All practice questions

976 questions

All types976 Multiple choice502 Multiple select450 Ordering24

A SysOps administrator manages an Amazon EC2 Auto Scaling group (ASG) that hosts a batch processing application. The ASG is configured with a simple scaling policy that launches $2$ additional EC2 instances when average CPU utilization exceeds $80\%$ for a single $5$ -minute period. The policy has a cooldown period of $300$ seconds. During a high-load event, the average CPU utilization reaches $90\%$ and remains constant for $25$ minutes. The ASG successfully launches the first $2$ additional instances, but no further scaling actions occur despite the CPU utilization remaining at $90\%$ and the processing queue growing. Which action should the administrator take to ensure the ASG continues to scale out as long as the CPU utilization remains above the threshold?

Decrease the scaling policy's cooldown period to

60

seconds.

Enable detailed monitoring in the launch template and update the CloudWatch alarm to evaluate the CPU utilization metric at

1

-minute intervals.

Replace the simple scaling policy with a step scaling policy.

Configure an Amazon EventBridge rule that detects when the Auto Scaling policy execution status is successful, and use it to invoke an AWS Systems Manager Automation document that resets the alarm state.

Show answer & explanation

Answer: Replace the simple scaling policy with a step scaling policy.

Answer

Replace the simple scaling policy with a step scaling policy.

Replacing the simple scaling policy with a step scaling policy is the correct solution. Simple scaling policies are only triggered when the CloudWatch alarm changes its state (e.g., from OK to ALARM). If the metric remains continuously above the threshold, the alarm stays in the ALARM state and does not transition again, preventing further scaling actions. In contrast, step scaling policies can continuously evaluate metrics and perform scaling actions as long as the alarm is in the ALARM state and the instance warm-up periods have expired.

Step-by-Step Solution

Analyze the current Auto Scaling configuration and the observed behavior.

The ASG uses a simple scaling policy, which launches

2

instances initially but fails to scale out further when CPU utilization stays high at

90\%

Identify why simple scaling policies fail to trigger subsequent scaling activities when metrics remain elevated.

Understand the difference between simple scaling and step scaling trigger mechanisms.

Simple scaling policies are only executed when the CloudWatch alarm transitions into the ALARM state. Step scaling policies can execute multiple scaling actions as long as the metric remains in the ALARM state and the instance warm-up periods are respected.

Select the scaling policy type that supports continuous scaling under sustained load.

Select the correct action to modify the Auto Scaling group policy.

Replacing the simple scaling policy with a step scaling policy ensures that the group continues to scale out as long as CPU utilization remains above

80\%

Apply the correct AWS operational practice to resolve the scaling limitation.

Key Concept

Auto Scaling Simple vs. Step Scaling Policies

Question 182Question →

An application hosted on Amazon EC2 instances in an Auto Scaling group (ASG) processes traffic from an Application Load Balancer. The ASG is configured with a target tracking scaling policy based on average CPU utilization. During a sudden traffic spike, the CPU utilization increases significantly. The ASG launches a new batch of instances, but before these instances can complete their initialization and begin serving traffic, the scaling policy triggers another scale-out action. This results in the ASG launching more instances than necessary. Which action should the SysOps administrator take to resolve this issue?

Enable detailed CloudWatch monitoring for the EC2 instances in the launch template to reduce the metric collection interval to 1 minute.

Increase the default scale-in cooldown period of the Auto Scaling group to restrict the scaling policy from evaluating metrics during the initialization phase.

Configure an estimated instance warmup time on the scaling policy that is greater than the time required for the application to initialize.

Create an Amazon EventBridge rule that detects the EC2 Instance Launch Successful event and triggers an AWS Systems Manager Automation document to temporarily suspend the launch process of the Auto Scaling group.

Show answer & explanation

Answer: Configure an estimated instance warmup time on the scaling policy that is greater than the time required for the application to initialize.

Answer

Configure an estimated instance warmup time on the scaling policy that is greater than the time required for the application to initialize.

Configuring an estimated instance warmup ensures that newly launched instances are excluded from the Auto Scaling group's capacity calculations while they are booting up. This prevents the target tracking scaling policy from launching additional instances prematurely while the initial batch is still warming up.

Step-by-Step Solution

Identify the root cause of the overprovisioning, which is that the target tracking policy does not wait for the newly launched instances to become fully ready and begin processing traffic before recalculating capacity needs.

Confirm that the scaling policy evaluates the ASG metric including warming-up instances if their warm-up time is not configured or is set too low.

This establishes that the policy needs to be aware of the instance initialization period.

Evaluate the available parameters for target tracking policies, and locate the estimated instance warmup parameter, which determines how long an instance is considered to be in the warm-up phase.

Determine that adjusting the estimated instance warmup will exclude these warming-up instances from the scaling calculations.

This identifies the correct mechanism to pause scaling triggers during initialization.

Set the estimated instance warmup value to be slightly longer than the actual boot and initialization time of the application.

The target tracking policy now ignores the newly launched instances during their startup phase and avoids triggering additional premature scale-out events.

This resolves the overprovisioning issue cleanly without breaking scaling automation.

Key Concept

Auto Scaling group instance warm-up and target tracking policy evaluation logic.

Estimated Time:1m 30s

Question 183Question →

A SysOps administrator recently configured AWS CloudTrail to deliver event logs to an Amazon S3 bucket. However, when checking the S3 bucket, the administrator discovers that no CloudTrail logs are being delivered. Which of the following root causes could be responsible for this delivery failure? (Select TWO.)

Select all that apply

The S3 bucket policy does not grant the CloudTrail service principal permission to perform the PutObject action.

The AWS KMS key policy used to encrypt the S3 bucket or the logs does not grant the CloudTrail service principal permission to use the key.

The CloudWatch Log Group associated with the CloudTrail trail has a retention period configuration of zero days.

CloudWatch detailed monitoring is disabled on the S3 bucket, preventing it from receiving external log streams.

The SysOps administrator did not assign iam:PassRole permissions to the target S3 bucket policy.

Show answer & explanation

Answer: The S3 bucket policy does not grant the CloudTrail service principal permission to perform the PutObject action.; The AWS KMS key policy used to encrypt the S3 bucket or the logs does not grant the CloudTrail service principal permission to use the key.

Answer

The S3 bucket policy must grant 's3:PutObject' permissions to the CloudTrail service principal, and the AWS KMS key policy must grant permissions to the CloudTrail service principal to generate data keys for encryption.

For CloudTrail to deliver logs successfully, the destination S3 bucket policy must allow the CloudTrail service principal ('cloudtrail.amazonaws.com') to perform the 's3:PutObject' action. Additionally, if KMS encryption is configured, the key policy must grant 'cloudtrail.amazonaws.com' permissions to generate the data keys needed to encrypt the log objects before writing them.

