All practice questions

976 questions

All types976 Multiple choice502 Multiple select450 Ordering24

An organization runs a memory-sensitive workload on a standalone Amazon EC2 instance. To ensure stability, the instance must be automatically rebooted if the custom metric `AvailableMemory`—which is published every ` $5$ ` minutes to a custom namespace—falls below ` $1024$ ` MB for two consecutive evaluation periods (a total of ` $10$ ` minutes). Which two configuration steps should a SysOps Administrator perform to achieve this requirement?

Select all that apply

Create a CloudWatch alarm on the `AvailableMemory` metric with a threshold of `

1024

` MB, a period of `

5

` minutes, and evaluation periods set to `

2

Configure an Amazon EventBridge rule that matches the CloudWatch alarm's state change to `ALARM`, and set the target to the `AWS-RestartEC2Instance` Systems Manager Automation runbook.

Add an EC2 reboot action directly to the CloudWatch alarm configuration to restart the instance when the alarm enters the `ALARM` state.

Enable detailed monitoring on the EC2 instance to increase the reporting frequency of the `AvailableMemory` custom metric to `

1

-minute` intervals.

Configure an Auto Scaling group scaling policy with a `

10

-minute` cooldown period to trigger the reboot action.

Show answer & explanation

Answer: Create a CloudWatch alarm on the `AvailableMemory` metric with a threshold of ` $1024$ ` MB, a period of ` $5$ ` minutes, and evaluation periods set to ` $2$ `.; Configure an Amazon EventBridge rule that matches the CloudWatch alarm's state change to `ALARM`, and set the target to the `AWS-RestartEC2Instance` Systems Manager Automation runbook.

Answer

The SysOps Administrator must create a CloudWatch alarm with a threshold of `

1024

` MB, a `

5

-minute` period, and `

2

` evaluation periods, and configure an Amazon EventBridge rule targeting the `AWS-RestartEC2Instance` Systems Manager Automation runbook on alarm state changes.

To satisfy the requirements, the CloudWatch alarm must evaluate the `AvailableMemory` metric over a `

5

-minute` period for `

2

` consecutive evaluation periods to span the `

10

-minute` window. Additionally, since the metric belongs to a custom namespace, the built-in EC2 actions (such as reboot or recover) cannot be attached directly to the alarm. Instead, an Amazon EventBridge rule must be configured to intercept the alarm's state change to `ALARM` and trigger the `AWS-RestartEC2Instance` Systems Manager Automation runbook to reboot the instance.

Step-by-Step Solution

Determine the alarm threshold, period, and evaluation periods settings.

Set the threshold to `

1024

` MB, period to `

5

` minutes, and evaluation periods to `

2

Since the metric is published every `

5

` minutes, a `

5

-minute` period is required. Checking for two consecutive periods ensures that the condition persists for `

10

` minutes before triggering the alarm.

Determine how to execute the reboot action on the EC2 instance.

Create an EventBridge rule that triggers the Systems Manager Automation runbook `AWS-RestartEC2Instance` when the alarm state changes to `ALARM`.

Custom metrics do not support built-in EC2 alarm actions (like reboot). EventBridge must route the state change to an SSM runbook to perform the reboot.

Key Concept

CloudWatch Custom Metric Alarms and Remediation Actions

Question 702Question →

A SysOps Administrator is troubleshooting an issue where a newly configured AWS CloudTrail trail is failing to deliver logs to a centralized Amazon S3 bucket. The trail is configured to encrypt log files using an AWS Key Management Service (AWS KMS) customer managed key. The S3 bucket policy is verified to correctly permit the 'cloudtrail.amazonaws.com' service principal to write objects. However, log delivery is failing, and the CloudTrail console displays an access denied error related to encryption. Which modification will resolve this log delivery issue?

Modify the S3 bucket policy to include 'kms:GenerateDataKey*' and 'kms:Decrypt' in the list of allowed actions for the 'cloudtrail.amazonaws.com' service principal.

Modify the KMS key policy to allow the 'cloudtrail.amazonaws.com' service principal to perform 'kms:GenerateDataKey*' and 'kms:DescribeKey' actions, using the 'aws:SourceArn' or encryption context conditions to restrict access to the trail.

Create an IAM role with a policy allowing the 'kms:GenerateDataKey*' action, attach it to the trail using the 'iam:PassRole' permission, and configure the KMS key to trust this role.

Update the KMS key policy to delegate key administration to the S3 bucket owner by adding the bucket owner's account root principal to the key's administrator list.

Show answer & explanation

Answer: Modify the KMS key policy to allow the 'cloudtrail.amazonaws.com' service principal to perform 'kms:GenerateDataKey*' and 'kms:DescribeKey' actions, using the 'aws:SourceArn' or encryption context conditions to restrict access to the trail.

Answer

The correct solution is to modify the KMS key policy to grant the 'cloudtrail.amazonaws.com' service principal permissions for 'kms:GenerateDataKey*' and 'kms:DescribeKey'. Because CloudTrail encrypts logs on the client side before delivering them to S3, it must have direct permission to use the customer managed key. Adding conditions like 'aws:SourceArn' or 'kms:EncryptionContext:aws:cloudtrail:arn' prevents unauthorized use of the key by other trails or accounts.

Step-by-Step Solution

Identify the resource where the access denied error is occurring.

The error is related to encryption, indicating the issue is with the KMS key policy rather than the S3 bucket policy.

The S3 bucket policy is already verified as correct, so the block is at the KMS key level.

Determine the principal and actions required for CloudTrail log encryption.

CloudTrail needs to call 'kms:GenerateDataKey*' to generate data keys for encryption and 'kms:DescribeKey' to obtain key metadata.

CloudTrail encrypts logs using the customer managed key on the client side before uploading them to the S3 bucket.

Configure the KMS key policy to grant the necessary permissions.

Add a statement allowing 'cloudtrail.amazonaws.com' the identified actions with condition keys like 'aws:SourceArn' to secure the key.

Key policies are the primary authorization mechanism for KMS customer managed keys.

Key Concept

AWS KMS Key Policies for CloudTrail Encryption

Question 703Question →

A SysOps administrator notices that an Auto Scaling group is launching excessive, redundant EC2 instances shortly after a scale-out event begins. This behavior occurs because new instances are still bootstrapping and have not yet begun reporting metrics, causing the CloudWatch alarm to remain in the ALARM state. Which Auto Scaling configuration setting should the administrator adjust to prevent these redundant scaling actions?

Configure detailed monitoring on the launch template to increase the frequency of EC2 instance metrics.

Increase the default instance warmup or scaling cooldown setting.

Attach an IAM policy with the iam:PassRole permission to the Auto Scaling group's service-linked role.

Create an Amazon EventBridge rule that triggers an AWS Systems Manager Automation document to delete duplicate scaling requests.

Show answer & explanation

Answer: Increase the default instance warmup or scaling cooldown setting.

Answer

Increase the default instance warmup or scaling cooldown setting.

Increasing the default instance warmup or scaling cooldown setting prevents the Auto Scaling group from launching additional instances while the existing ones are still bootstrapping. This gives the newly launched instances enough time to start reporting metrics and potentially bring the metric back to normal levels, resolving the alarm state.

Step-by-Step Solution

Analyze the root cause of the redundant instance launches, which is that the Auto Scaling group triggers new scale-out actions before previously launched instances are fully operational and reporting metrics.

Identify that the Auto Scaling group is acting too quickly on historical alarm data.

Understanding the timing of scaling actions is essential to resolving resource over-provisioning.