Step-by-Step Solution

Check the S3 bucket policy.

Identify if the 'cloudtrail.amazonaws.com' service principal has been granted 's3:PutObject' access to the bucket.

CloudTrail requires explicit permission to write logs to the target S3 bucket.

Check the KMS key policy if KMS encryption is enabled.

Verify that 'cloudtrail.amazonaws.com' is allowed to perform 'kms:GenerateDataKey*' on the KMS key.

If the trail or S3 bucket is encrypted using a KMS key, CloudTrail needs permissions to generate encryption keys to write the encrypted files.

Key Concept

AWS CloudTrail requires permissions to write logs to an S3 bucket, which involves bucket policies and, if applicable, KMS key policies.

Estimated Time:1m 30s

Question 184Question →

A SysOps Administrator is setting up a CloudWatch billing alarm to monitor estimated monthly charges and send an email notification via Amazon SNS if they exceed a target budget. The administrator logs into the AWS Management Console, navigates to Amazon CloudWatch in the us-east-1 (US East - N. Virginia) region, but discovers that the EstimatedCharges metric is missing from the Billing namespace. What configuration change is required to make the EstimatedCharges metric visible in CloudWatch?

Create an Amazon EventBridge rule to route EstimatedCharges events from the Billing Dashboard to a CloudWatch log group as the primary event destination.

Enable the option to receive billing alerts in the Billing Preferences section of the AWS Billing and Cost Management console.

Enable detailed monitoring with a 1-minute interval for billing metrics within the AWS Billing and Cost Management console.

Configure a static alert in AWS Budgets, which automatically enables and publishes the EstimatedCharges metric to CloudWatch.

Show answer & explanation

Answer: Enable the option to receive billing alerts in the Billing Preferences section of the AWS Billing and Cost Management console.

Answer

Enable the option to receive billing alerts in the Billing Preferences section of the AWS Billing and Cost Management console.

The EstimatedCharges metric in the CloudWatch Billing namespace is only generated and populated after the user enables billing alerts in the Billing Preferences page of the AWS Billing and Cost Management console. Once this option is turned on, Billing data is published to CloudWatch, allowing the administrator to configure the alarm.

Step-by-Step Solution

Access the AWS Billing and Cost Management console and navigate to Billing Preferences.

Located the billing alert configuration options.

AWS does not publish estimated billing charges to CloudWatch by default; this setting must be explicitly enabled to initiate metric generation.

Enable the option to receive billing alerts.

AWS Billing begins sending estimated charges data to CloudWatch.

Enabling this preference triggers the collection and publication of the EstimatedCharges metric in the CloudWatch billing namespace.

Select the US East (N. Virginia) region in the CloudWatch console to find the EstimatedCharges metric.

The metric becomes visible under the Billing namespace in the us-east-1 region.

Billing metric data is stored only in the us-east-1 region, even if the resources and alarms are configured from other AWS accounts or regions.

Key Concept

Enabling and monitoring EstimatedCharges metrics in CloudWatch for billing alarms.

Estimated Time:1m 0s

Question 185Question →

A SysOps administrator is managing an asynchronous queue-processing application running on Amazon EC2 instances within an Auto Scaling group (ASG). The ASG has a minimum capacity of $0$ and a maximum capacity of $10$ . To scale dynamically based on the queue size of an Amazon SQS queue, the administrator configures a target tracking scaling policy using a custom CloudWatch metric named `BacklogPerInstance`. This metric is calculated as the queue's `ApproximateNumberOfMessages` divided by the ASG's running instance capacity.

During a period of inactivity, the ASG successfully scales down to $0$ instances. However, when a new batch of messages is sent to the SQS queue, the ASG fails to launch any instances, leaving the messages unprocessed.

Which of the following actions should the SysOps administrator take to resolve this issue and ensure the ASG can scale out from $0$ instances?

Configure an additional step scaling policy based on the queue's `ApproximateNumberOfMessages` metric to launch

1

instance when the message count is greater than

0

, while keeping the target tracking policy for subsequent scaling.

Update the custom metric collection script running on the EC2 instances to publish a default `BacklogPerInstance` value of

100

when the running instance capacity is

0

Enable detailed monitoring on the EC2 instances within the launch template and configure the target tracking policy's custom CloudWatch alarm evaluation period to

1

minute.

Modify the target tracking scaling policy configuration to set the estimated instance warmup to

0

seconds and decrease the scale-in cooldown period.

Show answer & explanation

Answer: Configure an additional step scaling policy based on the queue's `ApproximateNumberOfMessages` metric to launch $1$ instance when the message count is greater than $0$ , while keeping the target tracking policy for subsequent scaling.

Answer

Configure an additional step scaling policy based on the queue's `ApproximateNumberOfMessages` metric to launch

1

instance when the message count is greater than

0

, while keeping the target tracking policy for subsequent scaling.

A target tracking scaling policy requires a valid metric value to function. When an Auto Scaling group scales down to

0

instances, a custom metric representing per-instance backlog becomes mathematically undefined because of division by zero. To resolve this, a step scaling policy based on the absolute queue size (`ApproximateNumberOfMessages`) should be configured to scale the ASG from

0

1

instance. Once

1

instance is running, the backlog metric can be calculated, allowing the target tracking policy to manage subsequent scaling.

Step-by-Step Solution

Analyze the scaling behavior of a target tracking policy based on backlog per instance when instance capacity is at

0

The backlog per instance metric is calculated by dividing queue depth by the running instance count. With

0

instances running, the formula contains a division by zero. This makes the metric undefined in CloudWatch, preventing the target tracking policy from triggering a scale-out event.

To identify why the ASG fails to launch instances from a scaled-down state of

0

Design a method to transition the ASG from

0

1

instance when messages arrive.

A step scaling policy does not rely on a per-instance ratio and can scale based on the absolute `ApproximateNumberOfMessages` metric. Configuring it to add

1

instance when the queue size is

> 0

bypasses the division-by-zero issue.

To establish a reliable trigger that operates when no instances are running.

Integrate the step scaling policy with the target tracking policy for ongoing operation.

When the step scaling policy launches the first instance, the capacity becomes

1

. At this point, the backlog per instance metric becomes defined and measurable, allowing the target tracking policy to resume scaling out or scaling in based on target workload thresholds.

To combine the cost benefits of scaling to

0

with the responsiveness of target tracking scaling under load.

Key Concept

Auto Scaling Scale-to-Zero SQS Queue Mechanics

Question 186Question →

An Auto Scaling group is configured to scale out when CPU utilization exceeds 70%. During a traffic spike, a scale-out event is triggered. Arrange the operational steps in the correct chronological order from the initial metric alarm to the point where the new instance handles active client requests.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence starts with the CloudWatch alarm triggering the scale-out policy. Next, the Auto Scaling group provisions the new instance using the active launch template. Then, the instance is registered with the target group of the Application Load Balancer. Finally, the load balancer routes client traffic to the instance once it passes health checks.

The correct order follows the logical operational flow: an alarm triggers the policy, the instance is provisioned, registered with the load balancer target group, and finally, traffic is routed to it after passing health checks.

Step-by-Step Solution

Triggering the policy

The CloudWatch alarm alerts the Auto Scaling group that CPU utilization has exceeded the threshold, starting the scale-out process.

Monitoring metrics must detect the load breach before any scaling action is initiated.

Provisioning the instance

Auto Scaling calls the EC2 API to boot up a new instance based on the launch template.

An active virtual machine must exist before it can be registered to receive network traffic.

Registering with the target group

The instance is registered with the load balancer target group in an initial state.

Registration is required so the load balancer is aware of the new resource's existence and IP address.

Passing health checks and serving traffic

The load balancer sends health probes to the instance, marks it healthy, and starts routing client requests.

Traffic routing must be delayed until the application on the instance is fully initialized and passing health checks to avoid routing requests to a broken node.

Key Concept

Auto Scaling instance launch and registration lifecycle with Elastic Load Balancing.

Question 187Question →

A company is designing a disaster recovery (DR) strategy for a non-critical internal administration application. The business requires a Recovery Point Objective (RPO) of $24$ hours and a Recovery Time Objective (RTO) of $24$ hours. The primary objective is to minimize cost. Which of the following actions should a SysOps Administrator take to meet these requirements? (Choose two.)

Select all that apply

Configure AWS Backup to perform daily cross-region backups of the database to the secondary Region.

Store infrastructure definitions as AWS CloudFormation templates to provision the compute resources in the secondary Region only during a disaster recovery event.

Configure an Amazon RDS Read Replica in the secondary Region to provide automatic synchronous failover of the database layer.

Set up Amazon S3 Cross-Region Replication (CRR) for application assets without enabling S3 Versioning on either the source or destination buckets.

Configure an Amazon Route 53 active-active failover routing policy to route all traffic to the secondary Region even when the primary Region is fully healthy.

Show answer & explanation

Answer: Configure AWS Backup to perform daily cross-region backups of the database to the secondary Region.; Store infrastructure definitions as AWS CloudFormation templates to provision the compute resources in the secondary Region only during a disaster recovery event.

Answer

Configure AWS Backup to perform daily cross-region backups of the database to the secondary Region, and store infrastructure definitions as AWS CloudFormation templates to provision the compute resources in the secondary Region only during a disaster recovery event.

The correct options align with the Backup and Restore disaster recovery strategy. With an RTO and RPO of

24

hours, the company does not need warm resources running in the secondary Region. Using AWS Backup for daily cross-region replication ensures that database backups are under

24

hours old, meeting the RPO. Deploying resources on-demand using AWS CloudFormation templates during a disaster allows recovery well within the

24

-hour RTO while avoiding the cost of maintaining running compute capacity.

Step-by-Step Solution

Analyze the business requirements for RTO, RPO, and budget.

Identify that both RTO and RPO are

24

hours, and the primary driver is cost optimization, which points to a Backup and Restore disaster recovery strategy.

Determining the correct recovery strategy category limits the set of appropriate AWS services.

Evaluate options for the database tier that satisfy the

24

-hour RPO at minimal cost.

Select daily cross-region backups using AWS Backup because they satisfy the

24

-hour RPO without the high cost of active replication like read replicas or global databases.

Ensures the database recovery point meets business requirements without exceeding the cost envelope.

Evaluate compute and infrastructure provisioning options that satisfy the

24

-hour RTO at minimal cost.

Select AWS CloudFormation templates to provision resources on-demand during a failover event, avoiding running idle instances in the disaster recovery Region.

Ensures the compute resources can be deployed within the

24

-hour recovery window without incurring passive compute charges.

Key Concept

Disaster Recovery Strategies

Question 188Question →

A SysOps administrator is updating an Amazon EC2 Auto Scaling group (ASG) to launch instances with a new IAM role that provides access to an Amazon DynamoDB table. When the administrator attempts to update the ASG to use a new launch template version containing the new IAM role, the operation fails with a permission error stating that the user is not authorized to perform `iam:PassRole`.

Additionally, the application hosted on the ASG experiences sudden spikes in CPU utilization. The administrator notices that the dynamic scaling policy is slow to respond because the CPU utilization metric is only evaluated at 5-minute intervals.

Which two actions should the SysOps administrator take to resolve the launch template update failure and reduce the scaling response time? (Select TWO.)

Select all that apply

Attach an IAM policy to the administrator's IAM identity that grants the `iam:PassRole` permission for the Amazon Resource Name (ARN) of the new IAM role.

Enable detailed monitoring in the launch template, and configure the CloudWatch alarm used by the scaling policy to have an evaluation period of 60 seconds.

Modify the trust policy of the new IAM role to allow the Auto Scaling service principal (`autoscaling.amazonaws.com`) to assume the role.

Create a CloudWatch metric filter for CPU utilization, and set the metric evaluation period to 60 seconds.

Decrease the default cooldown period of the Auto Scaling group to 0 seconds to allow the alarm to evaluate metrics more frequently.

Show answer & explanation

Answer: Attach an IAM policy to the administrator's IAM identity that grants the `iam:PassRole` permission for the Amazon Resource Name (ARN) of the new IAM role.; Enable detailed monitoring in the launch template, and configure the CloudWatch alarm used by the scaling policy to have an evaluation period of 60 seconds.

Answer

Attach an IAM policy to the administrator's IAM identity that grants the `iam:PassRole` permission for the new IAM role, and enable detailed monitoring in the launch template while configuring the CloudWatch alarm used by the scaling policy to have a period of 60 seconds.

The correct options are to grant `iam:PassRole` to the administrator's identity and to enable detailed monitoring in the launch template while adjusting the alarm period. To attach an IAM role to EC2 instances, the user initiating the launch or template update must be authorized to pass the role. Standard EC2 monitoring only reports metrics every 5 minutes; enabling detailed monitoring increases the frequency to 1-minute intervals, allowing a 60-second CloudWatch alarm to trigger scaling actions much faster.

Step-by-Step Solution

Identify the cause of the `iam:PassRole` error.

The administrator's IAM user or role lacks permissions to pass the new IAM role to the EC2 service via the launch template.

AWS security requires that any identity that associates an IAM role with an AWS resource must have explicit `iam:PassRole` permissions for that role to prevent privilege escalation.

Resolve the permission issue.

Add an IAM policy to the administrator's IAM user or role granting `iam:PassRole` for the target role's ARN.

This allows the administrator to successfully update the Auto Scaling group's launch template version.

Identify the cause of the 5-minute metric evaluation delay.

EC2 instances by default report standard CPU utilization metrics at 5-minute intervals.

Standard monitoring provides metric resolution at 5-minute intervals. To react within 1-minute intervals, detailed monitoring must be enabled.

Enable detailed monitoring and adjust the alarm.

Enable detailed monitoring in the launch template and configure the alarm to use a 60-second period.

Detailed monitoring publishes CPU utilization metrics at 1-minute intervals. Setting the CloudWatch alarm period to 60 seconds aligns the evaluation frequency with the new data frequency.

Key Concept

Auto Scaling Instance Configuration and CloudWatch Metric Resolution

Question 189Question →

A SysOps Administrator is setting up a new production database on Amazon RDS for PostgreSQL. The database must be highly available and support automatic failover to a standby instance in the event of an infrastructure failure or Availability Zone outage. Which configuration will meet these requirements?

Enable Multi-AZ deployment for the Amazon RDS database instance.

Deploy an Amazon RDS Read Replica in a different Availability Zone within the same AWS Region.

Deploy an Amazon RDS Read Replica in a different AWS Region and enable cross-region replication.

Configure an Amazon Route 53 failover routing policy pointing to a primary and secondary read replica.

Show answer & explanation

Answer: Enable Multi-AZ deployment for the Amazon RDS database instance.

Answer

Enable Multi-AZ deployment for the Amazon RDS database instance.

Enabling Multi-AZ deployment is the correct configuration. It creates a synchronous standby replica in a separate Availability Zone. If the primary instance fails or its Availability Zone becomes unavailable, Amazon RDS automatically modifies the CNAME record of the DB instance to point to the standby replica, providing high availability with zero manual intervention.

Step-by-Step Solution

Identify the high availability and automatic failover requirements for the Amazon RDS database.

The requirement demands synchronous failover to a standby instance with minimal downtime during an Availability Zone outage.

This determines the choice between Multi-AZ (synchronous HA) and Read Replicas (asynchronous scalability).

Evaluate Amazon RDS features that support synchronous replication and automated failover.

RDS Multi-AZ deployments provide synchronous replication and automatic DNS-based failover, whereas Read Replicas are asynchronous and require manual promotion.

To select the configuration that handles failover automatically without manual promotion or DNS updates.

Key Concept

Amazon RDS Multi-AZ deployments provide automatic failover and high availability by maintaining a synchronous standby replica in a different Availability Zone, whereas Read Replicas are for scalability and use asynchronous replication.

Estimated Time:45s

Question 190Question →

An organization trail is deployed in a management account to aggregate logs from all member accounts into a central Amazon S3 bucket within a dedicated audit account. To meet security standards, log encryption is enabled using a customer managed AWS KMS key. The deployment succeeds, but the SysOps administrator notices that no CloudTrail logs are appearing in the destination S3 bucket.

Which configurations must be verified and corrected to enable successful log delivery? (Select TWO.)

Select all that apply

The S3 bucket policy in the audit account must include a statement permitting the CloudTrail service principal:

{
"Sid": "AWSCloudTrailWrite",
"Effect": "Allow",
"Principal": {"Service": "cloudtrail.amazonaws.com"},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::audit-logs-bucket/AWSLogs/o-orgid/*",
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}

The KMS key policy must include a statement allowing the CloudTrail service principal to generate data keys:

{
"Sid": "Allow CloudTrail to encrypt logs",
"Effect": "Allow",
"Principal": {"Service": "cloudtrail.amazonaws.com"},
"Action": [
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
}

The S3 bucket policy in the audit account must include a statement allowing the management account's root principal:

{
"Sid": "AllowManagementAccountWrite",
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::111122223333:root"},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::audit-logs-bucket/*"
}

The IAM policy attached to the user or role executing the trail creation must include the following permissions:

{
"Sid": "AllowCloudTrailKMSEncrypt",
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-id"
}

The member accounts must assign an IAM policy to the CloudTrail service principal with iam:PassRole permissions to allow the management account to assume a logging role:

{
"Sid": "AllowPassRoleForCloudTrail",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::*:role/CloudTrailLoggingRole"
}

Show answer & explanation

Answer: The S3 bucket policy in the audit account must include a statement permitting the CloudTrail service principal:

{
"Sid": "AWSCloudTrailWrite",
"Effect": "Allow",
"Principal": {"Service": "cloudtrail.amazonaws.com"},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::audit-logs-bucket/AWSLogs/o-orgid/*",
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}
; The KMS key policy must include a statement allowing the CloudTrail service principal to generate data keys:

{
"Sid": "Allow CloudTrail to encrypt logs",
"Effect": "Allow",
"Principal": {"Service": "cloudtrail.amazonaws.com"},
"Action": [
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
}

Answer

To allow CloudTrail to deliver logs, configure the destination S3 bucket policy to permit the cloudtrail.amazonaws.com service principal to write to the organization-specific path, and modify the customer managed KMS key policy to permit the same service principal to execute kms:GenerateDataKey* and kms:DescribeKey.

The correct configurations involve setting resource-based access permissions. First, the S3 bucket policy must allow the CloudTrail service principal to perform `s3:PutObject` on the organization prefix. Second, the KMS key policy must authorize the CloudTrail service principal to perform `kms:GenerateDataKey*` and `kms:DescribeKey` so it can encrypt logs at the destination.

Step-by-Step Solution

Inspect the destination S3 bucket policy in the dedicated audit account.

Ensure a policy statement exists that allows cloudtrail.amazonaws.com to execute s3:PutObject for the resource path prefix AWSLogs/o-organizationid/.

For an organization trail, logs are organized by the organization ID, and CloudTrail requires write permissions to this specific path.

Ensure the S3 bucket policy statement enforces the bucket-owner-full-control ACL constraint.

Add a condition statement evaluating s3:x-amz-acl to bucket-owner-full-control.

CloudTrail requires this access control list to ensure the destination bucket owner has full control over the delivered logs.

Examine the KMS key policy for the customer managed key used by the trail.

Grant the cloudtrail.amazonaws.com service principal permissions for kms:GenerateDataKey* and kms:DescribeKey.

Because CloudTrail writes and encrypts logs asynchronously, the service principal itself must have permissions to generate data keys using the customer managed key.

Key Concept

CloudTrail multi-account log delivery requires resource-based policy configurations for S3 and KMS to authorize the CloudTrail service principal.

Question 191Question →

A technology company implements compliance monitoring using AWS Config. The security team deploys a conformance pack containing a custom Config rule that monitors security group configurations. The conformance pack template specifies an automatic remediation configuration that calls a custom Systems Manager (SSM) Automation document to modify non-compliant security groups. The Config remediation execution configuration uses a dedicated IAM role (ConfigRemediationRole) to initiate the remediation. The custom SSM Automation document contains a parameter AutomationAssumeRole, which requires passing a separate IAM role (SSMExecutionRole) to perform the actual resource modifications. Although AWS Config marks the security groups as non-compliant, the automated remediation consistently fails to execute. The execution logs show that the Config remediation role is unable to trigger the SSM Automation. Which action must the administrator take to resolve this issue?

Update the trust policy of the SSMExecutionRole to allow the config.amazonaws.com service principal to assume it.

Create an Amazon EventBridge rule that triggers on AWS Config compliance change events and targets the SSMExecutionRole to run the automation.

Attach an IAM policy to the ConfigRemediationRole that grants the iam:PassRole permission for the SSMExecutionRole.

Attach a policy to the AWS Config service-linked role that grants the sts:AssumeRole permission on the SSMExecutionRole.

Show answer & explanation

Answer: Attach an IAM policy to the ConfigRemediationRole that grants the iam:PassRole permission for the SSMExecutionRole.

Answer

Attach an IAM policy to the ConfigRemediationRole that grants the iam:PassRole permission for the SSMExecutionRole.

The correct action is to grant iam:PassRole permissions for the SSM execution role to the Config remediation role. When AWS Config triggers the Systems Manager Automation, the Config remediation role must pass the SSM execution role to the Systems Manager service so that Systems Manager can assume it and run the automation steps. Without iam:PassRole permissions, the API call to start the automation fails because the caller does not have permission to delegate the role.

Step-by-Step Solution

Identify the service delegation boundary in AWS Config automatic remediation.

Recognize that AWS Config assumes the configured remediation role (ConfigRemediationRole) to initiate the Systems Manager Automation document.

To understand which IAM entity initiates the API call and where permissions must be configured.

Analyze the role of AutomationAssumeRole inside the SSM document execution.

Determine that the ConfigRemediationRole must pass the SSMExecutionRole to the Systems Manager service during the StartAutomationExecution API call.

Systems Manager needs to assume SSMExecutionRole to execute the steps, requiring a delegation permission from the caller.

Apply the iam:PassRole permission requirement.

Formulate an IAM policy granting iam:PassRole on SSMExecutionRole and attach it to the ConfigRemediationRole.

An AWS service principal cannot assume or use a role passed by an API caller unless the caller's IAM entity is explicitly permitted to pass that role.

Key Concept

Delegating IAM roles to AWS Services using PassRole in Config Remediation

Alternative Method

Instead of passing a separate execution role, you can grant the ConfigRemediationRole direct permissions to modify the security group and omit the AutomationAssumeRole parameter in the SSM document. However, using a dedicated execution role for SSM remains the best practice for principal separation.

Estimated Time:3m 0s

Question 192Question →

A SysOps administrator needs to update the Amazon Machine Image (AMI) for all Amazon EC2 instances in an Auto Scaling group (ASG) with minimal downtime. The administrator decides to use the ASG Instance Refresh feature.

Arrange the steps in the correct chronological order to successfully execute this rolling update.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations is: First, update the Auto Scaling group configuration to reference the new launch template version. Second, start the instance refresh process. Third, terminate a batch of instances running the old version while keeping the active count above the minimum healthy percentage. Fourth, launch replacement instances using the new version and verify their health. Fifth, repeat the process for the remaining old instances. Finally, transition the refresh status to Successful.

The correct order of steps ensures that the Auto Scaling group is updated with the new configuration first, so that the subsequent instance refresh knows the target state. The refresh then terminates and replaces instances in batches to maintain application availability, verifying the health of each batch before proceeding, and finally completing the process.

Step-by-Step Solution

Update the Auto Scaling group configuration to point to the new launch template version.

The target configuration for the group is set to the new template containing the updated AMI.

The instance refresh uses the group's currently associated launch template version to determine which instances need to be replaced.

Start the instance refresh process.

The rolling replacement workflow is initialized on the Auto Scaling group.

Starting the refresh tells Auto Scaling to begin the rolling update to match the newly associated launch template version.

Terminate a subset of instances running the old launch template version.

A batch of old instances is terminated while maintaining the minimum healthy percentage.

This ensures that the application retains enough active capacity to handle traffic during the update.

Launch replacement instances using the new launch template version and verify their health.

New instances are brought online and registered as healthy.

The rolling update cannot proceed to the next batch until the current replacement batch is verified healthy.

Repeat the termination and replacement steps for the remaining old instances.

The remaining old instances are replaced in subsequent batches.

This completes the rolling update across the entire Auto Scaling group.

Verify all instances are running the new launch template version and transition status.

The instance refresh status becomes Successful.

This marks the successful completion of the rolling update.

Key Concept

Auto Scaling Group Instance Refresh

Question 193Question →

A SysOps Administrator is configuring monitoring for a serverless application where AWS Lambda functions write JSON-formatted log events to an Amazon CloudWatch Logs log group. The administrator creates a metric filter with the pattern { $.level = "ERROR" } to count database connection failures. When errors occur, a custom metric named DatabaseFailures is incremented. The administrator also configures a CloudWatch alarm to alert the operations team if the count of errors is 5 or more within a 5-minute period. During normal operations, no database connection errors occur, and no log events are written to the log group at all, causing the alarm to enter the INSUFFICIENT_DATA state. Which combination of actions will prevent the alarm from entering the INSUFFICIENT_DATA state during periods of zero errors while maintaining accurate alerting behavior?

Enable detailed monitoring for the log group to force CloudWatch to evaluate the metric filter at 1-minute intervals, and adjust the alarm threshold to evaluate 1 period instead of 5 periods.

Configure an Amazon EventBridge rule that detects the INSUFFICIENT_DATA state and triggers a Systems Manager Automation document to write dummy log events to the log group.

Remove the log group retention limit by setting it to 'Never Expire' to ensure that historic log metrics are permanently available, and increase the alarm's evaluation periods to 24 hours.

Set the default value of the metric filter's metric transformation to 0, and configure the CloudWatch alarm's missing data treatment to treat missing data as notBreaching.

Show answer & explanation

Answer: Set the default value of the metric filter's metric transformation to 0, and configure the CloudWatch alarm's missing data treatment to treat missing data as notBreaching.

Answer

Set the default value of the metric filter's metric transformation to 0, and configure the CloudWatch alarm's missing data treatment to treat missing data as notBreaching.

Setting the default value of the metric filter's metric transformation to 0 ensures that if log events are ingested into the log group but do not match the error pattern, a value of 0 is reported to CloudWatch. However, if there is absolutely no traffic and no log events are sent to the log group at all, the metric filter is not evaluated, and no metric data is reported. To handle this second scenario, the CloudWatch alarm must be configured to treat missing data as notBreaching (good), which keeps the alarm in the OK state rather than INSUFFICIENT_DATA.

Step-by-Step Solution

Analyze the log ingestion behavior during zero-traffic periods.

No log events are sent to the CloudWatch Logs log group during these periods.

Understanding the source of the missing data is necessary to determine why the metric filter is not reporting metrics.

Evaluate the metric filter's default value configuration.

Setting the default value to 0 ensures that 0 is reported when log events are written but do not match the filter, but it does not report data if no logs are written at all.

A metric filter is only evaluated when log events are ingested; if there are no logs, no metric data is published.

Determine the necessary configuration on the CloudWatch alarm.

Configure the alarm to treat missing data as 'notBreaching' (good).

This prevents the alarm from entering the 'INSUFFICIENT_DATA' state when no metric data points are reported due to a complete lack of log ingestion.

Key Concept

Handling missing data in CloudWatch alarms generated by metric filters when log ingestion stops.

Question 194Question →

A SysOps administrator manages an Amazon EC2 Auto Scaling group (ASG) that uses a target tracking scaling policy based on the Average CPU Utilization metric. The ASG has a scale-out lifecycle hook (InstanceLaunching) configured to run a custom security scanning script on new instances using AWS Systems Manager (SSM) Automation.

During a sudden increase in traffic, the administrator observes the following behavior:
- The ASG launches redundant batches of instances every few minutes before the previous instances complete the security scan, leading to significant over-provisioning.
- The SSM Automation fails to run on the newly launched instances, causing the lifecycle hook to eventually time out and terminate the instances.

Which actions should the administrator take to resolve these issues? (Select TWO.)

Select all that apply

Increase the estimated instance warmup time on the target tracking scaling policy to exceed the combined duration of the instance boot time and the lifecycle hook execution.

Add the iam:PassRole permission for the EC2 instance profile role to the IAM execution role used by the Systems Manager Automation runbook.

Increase the default cooldown period of the Auto Scaling group to prevent the target tracking policy from launching new instances while others are in the hook state.

Enable detailed monitoring in the Auto Scaling group launch template to reduce the CloudWatch metric collection interval to 1 minute, allowing the target tracking policy to stabilize faster.

Replace the Systems Manager Automation target with an AWS Config remediation rule triggered by an Amazon EventBridge rule when the instance state changes to running.

Show answer & explanation

Answer: Increase the estimated instance warmup time on the target tracking scaling policy to exceed the combined duration of the instance boot time and the lifecycle hook execution.; Add the iam:PassRole permission for the EC2 instance profile role to the IAM execution role used by the Systems Manager Automation runbook.

Answer

To resolve these issues, the administrator must increase the estimated instance warmup time on the target tracking scaling policy and add the iam:PassRole permission to the Systems Manager Automation execution role.

To prevent over-provisioning during scaling, the estimated instance warmup must be set to a value higher than the boot and configuration time of the instances. This ensures the scaling policy excludes the warming-up instances from the scaling calculation until they are ready. Additionally, the Systems Manager Automation role requires the iam:PassRole permission to associate the IAM instance profile role with the EC2 instances during runbook execution.

Step-by-Step Solution

Analyze why the target tracking policy is launching redundant instances during scale-out.

The target tracking policy uses the estimated instance warmup period to exclude newly launched instances from contributing to the group's metric calculations. Since the default warmup is shorter than the time the instance takes to boot and complete the lifecycle hook, the policy continues scaling out.

Increasing the warmup period prevents the policy from triggering additional scaling actions until the instances are fully initialized.

Identify why Systems Manager Automation is failing to run on the instances.

The automation role requires permission to associate the target instance profile with the EC2 instances. Without this permission, the execution fails.

Adding the iam:PassRole permission allows the Systems Manager Automation role to pass the instance profile role to the EC2 instances.

Key Concept

Auto Scaling target tracking policies utilize an estimated instance warmup period to suppress redundant scale-out events. Furthermore, automated configurations integrating with EC2 launch tasks must have correct iam:PassRole permissions to operate on behalf of the user.

Question 195Question →

A SysOps Administrator is configuring automated remediation to restart an AWS CloudTrail trail if it is stopped. The administrator creates an Amazon EventBridge rule that triggers on the `StopLogging` API call. The target of this rule is set to trigger an AWS Systems Manager Automation execution of the `AWS-ConfigureCloudTrail` document. The administrator configures the target to use an IAM service role named `SSMAutomationExecutionRole`, which has the necessary `cloudtrail:StartLogging` permissions and a trust policy allowing `ssm.amazonaws.com` to assume it. When the rule is triggered, the automation fails to start, and the EventBridge dead-letter queue reports an authorization error. Which configuration change will resolve this issue?

Modify the central logging Amazon S3 bucket policy to grant the `s3:PutObject` permission to the EventBridge service principal (events.amazonaws.com).

Reconfigure the EventBridge rule to target an Amazon SNS topic, and subscribe the Systems Manager Automation document directly to the SNS topic to trigger remediation.

Attach an IAM policy to the role used by the EventBridge rule to execute the target, granting the `iam:PassRole` permission for the `SSMAutomationExecutionRole` ARN.

Modify the trust policy of the `SSMAutomationExecutionRole` to allow the EventBridge service principal (events.amazonaws.com) to assume the role instead of Systems Manager.

Show answer & explanation

Answer: Attach an IAM policy to the role used by the EventBridge rule to execute the target, granting the `iam:PassRole` permission for the `SSMAutomationExecutionRole` ARN.

Answer

Attach an IAM policy to the role used by the EventBridge rule to execute the target, granting the `iam:PassRole` permission for the `SSMAutomationExecutionRole` ARN.

The correct action is to attach an IAM policy to the role used by the EventBridge rule to execute the target, granting the `iam:PassRole` permission for the `SSMAutomationExecutionRole` ARN. When Amazon EventBridge triggers an AWS Systems Manager Automation that runs using a customer-specified execution role, the principal triggering the event must have permission to pass that role to Systems Manager. The `iam:PassRole` permission ensures that the EventBridge service is authorized to delegate the specified execution role to Systems Manager.

Step-by-Step Solution

Identify the service relationship and the delegation of authority required for EventBridge to trigger Systems Manager Automation.

EventBridge needs to invoke Systems Manager Automation and pass a specific runtime role (SSMAutomationExecutionRole) to the Systems Manager service.

When a service like EventBridge triggers an automation that runs under a specified role, the calling service must be permitted to pass that role to the target service.

Verify the permissions of the IAM role used by the EventBridge rule.

The EventBridge rule's role is missing the `iam:PassRole` permission for the targeted `SSMAutomationExecutionRole` ARN.

Without `iam:PassRole` on the calling identity, AWS prevents the identity from delegating the execution role to another service, resulting in an authorization failure.

Attach a policy to the EventBridge execution role containing the `iam:PassRole` permission for the SSM role's ARN.

The EventBridge rule is now authorized to pass the role, and the Systems Manager Automation executes successfully when the rule is triggered.

This establishes the secure delegation required for EventBridge to pass the execution role to Systems Manager.

Key Concept

Delegating IAM roles to AWS services using the PassRole permission during event-driven automated remediation.

Estimated Time:1m 30s

Question 196Question →

A fleet of Amazon EC2 instances is managed by an Auto Scaling group that uses target tracking based on average CPU utilization. The application hosted on these instances takes approximately 6 minutes to complete its boot sequence and begin serving traffic. During scale-out events, the Auto Scaling group launches multiple waves of redundant instances before the first new instance can actively handle requests, resulting in temporary over-provisioning. Which configuration change will address this issue?

Increase the default cooldown period of the Auto Scaling group to 360 seconds.

Enable detailed monitoring in the Auto Scaling group launch template to send EC2 metrics at 1-minute intervals.

Increase the estimated instance warmup time in the target tracking policy to at least 360 seconds.

Create an Amazon EventBridge rule that triggers an AWS Systems Manager Automation document to suspend the Launch process during scaling events.

Show answer & explanation

Answer: Increase the estimated instance warmup time in the target tracking policy to at least 360 seconds.

Answer

Increase the estimated instance warmup time in the target tracking policy to at least 360 seconds.

Increasing the estimated instance warmup time in the target tracking policy to at least 360 seconds ensures that the Auto Scaling group does not launch additional instances while the recently launched instances are bootstrapping. During the warmup period, instances are not counted toward the average metrics of the Auto Scaling group, preventing the policy from triggering further scale-out events prematurely.

Step-by-Step Solution

Analyze the scaling behavior and policy type.

The Auto Scaling group uses a target tracking scaling policy, and the application initialization delay is approximately 6 minutes (360 seconds).

Target tracking scaling policies evaluate metrics continuously but need to know how long a newly launched instance takes to warm up before contributing to the group's aggregate metrics.

Identify the parameter that controls metric aggregation timing for new instances.

The target tracking policy uses the estimated instance warmup parameter, which pauses further scale-out evaluations for the newly launched instance during its initialization.

Adjusting the default cooldown has no effect on target tracking policies, and changing monitoring frequency does not stop premature scaling.

Configure the estimated instance warmup parameter to cover the bootstrap period.

Setting the estimated instance warmup to 360 seconds or more prevents the target tracking policy from launching redundant instances during the 6-minute boot phase.

This stabilizes the scaling process and avoids over-provisioning.

Key Concept

Auto Scaling target tracking and estimated instance warmup configuration

Estimated Time:1m 30s

Question 197Question →

A SysOps administrator is setting up an active-passive failover configuration in Amazon Route 53. The primary resource record set points to an Application Load Balancer, and the secondary resource record set points to an Amazon S3 static website. What configuration is required on the primary resource record set to enable Route 53 to automatically redirect traffic to the secondary record during an outage?

A CloudWatch alarm configured for 1-minute detailed monitoring associated with a CloudWatch metric filter.

A Route 53 health check that monitors the primary endpoint and has the DNS record's 'Evaluate Target Health' option set to Yes.

A Route 53 weighted routing policy with the primary record set to a weight of 0 and the secondary record set to a weight of 100.

An Amazon RDS Read Replica designated as the failover target within the Route 53 routing policy.

Show answer & explanation

Answer: A Route 53 health check that monitors the primary endpoint and has the DNS record's 'Evaluate Target Health' option set to Yes.

Answer

A Route 53 health check that monitors the primary endpoint and has the DNS record's 'Evaluate Target Health' option set to Yes.

To set up active-passive failover, Amazon Route 53 needs a way to detect whether the primary resource is healthy. Associating a Route 53 health check with the primary resource record set and enabling 'Evaluate Target Health' ensures Route 53 regularly checks the health of the Application Load Balancer and redirects queries to the S3 bucket if the ALB becomes unhealthy.

Step-by-Step Solution

Identify the primary and secondary endpoints in the active-passive failover configuration.

The primary endpoint is the Application Load Balancer, and the secondary endpoint is the Amazon S3 static website.

This establishes which resource should handle normal traffic and where traffic should flow if that resource becomes unhealthy.

Determine the mechanism Route 53 uses to dynamically detect endpoint failures.

Route 53 uses health checks associated with resource record sets to determine endpoint health.

Without an associated health check, Route 53 cannot determine whether a resource is healthy and will continue routing traffic to it indefinitely.

Identify the record setting that enables evaluation of the load balancer's target health.

Setting 'Evaluate Target Health' to Yes on the Alias record set points Route 53 to the health of the underlying load balancer targets.

This configuration integrates Route 53 directly with the ELB health checks, enabling faster failover.

Key Concept

Active-passive DNS failover in Amazon Route 53 requires associating a health check with the primary record, and for Alias records, configuring 'Evaluate Target Health' to Yes to track the endpoint availability.

Question 198Question →

A SysOps Administrator needs to configure an Amazon RDS DB instance to ensure automatic failover to a synchronous standby instance in a different Availability Zone during an outage. Which RDS configuration meets this requirement?

Multi-AZ DB deployment

RDS Read Replicas in a different Availability Zone

Amazon Route 53 active-passive failover routing policy pointing to a separate standalone DB instance

Cross-Region database replication to another AWS Region

Show answer & explanation

Answer: Multi-AZ DB deployment

Answer

Multi-AZ DB deployment

The correct option is the Multi-AZ DB deployment because it synchronously replicates data to a standby instance in a different Availability Zone. In the event of an infrastructure failure or primary database outage, Amazon RDS automatically performs a failover to the standby instance by updating the DNS record, ensuring high availability with zero manual intervention.

Step-by-Step Solution

Identify the high availability requirement.

The requirement specifies automated database-tier failover to a synchronous standby instance in a different Availability Zone with zero manual intervention.

This limits the potential solutions to AWS services that support synchronous database replication and automated failover.

Compare RDS Multi-AZ deployments with Read Replicas.

Multi-AZ deployments perform synchronous replication and automatic DNS-level failover to a standby. Read Replicas perform asynchronous replication and require manual promotion to become the primary instance.

Differentiating these replication and failover mechanisms is key to selecting the highly available solution.

Evaluate the DNS-level alternative.

Route 53 active-passive failover routing policies manage traffic routing at the DNS layer but do not configure database synchronization, making them insufficient on their own for database-tier high availability.

This rules out DNS-only failover configurations as a primary database replication solution.

Key Concept

Amazon RDS Multi-AZ deployments provide high availability and failover support for DB instances by synchronously replicating data to a standby instance in a different Availability Zone.

Estimated Time:45s

Question 199Question →

A company runs a critical web application in the us-east-1 Region. The application's stateful data is stored in an Amazon RDS for PostgreSQL DB instance. The SysOps administrator is designing a pilot light disaster recovery (DR) strategy in the us-west-2 Region. The business requires a Recovery Point Objective (RPO) of 15 minutes and a Recovery Time Objective (RTO) of 2 hours. Which combination of actions should the SysOps administrator perform to meet these requirements at the lowest cost? (Select TWO.)

Select all that apply

Create a cross-region read replica of the RDS for PostgreSQL DB instance in us-west-2 to achieve the required recovery point objective (RPO).

Configure an Amazon Route 53 failover routing policy with a primary record pointing to us-east-1 and a secondary record pointing to us-west-2, and associate a Route 53 health check with the primary record.

Configure Route 53 to point to the cross-region read replica as a secondary endpoint, and rely on Amazon RDS to automatically promote the read replica to a primary database and redirect write traffic when Route 53 fails over.

Configure an Amazon Route 53 failover routing policy with a primary record pointing to us-east-1 and a secondary record pointing to us-west-2, without associating a health check, as Route 53 automatically fails over when the primary endpoint is unreachable.

Set up Amazon S3 Cross-Region Replication (CRR) to replicate application backup files from a source bucket in us-east-1 to a destination bucket in us-west-2 without enabling bucket versioning on either bucket.

Show answer & explanation

Answer: Create a cross-region read replica of the RDS for PostgreSQL DB instance in us-west-2 to achieve the required recovery point objective (RPO).; Configure an Amazon Route 53 failover routing policy with a primary record pointing to us-east-1 and a secondary record pointing to us-west-2, and associate a Route 53 health check with the primary record.

Answer

Create a cross-region read replica of the RDS for PostgreSQL DB instance in us-west-2, and configure an Amazon Route 53 failover routing policy with a primary record pointing to us-east-1 and a secondary record pointing to us-west-2, associating a Route 53 health check with the primary record.

The correct actions are to create an Amazon RDS cross-region read replica in the disaster recovery region and configure a Route 53 failover routing policy with a health check on the primary record. The cross-region read replica keeps the data synchronized asynchronously, ensuring the Recovery Point Objective (RPO) of 15 minutes is met. During failover, the replica is promoted to a primary database. Setting up Route 53 failover routing with a health check ensures that traffic is dynamically redirected to the secondary region when the primary region becomes unhealthy, supporting the 2-hour Recovery Time Objective (RTO).

Step-by-Step Solution

Analyze the RPO and RTO requirements to determine the database replication mechanism.

The 15-minute RPO cannot be reliably met with daily snapshots. A cross-region read replica is required to provide near real-time asynchronous data replication to us-west-2.

Asynchronous cross-region replication ensures that data loss remains under 15 minutes during a disaster.

Determine the DNS routing mechanism for traffic failover.

Route 53 failover routing is chosen, pointing to us-east-1 as primary and us-west-2 as secondary.

This active-passive DNS configuration allows automated routing redirection when a regional failure occurs.

Configure the required Route 53 health check and associate it with the primary record.

A Route 53 health check is created to monitor the health of the us-east-1 endpoint and attached to the primary record.

Without an associated health check, Route 53 cannot detect a primary region outage and will not execute the failover routing policy.

Key Concept

Disaster Recovery strategies (specifically Pilot Light / Warm Standby database replication and Route 53 failover routing configuration).

Question 200Question →

A company has a Single-AZ Amazon RDS MySQL DB instance and wants to improve its reliability. A SysOps Administrator plans to convert this instance into a Multi-AZ deployment. Which of the following statements correctly describe the behavior or configuration of this transition? (Select TWO.)

Select all that apply

Modifying the DB instance to enable Multi-AZ automatically provisions a synchronous standby replica in a different Availability Zone.

Amazon RDS automatically updates the DNS CNAME record of the DB instance to point to the standby instance during a failover.

The newly created standby replica can be immediately used to serve read-only queries to offload the primary database.

A read replica must be manually promoted to primary and the application's connection endpoints updated to achieve failover.

A Route 53 active-active failover routing policy must be manually configured to route traffic to the standby database instance.

Show answer & explanation

Answer: Modifying the DB instance to enable Multi-AZ automatically provisions a synchronous standby replica in a different Availability Zone.; Amazon RDS automatically updates the DNS CNAME record of the DB instance to point to the standby instance during a failover.

Answer

Modifying the DB instance to enable Multi-AZ automatically provisions a synchronous standby replica in a different Availability Zone, and Amazon RDS automatically updates the DNS CNAME record of the DB instance to point to the standby instance during a failover.

When converting a Single-AZ instance to a Multi-AZ deployment, Amazon RDS automatically creates a synchronous standby replica in a different Availability Zone. If a failure occurs, RDS automatically switches to the standby replica by updating the DNS CNAME record of the DB endpoint. This keeps the database endpoint URL unchanged, requiring no code modifications in the application.

Step-by-Step Solution

Identify the high availability replication model for standard RDS Multi-AZ.

RDS Multi-AZ uses synchronous replication to a standby instance in a different Availability Zone.

This guarantees zero data loss up to the point of synchronous write completion and enables failover capability.

Determine how failover is handled from the networking and DNS perspective.

Amazon RDS automatically updates the DNS CNAME record to point to the standby instance.

This maintains the same database endpoint for the client application and minimizes operational intervention.

Key Concept

Amazon RDS Multi-AZ deployments provide high availability and failover support natively by synchronously replicating data to a standby instance in a different Availability Zone and automatically updating the endpoint's DNS CNAME record during failovers.

PreviousPage 10 / 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

Alternative Method

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