Identify the parameters that control the pause or grace period after a scaling action, specifically the instance warmup and scaling cooldown settings.

Recognize that increasing these parameters forces the Auto Scaling group to wait.

This allows newly launched instances enough time to finish bootstrapping and start reporting metrics to CloudWatch.

Select the option that recommends increasing the default instance warmup or scaling cooldown settings.

Determine the correct configuration change to prevent redundant launches.

This directly mitigates the issue without introducing unnecessary architectural complexity or permission changes.

Key Concept

Auto Scaling cooldown and warmup periods

Question 704Question →

A SysOps Administrator is configuring a new AWS CloudTrail trail to deliver management events to an Amazon S3 bucket. The logs must be encrypted using an AWS Key Management Service (AWS KMS) customer managed key (SSE-KMS), and log file integrity validation must be enabled. Which actions must the SysOps Administrator take to configure this log delivery and encryption? (Select two.)

Select all that apply

Configure the Amazon S3 bucket policy to allow the AWS CloudTrail service principal to perform s3:PutObject and s3:GetBucketAcl actions.

Configure the AWS KMS key policy to allow the AWS CloudTrail service principal to perform kms:GenerateDataKey* and kms:DescribeKey actions.

Attach an IAM policy to the administrator's IAM group that grants kms:Encrypt and kms:GenerateDataKey permissions on the customer managed key.

Create an IAM service role for CloudTrail with Amazon S3 write access, and specify the role in the trail's configuration settings.

Create an Amazon EventBridge rule that detects CloudTrail log uploads and triggers an AWS Systems Manager Automation workflow to encrypt the log files.

Show answer & explanation

Answer: Configure the Amazon S3 bucket policy to allow the AWS CloudTrail service principal to perform s3:PutObject and s3:GetBucketAcl actions.; Configure the AWS KMS key policy to allow the AWS CloudTrail service principal to perform kms:GenerateDataKey* and kms:DescribeKey actions.

Answer

Configure the Amazon S3 bucket policy to allow the AWS CloudTrail service principal to perform s3:PutObject and s3:GetBucketAcl actions, and configure the AWS KMS key policy to allow the AWS CloudTrail service principal to perform kms:GenerateDataKey* and kms:DescribeKey actions.

To successfully deliver and encrypt logs, the Amazon S3 bucket policy must explicitly permit the AWS CloudTrail service principal (cloudtrail.amazonaws.com) to write log files using s3:PutObject and check bucket ACLs using s3:GetBucketAcl. Concurrently, the AWS KMS key policy must permit the same service principal to execute kms:GenerateDataKey* to obtain data encryption keys and kms:DescribeKey to check the key's state.

Step-by-Step Solution

Ensure the target Amazon S3 bucket policy permits the AWS CloudTrail service principal (cloudtrail.amazonaws.com) to execute s3:PutObject for writing logs and s3:GetBucketAcl to verify bucket owner control.

The S3 bucket will accept logs delivered by the CloudTrail service without permission errors.

CloudTrail must verify ownership of the bucket before writing log files to avoid data loss or delivery failures.

Modify the AWS KMS key policy of the customer managed key to allow the cloudtrail.amazonaws.com service principal to run kms:GenerateDataKey* and kms:DescribeKey actions.

CloudTrail can generate unique data keys to encrypt each log object natively using SSE-KMS.

CloudTrail uses key policy delegation to encrypt logs at rest directly, as it cannot rely on user-level IAM policies for background service operations.

Key Concept

Configuring S3 bucket policies and KMS key policies for AWS CloudTrail log delivery

Question 705Question →

A SysOps Administrator is troubleshooting log delivery for an AWS Organizations trail configured in the management account (111122223333). The trail is configured to log API events for all member accounts, deliver logs to a centralized Amazon S3 bucket named central-trail-logs, and encrypt the logs using a customer managed AWS KMS key. Currently, no logs are appearing in the S3 bucket, and CloudTrail logs show delivery errors. Which two configuration updates are required to resolve this issue? (Select TWO.)

Select all that apply

Update the S3 bucket policy on central-trail-logs to allow the cloudtrail.amazonaws.com service principal to perform the s3:PutObject action on arn:aws:s3:::central-trail-logs/AWSLogs/* and the s3:GetBucketAcl action on the bucket resource.

Update the KMS key policy to allow the cloudtrail.amazonaws.com service principal to perform the kms:GenerateDataKey* and kms:Decrypt actions, with a condition matching the trail ARN in the encryption context.

Create an IAM role with iam:PassRole permissions attached to the SysOps Administrator's IAM user policy to delegate S3 and KMS permissions to the CloudTrail service.

Modify the S3 bucket policy on central-trail-logs to grant the s3:PutObject permission directly to the SysOps Administrator's IAM role, since CloudTrail executes API calls under the credentials of the user who created the trail.

Configure an Amazon EventBridge rule that triggers an AWS Systems Manager Automation execution role to assume the target role and write logs directly to the S3 bucket whenever a write event is recorded.

Show answer & explanation

Answer: Update the S3 bucket policy on central-trail-logs to allow the cloudtrail.amazonaws.com service principal to perform the s3:PutObject action on arn:aws:s3:::central-trail-logs/AWSLogs/* and the s3:GetBucketAcl action on the bucket resource.; Update the KMS key policy to allow the cloudtrail.amazonaws.com service principal to perform the kms:GenerateDataKey* and kms:Decrypt actions, with a condition matching the trail ARN in the encryption context.

Answer

Update the S3 bucket policy to allow the CloudTrail service principal to perform s3:PutObject and s3:GetBucketAcl, and update the KMS key policy to allow the CloudTrail service principal to perform kms:GenerateDataKey* and kms:Decrypt.

AWS CloudTrail requires explicit permissions to write logs to an Amazon S3 bucket and to use a customer managed KMS key for encryption. Specifically, the S3 bucket policy must allow the CloudTrail service principal (cloudtrail.amazonaws.com) to perform s3:PutObject on the log file prefix (such as arn:aws:s3:::central-trail-logs/AWSLogs/*) and s3:GetBucketAcl on the bucket. If the logs are encrypted using a customer managed KMS key, the KMS key policy must also explicitly allow the CloudTrail service principal to perform the kms:GenerateDataKey* and kms:Decrypt actions, with a condition verifying the CloudTrail ARN in the encryption context. Without both policy configurations, log delivery will fail.

Step-by-Step Solution

Verify and update the S3 bucket policy on the destination bucket.

The bucket policy is updated to grant the cloudtrail.amazonaws.com service principal the s3:PutObject permission for the log path and the s3:GetBucketAcl permission for the bucket itself.

This allows CloudTrail to verify bucket ownership and write log files to the S3 bucket.

Verify and update the KMS key policy of the customer managed key used for encryption.

The key policy is updated to grant the cloudtrail.amazonaws.com service principal the kms:GenerateDataKey* and kms:Decrypt permissions with a condition matching the trail ARN in the encryption context.

This allows CloudTrail to encrypt the logs before storing them in S3.

Key Concept

CloudTrail log delivery permissions requiring service principal access in S3 bucket policies and KMS key policies.

Question 706Question →

An administrator has installed the unified Amazon CloudWatch agent on an Amazon EC2 instance to send application log files to Amazon CloudWatch Logs. The agent status is running, but no log streams are appearing in the CloudWatch console. Which of the following configurations is missing and preventing the logs from being delivered?

The IAM policy for the administrator role lacks the iam:PassRole permission needed to assign the role to the CloudWatch agent.

The target CloudWatch log group has a retention policy configured to zero days, which automatically deletes log streams as soon as they are received.

The S3 bucket policy for the log group's storage location is missing permission to allow write access from the EC2 instance.

The IAM role associated with the EC2 instance profile does not have the policy permissions required to create log streams and put log events in CloudWatch Logs.

Show answer & explanation

Answer: The IAM role associated with the EC2 instance profile does not have the policy permissions required to create log streams and put log events in CloudWatch Logs.

Answer

The IAM role associated with the EC2 instance profile does not have the policy permissions required to create log streams and put log events in CloudWatch Logs.

For the unified CloudWatch agent on an EC2 instance to send logs to CloudWatch Logs, it must run with the proper IAM permissions. Since the agent executes on the EC2 instance, it uses the credentials provided by the EC2 instance profile's IAM role. If this role is missing the permissions for logs:CreateLogStream and logs:PutLogEvents (commonly provided by the CloudWatchAgentServerPolicy managed policy), the logs cannot be sent.

Step-by-Step Solution

Verify that the Amazon CloudWatch agent is running and configured correctly on the EC2 instance.

The agent status is active and logs are processed locally, but fail to appear in CloudWatch.

This isolates the issue to permissions or network connectivity rather than agent configuration.

Check the IAM role attached to the EC2 instance profile and inspect its permissions policy.

The IAM role is missing permissions such as logs:CreateLogStream and logs:PutLogEvents.

The EC2 instance needs explicit AWS API permissions to publish logs to CloudWatch Logs.

Attach the AWS managed policy CloudWatchAgentServerPolicy to the IAM role.

The EC2 instance now has permissions to push metrics and logs to CloudWatch.

This updates the IAM credentials used by the agent to allow successful log transmission.

Key Concept

EC2 Instance Profile and CloudWatch Logs Permissions

Question 707Question →

A company runs a production web application on AWS. The application tier consists of stateless Amazon EC2 instances, and the data tier uses an Amazon RDS for PostgreSQL database instance. A SysOps administrator must implement a cross-region disaster recovery (DR) strategy with a Recovery Time Objective (RTO) of 4 hours and a Recovery Point Objective (RPO) of 24 hours. The strategy must minimize ongoing costs. Which DR strategy should the administrator implement to meet these requirements?

Configure a pilot light strategy by deploying a standby EC2 instance in the recovery region and setting up a cross-region RDS Read Replica to serve as the automatic, synchronous failover target.

Configure a warm standby strategy by deploying a fully functional, active-active multi-site architecture across both regions, and use Route 53 failover routing without associating health checks with the primary DNS record.

Configure AWS Backup to take daily snapshots of the database and EC2 instances, copy them to the recovery region, and deploy the infrastructure using AWS CloudFormation templates only during a failover event.

Configure an S3 bucket in the recovery region to store database backups, and enable S3 Cross-Region Replication (CRR) from the primary bucket without enabling versioning on the source bucket.

Show answer & explanation

Answer: Configure AWS Backup to take daily snapshots of the database and EC2 instances, copy them to the recovery region, and deploy the infrastructure using AWS CloudFormation templates only during a failover event.

Answer

The Backup and Restore strategy satisfies both RTO and RPO requirements at the lowest cost. Taking daily backups satisfies the 24-hour RPO, and copying them to a secondary region allows restoration within 4 hours (RTO) using CloudFormation to deploy resources on-demand. This avoids the running costs associated with Pilot Light, Warm Standby, or Multi-site strategies.

Step-by-Step Solution

Analyze RTO and RPO requirements.

The target RTO is 4 hours (acceptable recovery time), and RPO is 24 hours (acceptable data loss up to 24 hours).

Determines which DR strategy satisfies the requirements while minimizing costs.

Evaluate the cost-effectiveness of DR strategies.

Backup and Restore has the lowest cost because it does not keep active compute resources running in the secondary region.

Selecting the strategy that matches the 'minimize ongoing costs' constraint.

Confirm technical feasibility of Backup and Restore.

Daily backups copied to the secondary region satisfy the 24-hour RPO. Restoring the database from snapshots and deploying stateless instances using CloudFormation can easily be completed within 4 hours, satisfying the RTO.

Ensures the selected option meets all specified targets.

Key Concept

Disaster Recovery Strategies

Question 708Question →

A financial services provider hosts a critical transaction application in the us-east-1 Region. The architecture consists of an Application Load Balancer, an Auto Scaling group of Amazon EC2 instances, and an Amazon Aurora PostgreSQL database cluster. The provider requires a disaster recovery (DR) solution in the us-west-2 Region with a Recovery Point Objective (RPO) of less than 5 minutes and a Recovery Time Objective (RTO) of less than 15 minutes. The solution must minimize ongoing operational costs.

Which strategy meets these requirements?

Configure an Amazon Aurora Global Database with a secondary cluster in us-west-2 containing a single DB instance. Deploy the Application Load Balancer and an Auto Scaling group in us-west-2 with the desired capacity set to 0. During a disaster, promote the secondary Aurora cluster and scale up the Auto Scaling group.

Configure the Aurora PostgreSQL database cluster as Multi-AZ in us-east-1. Deploy a duplicate Application Load Balancer and Auto Scaling group in us-west-2, and configure Amazon Route 53 active-passive failover to route traffic to us-west-2 if the primary region experiences a service disruption.

Set up an Amazon Aurora Global Database with a secondary cluster in us-west-2. Deploy an Application Load Balancer and Auto Scaling group in both regions, and configure an Amazon Route 53 active-active failover routing policy using latency-based routing to distribute write transactions across both regions.

Schedule database backups using script-based snapshots exported to an Amazon S3 bucket in us-east-1. Configure S3 Cross-Region Replication (CRR) to a bucket in us-west-2 without enabling bucket versioning to save on storage fees. In us-west-2, deploy the compute infrastructure with a standby database ready to restore the snapshots.

Show answer & explanation

Answer: Configure an Amazon Aurora Global Database with a secondary cluster in us-west-2 containing a single DB instance. Deploy the Application Load Balancer and an Auto Scaling group in us-west-2 with the desired capacity set to 0. During a disaster, promote the secondary Aurora cluster and scale up the Auto Scaling group.

Answer

The correct strategy uses Aurora Global Database, which offers sub-second replication to us-west-2, meeting the 5-minute RPO requirement. By keeping the secondary cluster active with a single DB instance and using an Auto Scaling group with a desired capacity of 0, the organization minimizes ongoing compute costs in the disaster recovery region. In the event of a disaster, promoting the secondary cluster and scaling up the Auto Scaling group can be completed well within the 15-minute RTO target.

Step-by-Step Solution

Analyze RTO and RPO requirements.

The RPO must be less than 5 minutes (data loss limit) and the RTO must be less than 15 minutes (downtime limit).

This determines which data replication mechanism and compute restoration process are acceptable.

Evaluate the database replication strategy.

Aurora Global Database replicates data within seconds (RPO < 5 minutes) and can be promoted to a standalone read-write cluster in under a minute (RTO < 15 minutes).

Traditional backup-and-restore or snapshot copy methods take too long to restore, violating the 15-minute RTO.

Evaluate the cost minimization strategy for compute resources.

Keeping the secondary Auto Scaling group at a desired capacity of 0 ensures that no EC2 instances are running (and incurring costs) under normal conditions, while remaining deployable via scaling actions during failover.

This meets the pilot light / warm standby principle of keeping infrastructure costs to a minimum in the DR region.

Key Concept

Disaster Recovery Strategies

Question 709Question →

A company's production environment runs on a single-node Amazon RDS for MySQL DB instance. Due to recent network issues, a SysOps Administrator is tasked with configuring the database for high availability to ensure it can survive an Availability Zone outage with minimal downtime. Which actions should the administrator take to achieve this configuration? (Select TWO.)

Select all that apply

Modify the RDS DB instance to enable the Multi-AZ deployment option.

Configure the application connection string to point to the single DB instance endpoint, which remains unchanged during a failover.

Deploy an RDS Read Replica in a different Availability Zone and configure the application to write to the read replica's endpoint.

Configure an Amazon Route 53 failover routing policy to direct write traffic to an RDS Read Replica when the primary instance becomes unhealthy.

Create a secondary DB instance in a separate Availability Zone and configure the application to manually swap connection strings when an outage is detected.

Show answer & explanation

Answer: Modify the RDS DB instance to enable the Multi-AZ deployment option.; Configure the application connection string to point to the single DB instance endpoint, which remains unchanged during a failover.

Answer

To configure the Amazon RDS DB instance for high availability, the administrator must modify the DB instance to enable the Multi-AZ deployment option and ensure the application connects to the single database endpoint, which RDS automatically updates to point to the standby instance during a failover.

High availability and automated failover in Amazon RDS are achieved by enabling the Multi-AZ deployment option, which provisions a synchronous standby replica in another Availability Zone. Amazon RDS manages the DNS configuration for the DB instance endpoint, automatically updating it to point to the standby instance during a failover so that the application connection string remains unchanged.

Step-by-Step Solution

Enable Multi-AZ deployment in the Amazon RDS console or via the AWS CLI for the target DB instance.

Amazon RDS provisions a standby replica in a different Availability Zone and begins synchronous data replication.

This sets up the physical infrastructure and synchronous data replication required for automatic failover without data loss.

Verify that the application is configured to connect using the primary RDS DB endpoint rather than any hardcoded IP addresses or secondary endpoints.

The application remains pointed at a single DNS name that handles connection routing.

During an outage, Amazon RDS automatically updates the DNS record to point to the standby instance, keeping the endpoint name the same and avoiding application configuration updates.

Key Concept

Amazon RDS Multi-AZ deployments provide high availability and automated failover by replicating data synchronously to a standby instance in a different Availability Zone, utilizing a single DNS endpoint that RDS automatically updates during a failover event.

Estimated Time:1m 0s

Question 710Question →

A SysOps Administrator is configuring a new multi-region trail in AWS CloudTrail for Account A ( $111111111111$ ). The trail is configured to deliver logs to a centralized Amazon S3 bucket located in Account B ( $222222222222$ ). The bucket is configured to encrypt all new objects using a Customer Managed Key (CMK) in AWS KMS located in Account B. The S3 bucket policy in Account B has been updated to allow log delivery from Account A, but CloudTrail displays a log delivery error and no log files are generated. Which configuration change will resolve this log delivery failure?

Add a statement to the KMS key policy in Account B that grants the CloudTrail service principal (cloudtrail.amazonaws.com) the permissions to perform kms:GenerateDataKey* and kms:DescribeKey, using a condition to verify the source trail ARN:

{
"Sid": "Allow CloudTrail to encrypt logs",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:111111111111:trail/*"
}
}
}

Add a statement to the S3 bucket policy in Account B that grants the CloudTrail service principal the permissions to perform kms:GenerateDataKey* and kms:DescribeKey on the encryption key:

{
"Sid": "Allow CloudTrail KMS encryption",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:us-east-1:222222222222:key/my-kms-key"
}

Attach an IAM policy to the IAM execution role used by CloudTrail in Account A to allow key usage across accounts:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow KMS usage for CloudTrail",
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:us-east-1:222222222222:key/my-kms-key"
}
]
}

Attach an IAM policy to the CloudTrail administrator in Account A to allow passing the delivery role to CloudTrail across accounts:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow PassRole to CloudTrail",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111111111111:role/CloudTrailDeliveryRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": "cloudtrail.amazonaws.com"
}
}
}
]
}

Show answer & explanation

Answer: Add a statement to the KMS key policy in Account B that grants the CloudTrail service principal (cloudtrail.amazonaws.com) the permissions to perform kms:GenerateDataKey* and kms:DescribeKey, using a condition to verify the source trail ARN:

{
"Sid": "Allow CloudTrail to encrypt logs",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:111111111111:trail/*"
}
}
}

Answer

When a CloudTrail trail delivers logs to an Amazon S3 bucket encrypted with a Customer Managed Key (CMK), the CloudTrail service principal (cloudtrail.amazonaws.com) must have permissions to use the key. Because the key is in Account B and the trail is in Account A, the KMS key policy in Account B must explicitly permit the service principal to perform kms:GenerateDataKey* and kms:DescribeKey. Using the kms:EncryptionContext condition ensures that only the trail from Account A can use the key for log encryption.

Step-by-Step Solution

Identify the principal delivering the logs.

The AWS CloudTrail service principal (cloudtrail.amazonaws.com) is the caller that attempts to write logs and use the KMS key.

CloudTrail performs log writing and encryption directly under its own service identity, not a user-defined role.

Identify the resource policy where the permissions must be defined.

The target KMS key is in Account B, meaning only the KMS key policy in Account B can authorize cross-account access for the service principal.

KMS key policies must explicitly trust external principals and service principals for cross-account access.

Define the correct KMS actions and scoping conditions.

The actions kms:GenerateDataKey* and kms:DescribeKey are required, and the kms:EncryptionContext condition scopes the access to only the specific source trail in Account A.

This configuration enables CloudTrail to encrypt the files before putting them in the S3 bucket while ensuring other accounts cannot abuse the key.

Key Concept

Cross-account AWS CloudTrail log delivery with KMS encryption requires explicit KMS key policy permissions for the CloudTrail service principal.

Question 711Question →

A SysOps Administrator is designing a disaster recovery strategy for a critical transactional application. The primary infrastructure is in the eu-west-1 Region, utilizing an Amazon RDS for PostgreSQL DB instance in a Multi-AZ deployment. For cross-region disaster recovery, the administrator deploys an RDS Read Replica in the eu-central-1 Region.

To manage traffic during a regional outage, the administrator configures an Amazon Route 53 active-passive failover routing policy. The primary routing record is a CNAME pointing to the primary RDS endpoint in eu-west-1, associated with a Route 53 health check. The secondary routing record is a CNAME pointing to the replica's endpoint in eu-central-1.

During a simulated outage of eu-west-1, the health check fails, and Route 53 successfully redirects traffic to eu-central-1. However, the application fails to perform any write operations, returning read-only database transaction errors.

Which of the following describes the root cause of this issue, and the correct action to resolve it?

The Route 53 failover routing policy was configured with an active-active routing configuration rather than active-passive, which kept the primary region CNAME active. The administrator must change the routing policy to active-passive and associate the primary health check with the secondary record to allow RDS to automatically trigger the database promotion API.

The administrator did not configure the cross-region Read Replica as a standby instance within the RDS Multi-AZ deployment configuration. Enabling Multi-AZ globally across both regions is required for RDS to perform automatic failover and promote the secondary replica to a write-enabled state without manual intervention.

Cross-region RDS Read Replicas are read-only and do not automatically promote to primary write-enabled instances during a DNS failover. To restore write capabilities, the administrator must manually promote the Read Replica in the secondary region to a standalone DB instance.

The administrator omitted the 'Enable Failover Target' attribute when launching the cross-region Read Replica. Without this attribute, Route 53 DNS updates redirect the application connection string, but the replica is prevented from assuming the master role and transitioning out of read-only mode.

Show answer & explanation

Answer: Cross-region RDS Read Replicas are read-only and do not automatically promote to primary write-enabled instances during a DNS failover. To restore write capabilities, the administrator must manually promote the Read Replica in the secondary region to a standalone DB instance.

Answer

The correct answer is correct because Amazon RDS cross-region Read Replicas are designed for asynchronous read replication and disaster recovery, but they are read-only. Route 53 DNS failover only updates the CNAME record to point to the secondary region endpoint; it does not perform any control-plane actions on the RDS database itself. To enable write operations on the secondary database, the administrator must manually promote the Read Replica to a standalone database instance.

Step-by-Step Solution

Analyze the architecture components and identify that the database in the primary region is configured as Multi-AZ, whereas the database in the secondary region is a cross-region Read Replica.

Identify that RDS Multi-AZ provides synchronous replication and automatic failover within a single region, but cross-region disaster recovery relies on asynchronous Read Replicas.

Understanding the replication and failover boundaries is necessary to diagnose the cause of write failures in the secondary region.

Examine the role of Route 53 DNS failover in the setup.

Determine that Route 53 active-passive failover only updates DNS routing records (CNAME) to point to the new database endpoint, but it does not execute any database promotion operations.

This distinguishes DNS-level routing updates from database-level state changes (such as promoting a read-only instance to read-write).

Identify the write state of the database target in the secondary region.

Confirm that the cross-region Read Replica in the secondary region remains in a read-only state because it has not been promoted.

This explains why the client application receives read-only database transaction errors upon connecting to the replica.

Determine the required administrative action to resolve the database write errors.

The administrator must manually promote the cross-region Read Replica to a standalone DB instance to enable write operations.

Promoting the replica breaks replication and opens the database for read-write operations, completing the disaster recovery failover process.

Key Concept

Distinction between local Multi-AZ failover (automatic, synchronous) and cross-region disaster recovery using Read Replicas (manual promotion, asynchronous).

Estimated Time:3m 0s

Question 712Question →

A company has an Amazon EC2 Auto Scaling group (ASG) configured with a scale-in lifecycle hook. When a scale-in event occurs, application log files on the instance must be backed up to an Amazon S3 bucket before the instance is terminated. A SysOps administrator is configuring this flow using Amazon EventBridge and AWS Systems Manager Run Command.

Arrange the sequence of events in the correct chronological order from the initiation of the scale-in event to the final termination of the instance.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with Auto Scaling selecting the instance for termination. Next, the instance enters the Terminating:Wait state, which triggers an Amazon EventBridge rule to invoke the Systems Manager Run Command. The SSM Run Command runs the backup script on the instance, which uploads logs to S3. Once completed, the script signals Auto Scaling via the complete-lifecycle-action CLI command with a CONTINUE result. Finally, Auto Scaling moves the instance to Terminating:Proceed and terminates it.

The correct order follows the chronological flow of an Auto Scaling lifecycle hook from the initial scale-in determination, pausing in Terminating:Wait, triggering remediation via EventBridge, executing SSM Run Command to copy logs, signaling completion using the AWS CLI, and finally terminating the instance in Terminating:Proceed.

Step-by-Step Solution

Select instance for termination

The target instance is chosen according to the ASG's termination policies.

Before any lifecycle action occurs, the scale-in trigger must run and identify which instance will be terminated.

Pause instance termination

The instance enters the Terminating:Wait state.

The lifecycle hook intercepts the termination flow to allow custom tasks like log exporting to run first.

Trigger automation via EventBridge

EventBridge receives the event pattern and targets SSM Run Command.

EventBridge serves as the event bus that detects the state change and initiates the remediation action.

Run logs export on the instance

Logs are transferred to the Amazon S3 bucket.

The SSM Agent running on the instance runs the script locally to retrieve and store the application logs.

Complete lifecycle hook action

Auto Scaling receives the API call to complete the lifecycle hook.

The script must signal Auto Scaling that the logs are successfully archived so it knows it is safe to proceed.

Proceed with termination

The instance moves to Terminating:Proceed and is shut down.

With the lifecycle hook resolved, Auto Scaling resumes the normal termination process.

Key Concept

Auto Scaling Lifecycle Hooks and AWS Integration

Question 713Question →

A SysOps administrator is configuring a monitoring solution for a legacy transaction-processing application. The application logs are streamed to an Amazon CloudWatch Logs log group. The log events use a space-delimited format, with each line structured as:

`[Date] [Time] [Transaction_ID] [Status] [Latency_MS]`

An example log line is:

`2026-07-14 10:15:30 tx-40293 SUCCESS 1250`

The administrator needs to monitor performance degradation by capturing the latency of all successful transactions where the latency exceeds $1000$ milliseconds. The captured latency values must be published to a custom CloudWatch metric.

Which configuration should the administrator use to accomplish this?

Create a metric filter with the filter pattern `[date, time, transaction_id, status = SUCCESS, latency > 1000]` and set the metric value to `$latency` in the metric transformation.

Create a metric filter with the filter pattern `[date, time, transaction_id, status = SUCCESS, latency > 1000]` and set the metric value to `

latency` in the metric transformation, then enable detailed monitoring on the Amazon EC2 instances to ensure the custom metric reports at

1$-minute intervals.

Create a metric filter with the filter pattern `[date, time, transaction_id, status = SUCCESS, latency > 1000]` and set the metric value to `$latency` in the metric transformation, then set the log group retention period to Never Expire to prevent CloudWatch from deleting log data before the custom metric is published.

Configure an Amazon EventBridge rule to match any incoming log event containing the SUCCESS status, and set the target to an AWS Systems Manager Automation document that parses the log line and publishes the metric.

Show answer & explanation

Answer: Create a metric filter with the filter pattern `[date, time, transaction_id, status = SUCCESS, latency > 1000]` and set the metric value to `$latency` in the metric transformation.

Answer

Create a metric filter with the filter pattern `[date, time, transaction_id, status = SUCCESS, latency > 1000]` and set the metric value to `$latency` in the metric transformation.

The correct option specifies a valid space-delimited filter pattern `[date, time, transaction_id, status = SUCCESS, latency > 1000]` and maps the value of the fifth field using `$latency` in the metric transformation. This correctly extracts the numeric latency value and publishes it to CloudWatch Metrics.

Step-by-Step Solution

Define the filter pattern for space-delimited logs.

The pattern `[date, time, transaction_id, status = SUCCESS, latency > 1000]` maps the fields in order and filters for status equal to SUCCESS and latency greater than

1000

This matches the space-delimited format of the incoming logs and applies the required filtering criteria.

Configure the metric value in the metric transformation.

Set the metric value to `$latency`.

This extracts the actual value of the fifth field (latency) from the log event to publish it as the metric data point, rather than just counting the occurrences.

Key Concept

CloudWatch Logs Metric Filters allow administrators to use space-delimited or JSON patterns to search log streams and extract terms or values to publish as custom metrics in CloudWatch.

Question 714Question →

An organization has enabled log file integrity validation on an active AWS CloudTrail trail. While the trail successfully delivers CloudTrail log files to the destination Amazon S3 bucket, the administrator notices that no digest files are being generated or delivered to the bucket, preventing log validation. Which of the following is the most likely cause of this issue?

The IAM policy attached to the CloudTrail service role is missing the iam:PassRole permission, which prevents CloudTrail from passing the execution role to the S3 bucket during digest delivery.

An Amazon EventBridge rule is missing to trigger an AWS Systems Manager Automation document that initiates digest file generation when log files are written to S3.

The S3 bucket policy limits s3:PutObject permissions to the path prefix AWSLogs/123456789012/CloudTrail/*, which prevents CloudTrail from delivering the digest files to the prefix AWSLogs/123456789012/CloudTrail-Digest/*.

The KMS key policy used to encrypt the trail does not allow the kms:GenerateDataKey action for the digest prefix, although it allows it for the log prefix.

Show answer & explanation

Answer: The S3 bucket policy limits s3:PutObject permissions to the path prefix AWSLogs/123456789012/CloudTrail/*, which prevents CloudTrail from delivering the digest files to the prefix AWSLogs/123456789012/CloudTrail-Digest/*.

Answer

The correct answer is correct because CloudTrail log file integrity validation stores digest files under the 'CloudTrail-Digest' prefix rather than the standard 'CloudTrail' prefix. If the S3 bucket policy is overly restrictive and only grants permissions for the standard prefix, CloudTrail will fail to write the digests, resulting in missing files and validation failures.

Step-by-Step Solution

Identify the storage path for CloudTrail digest files.

CloudTrail stores digest files under the prefix AWSLogs/<AccountID>/CloudTrail-Digest/<Region>/.

Log file integrity validation uses a separate path for storing digest files compared to standard log files.

Review the S3 bucket policy permissions granted to the CloudTrail service principal.

The bucket policy must allow the s3:PutObject action on the digest path prefix.

Without this permission, CloudTrail cannot deliver digest files even if log file delivery is working.

Determine the corrective action to allow digest delivery.

Update the S3 bucket policy to grant s3:PutObject permission on the CloudTrail-Digest path or use a wildcard matching all paths under AWSLogs/<AccountID>/*.

This resolves the access denied error encountered by CloudTrail during digest delivery.

Key Concept

CloudTrail S3 Bucket Permissions for Log File Integrity Validation

Question 715Question →

A company hosts a web application on Amazon EC2 instances with an Amazon RDS for MySQL DB instance. A SysOps Administrator must establish a cross-region disaster recovery (DR) strategy with a Recovery Point Objective (RPO) of 1 hour and a Recovery Time Objective (RTO) of 30 minutes. The solution must minimize ongoing running costs in the recovery region. Which disaster recovery strategy should the SysOps Administrator implement to meet these requirements?

Configure a cross-region Amazon RDS read replica in the recovery region. Maintain the application tier infrastructure as an AWS CloudFormation template. In the event of a disaster, deploy the CloudFormation stack to launch the EC2 instances, promote the read replica to a standalone DB instance, and update Amazon Route 53 routing to point to the new resources.

Configure the Amazon RDS DB instance with Multi-AZ replication targeting the recovery region. Launch a minimum capacity Auto Scaling group of EC2 instances in the recovery region, and configure Route 53 to route all database queries directly to the RDS standby replica endpoint during a failover.

Deploy a duplicate active-active environment in the recovery region with running EC2 instances and a read replica of the RDS DB instance. Configure an Amazon Route 53 active-active weighted routing policy to distribute traffic equally between both regions, ensuring automatic DNS failover without manual database promotion.

Implement a Pilot Light strategy. Configure AWS Backup to copy database snapshots to the recovery region every hour. Set up Amazon S3 Cross-Region Replication to copy application files to the destination bucket in the recovery region, without enabling versioning on the source bucket to minimize storage costs.

Show answer & explanation

Answer: Configure a cross-region Amazon RDS read replica in the recovery region. Maintain the application tier infrastructure as an AWS CloudFormation template. In the event of a disaster, deploy the CloudFormation stack to launch the EC2 instances, promote the read replica to a standalone DB instance, and update Amazon Route 53 routing to point to the new resources.

Answer

The correct strategy is a Pilot Light configuration. An RDS cross-region read replica keeps the data synchronized asynchronously, meeting the 1-hour RPO target. Keeping the application resources in an AWS CloudFormation template avoids ongoing EC2 costs in the recovery region, and deploying them takes only minutes, easily meeting the 30-minute RTO constraint.

Step-by-Step Solution

Analyze the RTO, RPO, and cost constraints.

An RPO of 1 hour requires continuous data replication, while an RTO of 30 minutes requires automated template-based provisioning or pre-warmed servers. The cost constraint dictates minimizing running compute resources in the recovery region.

This rules out full active-active strategies due to high cost, and rules out backup-and-restore strategies due to the time required to restore database instances from snapshots exceeding 30 minutes.

Determine the database replication mechanism for cross-region disaster recovery.

Amazon RDS cross-region read replicas use asynchronous replication, satisfying the 1-hour RPO target with minimal overhead and without running standby write instances.

Synchronous Multi-AZ deployments are restricted to a single region and cannot be used for cross-region disaster recovery.

Validate the deployment method for the application tier during a failover.

Using AWS CloudFormation to spin up stateless EC2 instances on-demand fits the Pilot Light strategy. Because provisioning EC2 instances takes only a few minutes, it comfortably fits within the 30-minute RTO.

This minimizes ongoing idle compute costs while ensuring the application tier can be quickly established and mapped to the promoted database.

Key Concept

Disaster Recovery Strategies (Pilot Light vs. Warm Standby)

Question 716Question →

A SysOps administrator manages an Amazon EC2 Auto Scaling group (ASG) behind an Application Load Balancer. The ASG is configured with a target tracking scaling policy based on the $ASGAverageCPUUtilization$ metric at a target value of $60\%$ . Standard monitoring is enabled on the EC2 instances in the launch template. During sudden traffic spikes, CPU utilization rises to $90\%$ , triggering a scale-out. However, the administrator observes that the ASG launches multiple consecutive batches of instances before the first batch has finished initializing and registering with the load balancer, leading to significant over-provisioning. The application on the instances requires $4$ minutes to become fully operational and begin processing requests. Which action should the administrator take to prevent this over-provisioning behavior?

Enable detailed monitoring in the launch template used by the ASG, and configure the estimated instance warm-up for the target tracking scaling policy to 240 seconds.

Keep standard monitoring enabled, and reduce the target tracking scaling policy's estimated instance warm-up to 60 seconds to allow the ASG to recalculate the metrics more frequently.

Increase the default cooldown period of the Auto Scaling group to 240 seconds to prevent the group from executing subsequent scale-out actions while instances are initializing.

Modify the EC2 instance profile role to grant the iam:PassRole permission to the Auto Scaling service, ensuring that the instances can pass their monitoring roles to CloudWatch without delay.

Show answer & explanation

Answer: Enable detailed monitoring in the launch template used by the ASG, and configure the estimated instance warm-up for the target tracking scaling policy to 240 seconds.

Answer

Enable detailed monitoring in the launch template used by the ASG, and configure the estimated instance warm-up for the target tracking scaling policy to 240 seconds.

Enabling detailed monitoring ensures that EC2 CPU utilization metrics are sent to CloudWatch at 1-minute intervals. Configuring the estimated instance warm-up to 240 seconds (4 minutes) ensures that the target tracking policy does not perform another scaling evaluation until the new instances have finished booting and their impact on the average CPU utilization is reflected in the 1-minute metric updates.

Step-by-Step Solution

Analyze the metric reporting frequency.

Standard monitoring updates metrics at 5-minute (300 seconds) intervals, which is longer than the 4 minutes (240 seconds) the application needs to boot.

To prevent the scaling policy from evaluating stale data, the metric evaluation frequency must match or exceed the scaling policy evaluation intervals.

Identify the scaling policy control parameter for scale-out actions.

Target tracking scaling policies use the 'estimated instance warm-up' parameter to determine how long to wait before counting newly launched instances toward the group's metrics.

The ASG's default cooldown is ignored for scale-out actions in target tracking policies.

Align the warm-up period with the actual initialization time.

Set the estimated instance warm-up to 240 seconds.

This blocks the policy from performing further scale-out evaluations until the new instances have had 4 minutes to boot.

Enable detailed monitoring in the launch template.

Metrics are now sent to CloudWatch at 1-minute intervals.

Detailed monitoring ensures that once the 240-second warm-up ends, CloudWatch has fresh metrics showing the reduced average CPU utilization, preventing subsequent redundant launches.

Key Concept

Auto Scaling Target Tracking Warm-up and Monitoring Granularity

Estimated Time:2m 0s

Question 717Question →

An organization's enterprise resource planning (ERP) application uses an Amazon RDS for PostgreSQL DB instance configured in a Multi-AZ deployment within the us-east-1 Region. For disaster recovery purposes, the database also has a cross-Region read replica configured in the us-west-2 Region. The application servers in us-east-1 connect to the database using the primary database endpoint CNAME. Amazon Route 53 is configured with an active-passive failover routing policy to redirect client traffic to us-west-2 only if the application stack in us-east-1 becomes completely unavailable.

Following an unexpected hardware failure on the active primary DB instance in us-east-1, the database undergoes an automatic failover. However, the SysOps Administrator observes that the local application servers in us-east-1 continue to encounter database connection timeout errors for several minutes, and Route 53 does not redirect client traffic to the us-west-2 Region.

Which two statements correctly explain these observations and identify the appropriate steps to resolve the connection issues? (Select TWO.)

Select all that apply

The database connection timeouts occur because the application servers or database clients have cached the DNS resolution (IP address) of the RDS primary database endpoint. Restarting the client applications or reducing the client-side DNS cache TTL will force them to resolve the endpoint to the newly promoted standby instance's IP address.

Route 53 did not redirect traffic to us-west-2 because the failover was localized to the primary Region. The database endpoint CNAME was updated to point to the standby instance within us-east-1, keeping the primary Region's application stack healthy and functional once client DNS caches cleared.

To resolve the connection timeouts, the administrator must manually promote the us-west-2 read replica to a standalone primary DB instance, as RDS Multi-AZ standby instances do not automatically assume the primary database endpoint CNAME during a failover.

To prevent future connection timeouts during database failovers, the application connection strings should be updated to point to the read replica endpoint in us-west-2, allowing synchronous write redirection to the promoted standby instance.

Route 53 failed to redirect client traffic because active-passive failover routing requires the primary database to be configured with an active-active routing policy to synchronize CNAME records across both Regions during a local AZ outage.

Show answer & explanation

Answer: The database connection timeouts occur because the application servers or database clients have cached the DNS resolution (IP address) of the RDS primary database endpoint. Restarting the client applications or reducing the client-side DNS cache TTL will force them to resolve the endpoint to the newly promoted standby instance's IP address.; Route 53 did not redirect traffic to us-west-2 because the failover was localized to the primary Region. The database endpoint CNAME was updated to point to the standby instance within us-east-1, keeping the primary Region's application stack healthy and functional once client DNS caches cleared.

Answer

The database connection timeouts are caused by client-side DNS caching of the RDS database endpoint, which can be resolved by restarting the application or reducing the DNS cache TTL. Route 53 did not fail over because the database failover was successfully handled locally within the primary Region, keeping the primary application stack healthy.

The correct options state that client-side DNS caching is the cause of connection timeouts following an RDS Multi-AZ failover, which can be mitigated by resetting connections or reducing cache TTL. Additionally, Route 53 did not fail over because the database failover was successfully resolved within the primary Region, maintaining the overall health of the primary application stack.

Step-by-Step Solution

Analyze the database configuration and the scope of the failover event.

The primary database is configured as an RDS Multi-AZ deployment in us-east-1, meaning automated failover is managed locally at the database service layer, while the us-west-2 read replica is asynchronous and decoupled from local AZ failovers.

To determine whether the failure represents a localized AZ issue or a regional disaster recovery event.

Evaluate the behavior of the database endpoint CNAME during Multi-AZ failovers.

RDS automatically promotes the standby DB instance and updates the CNAME of the database endpoint to resolve to the standby's new IP address, typically completing within 60 to 120 seconds.

To verify that manual intervention (such as promoting the read replica) is not required for a local AZ failover.

Diagnose the source of client connection timeouts following the failover.

Identify that client-side DNS caching (at the OS, JVM, or application level) preserves the resolved IP address of the failed primary instance, ignoring the updated CNAME target until the cache is cleared or restarted.

To explain the connection errors despite successful database-side standby promotion.

Evaluate Route 53 DNS routing status and health check conditions.

Confirm that Route 53 active-passive failover did not trigger because the application stack in us-east-1 recovered locally once client DNS cache cleared, keeping the primary Region's application health checks green.

To explain why client traffic was not redirected to the disaster recovery Region in us-west-2.

Key Concept

RDS Multi-AZ failovers rely on DNS CNAME updates to redirect local traffic, but client-side DNS caching can delay recovery. Route 53 regional failovers only trigger when the entire primary regional application stack fails health checks.

Estimated Time:3m 0s

Question 718Question →

A SysOps Administrator is troubleshooting an Amazon EC2 instance in a private subnet that is unable to send application logs to Amazon CloudWatch Logs. The unified CloudWatch agent is installed on the instance, and an interface VPC endpoint for CloudWatch Logs (`com.amazonaws.us-east-1.logs`) is deployed in the VPC. The CloudWatch agent log file on the instance shows repeated connection timeouts when attempting to reach the CloudWatch Logs service endpoint.

Which TWO configurations should the administrator verify to resolve these connection timeouts? (Select TWO.)

Select all that apply

Verify that the security group attached to the interface VPC endpoint allows inbound TCP port 443 traffic from the security group of the EC2 instance.

Verify that the VPC has both 'Enable DNS resolution' and 'Enable DNS hostnames' set to true to ensure the standard CloudWatch Logs service endpoint resolves to the private IP addresses of the interface VPC endpoint.

Verify that the EC2 instance profile has the `iam:PassRole` permission to pass the CloudWatch agent service role to the interface VPC endpoint.

Verify that the Amazon S3 bucket policy associated with the VPC gateway endpoint allows the `s3:PutObject` action from the EC2 instance profile role.

Verify that the retention policy of the destination CloudWatch log group is set to 'Never Expire' to allow the agent to initialize a new log stream.

Show answer & explanation

Answer: Verify that the security group attached to the interface VPC endpoint allows inbound TCP port 443 traffic from the security group of the EC2 instance.; Verify that the VPC has both 'Enable DNS resolution' and 'Enable DNS hostnames' set to true to ensure the standard CloudWatch Logs service endpoint resolves to the private IP addresses of the interface VPC endpoint.

Answer

Verify that the security group attached to the interface VPC endpoint allows inbound TCP port 443 traffic from the EC2 instance's security group, and verify that the VPC has 'Enable DNS resolution' and 'Enable DNS hostnames' set to true.

The connection timeouts indicate that the CloudWatch agent is unable to reach the CloudWatch Logs service endpoint. Because the EC2 instance is located in a private subnet without internet access, it must use the interface VPC endpoint (`com.amazonaws.us-east-1.logs`) to route its traffic privately. To achieve this, two conditions must be met: first, the security group of the VPC endpoint must permit inbound HTTPS (port 443) traffic from the EC2 instance's security group. Second, the VPC must have both 'Enable DNS resolution' and 'Enable DNS hostnames' enabled so that the standard CloudWatch Logs regional domain (e.g., `logs.us-east-1.amazonaws.com`) resolves to the private IP addresses of the interface endpoint instead of the public internet addresses.

Step-by-Step Solution

Analyze the error symptoms in the scenario.

The agent logs show connection timeouts, which points to a network routing or firewall issue rather than an IAM permission policy issue.

Connection timeouts occur when the client cannot establish a TCP handshake with the target endpoint.

Check the security group configuration of the interface VPC endpoint.

Ensure that the security group attached to the interface VPC endpoint allows inbound HTTPS (port 443) traffic from the EC2 instance's security group.

Interface VPC endpoints act as elastic network interfaces (ENIs) inside the VPC and are protected by security groups.

Verify DNS settings within the VPC.

Confirm that the VPC has 'Enable DNS resolution' and 'Enable DNS hostnames' enabled, allowing Private DNS on the endpoint to function.

Without Private DNS, the agent resolves the public endpoint address and fails to connect, as it resides in a private subnet with no internet route.

Key Concept

VPC Endpoint Connectivity and Private DNS Resolution for CloudWatch Logs

Question 719Question →

A SysOps Administrator is configuring a monitoring solution for a microservice running on AWS. The application outputs structured JSON logs to an Amazon CloudWatch Logs log group. Below is a sample log event:

{
"eventType": "OrderDelivery",
"details": {
"status": "Failed",
"retryCount": 3,
"latencyMs": 450
}
}

The administrator needs to monitor this log group and trigger an alert if there are frequent occurrences of order deliveries that fail after 3 or more retries. The administrator wants to ensure that the alarm evaluates correctly even during periods of zero traffic when no logs are generated.

Which TWO configuration steps should the administrator perform to meet these requirements? (Select TWO.)

Select all that apply

Create an Amazon CloudWatch Logs metric filter with the filter pattern {

.details.status = "Failed" &&

.details.retryCount >= 3 }.

In the metric transformation configuration, specify a metric value of 1 and set the default value of the metric to 0.

Enable detailed monitoring for the CloudWatch Log Group in the AWS Management Console to decrease the custom metric reporting interval to 1 minute.

Configure a log group retention policy of 0 days to purge log streams immediately after metric extraction, avoiding storage charges.

Define the filter pattern using SQL syntax SELECT COUNT(*) WHERE status = 'Failed' AND retryCount >= 3 and configure Amazon EventBridge to query the log group.

Show answer & explanation

Answer: Create an Amazon CloudWatch Logs metric filter with the filter pattern { $.details.status = "Failed" &&$ .details.retryCount >= 3 }.; In the metric transformation configuration, specify a metric value of 1 and set the default value of the metric to 0.

Answer

The correct steps are to create a metric filter with the JSON path pattern targeting status and retryCount, and to configure the metric transformation with a metric value of 1 and a default value of 0.

Defining the filter pattern using the JSON path notation to check nested fields matches the specific log structure. Setting a default value of 0 in the metric transformation ensures that CloudWatch reports a data point even when no matching events occur, preventing the metric from reporting insufficient data during zero-traffic periods.

Step-by-Step Solution

Analyze the JSON log structure and identify the correct JSON path for the target fields.

The target fields are 'status' and 'retryCount', nested inside the 'details' object, represented as '

.details.status' and '

.details.retryCount'.

This allows us to construct a syntactically correct CloudWatch Logs filter pattern.

Construct the JSON filter pattern using proper operators.

The pattern is {

.details.status = "Failed" &&

.details.retryCount >= 3 }.

This matches only log events where order delivery failed and has 3 or more retries.

Configure the metric transformation to handle zero-traffic scenarios.

Set the metric value to 1 and specify a default value of 0.

This guarantees that the metric reports 0 when there is no matching log activity, ensuring the alarm does not fall into an INSUFFICIENT_DATA state.

Key Concept

CloudWatch Logs Metric Filters and JSON Filter Patterns

Estimated Time:2m 0s

Question 720Question →

An organization runs an internal document processing system on AWS. The application tier uses stateless Amazon EC2 instances in a single Availability Zone in the us-west-2 Region. The data tier consists of an Amazon RDS for PostgreSQL database for metadata and an Amazon S3 bucket for PDF storage. A SysOps Administrator must establish a Disaster Recovery (DR) strategy in the us-east-1 Region. The business requires a Recovery Point Objective (RPO) of 15 minutes for the PDFs, an RPO of 1 hour for the metadata database, and a Recovery Time Objective (RTO) of 4 hours. The strategy must minimize ongoing costs under normal operating conditions. Which two configuration steps should the SysOps Administrator perform to meet these requirements? (Select TWO.)

Select all that apply

Enable S3 Versioning on both the source and destination buckets, and configure Amazon S3 Cross-Region Replication (CRR) to replicate documents from the us-west-2 bucket to the us-east-1 bucket.

Create an Amazon RDS PostgreSQL cross-region read replica in the us-east-1 Region.

Configure Amazon S3 Cross-Region Replication (CRR) to replicate documents from the us-west-2 bucket to the us-east-1 bucket without enabling S3 Versioning on either bucket.

Create an Amazon RDS PostgreSQL read replica in the us-east-1 Region, and rely on RDS Multi-AZ automatic failover to automatically route write traffic to the replica if the primary Region fails.

Configure an Amazon Route 53 active-active failover routing policy to route database write traffic to both Regions simultaneously, with a CNAME record at the zone apex.

Show answer & explanation

Answer: Enable S3 Versioning on both the source and destination buckets, and configure Amazon S3 Cross-Region Replication (CRR) to replicate documents from the us-west-2 bucket to the us-east-1 bucket.; Create an Amazon RDS PostgreSQL cross-region read replica in the us-east-1 Region.

Answer

To meet the requirements, the SysOps Administrator must enable S3 Versioning on both buckets and configure S3 Cross-Region Replication (CRR) to replicate the documents, and create an Amazon RDS PostgreSQL cross-region read replica in the us-east-1 Region.

To meet the 15-minute RPO for the documents, S3 Cross-Region Replication (CRR) must be used, which replicates new objects within minutes. CRR has a strict prerequisite that versioning must be enabled on both the source and destination buckets. To meet the 1-hour RPO for the database, an Amazon RDS cross-region read replica is appropriate because it replicates data asynchronously with very low lag. It can be promoted to a standalone master database during a disaster recovery event, which fits within the 4-hour RTO.

Step-by-Step Solution

Enable S3 Versioning on the source and destination S3 buckets, and configure S3 Cross-Region Replication (CRR).

Documents are replicated automatically to the secondary Region within minutes, satisfying the 15-minute RPO.

S3 CRR requires versioning to be enabled on both buckets to track object changes and replicate them asynchronously.

Deploy a cross-region read replica for the RDS PostgreSQL DB instance in the us-east-1 Region.

Database updates are replicated asynchronously to the secondary Region with typical lag of less than a few minutes, satisfying the 1-hour database RPO.

Cross-region read replicas provide continuous replication and can be promoted to primary databases during failover within the 4-hour RTO.

Key Concept

Implementing cross-region disaster recovery for stateful services using S3 Cross-Region Replication and RDS Cross-Region Read Replicas.

PreviousPage 36 / 49Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept