Reliability and Business Continuity

153 questions

All types153 Multiple choice80 Multiple select63 Ordering10

A SysOps Administrator is configuring cross-account, cross-region replication for an Amazon S3 bucket. The source bucket is in Account A (us-east-1) and contains objects encrypted with an AWS KMS customer managed key. The destination bucket is in Account B (us-west-2). The administrator has enabled versioning on the source bucket, created the replication configuration in Account A, and specified a new replication IAM role in Account A. However, the replication is failing, and no objects are appearing in the destination bucket. Which two actions must the administrator take to successfully replicate the KMS-encrypted objects?

Select all that apply

Enable bucket versioning on the destination bucket in Account B.

Modify the KMS key policy in Account B to grant the replication IAM role from Account A permissions to perform kms:GenerateDataKey and kms:Encrypt actions.

Modify the replication IAM role in Account A to include iam:PassRole permissions targeting the S3 replication service principal.

Associate the destination bucket's subnet route table in Account B with an S3 Gateway Endpoint to authorize cross-account replication traffic.

Configure the replication rule to use the default AWSServiceRoleForS3Replication service-linked role to automatically inherit permissions for cross-account KMS key access.

Show answer & explanation

Answer: Enable bucket versioning on the destination bucket in Account B.; Modify the KMS key policy in Account B to grant the replication IAM role from Account A permissions to perform kms:GenerateDataKey and kms:Encrypt actions.

Answer

Enable bucket versioning on the destination bucket in Account B, and modify the KMS key policy in Account B to grant the replication IAM role from Account A permissions to perform kms:GenerateDataKey and kms:Encrypt actions.

Replicating KMS-encrypted objects across accounts requires S3 versioning to be enabled on both the source and destination buckets, as S3 replication requires versioning to track and sync objects. Additionally, the replication IAM role in Account A must have permissions to encrypt objects in the destination bucket using Account B's KMS key. This is accomplished by updating the KMS key policy in Account B to grant kms:GenerateDataKey and kms:Encrypt permissions to the replication role in Account A.

Step-by-Step Solution

Enable versioning on the destination bucket in Account B.

Meets the core prerequisite that both source and destination buckets in an S3 replication setup must have versioning enabled.

S3 replication relies on versioning metadata to track and sync object states, so replication will fail if the destination bucket lacks versioning.

Update the KMS key policy for the destination key in Account B.

Grants the replication IAM role (from Account A) permission to encrypt objects at the destination using Account B's KMS key.

Since the replication role resides in Account A, the cross-account KMS key policy in Account B must explicitly permit that role to call kms:Encrypt and kms:GenerateDataKey.

Key Concept

Amazon S3 Cross-Account Replication with KMS Encryption

Question 2Question →

A SysOps administrator is configuring an Amazon EC2 Auto Scaling group (ASG) to launch instances using a new launch template. The launch template specifies an IAM instance profile with an associated IAM role for the instances. When the ASG attempts to launch instances to meet the desired capacity, all launch attempts fail with the status message: "You are not authorized to perform this operation." The administrator verified that the administrator's IAM identity has the necessary permissions to create the ASG and the launch template. Which configuration change will resolve the launch failures?

Modify the trust policy of the instance profile's IAM role to allow the Auto Scaling service principal (autoscaling.amazonaws.com) to perform the sts:AssumeRole action.

Create a custom service-linked role for the Auto Scaling group and attach a policy that grants the sts:AssumeRole permission to the Auto Scaling group.

Attach a policy to the administrator's IAM identity that grants the iam:PassRole permission for the ARN of the instance profile's IAM role.

Enable detailed monitoring in the launch template to authorize the Auto Scaling group to send launch status metrics to Amazon CloudWatch.

Show answer & explanation

Answer: Attach a policy to the administrator's IAM identity that grants the iam:PassRole permission for the ARN of the instance profile's IAM role.

Answer

Attach a policy to the administrator's IAM identity that grants the iam:PassRole permission for the ARN of the instance profile's IAM role.

The correct answer is to attach a policy to the administrator's IAM identity that grants the iam:PassRole permission for the ARN of the instance profile's IAM role. AWS requires that any identity configuring an AWS service to act on its behalf must have permission to pass the associated role. Without this permission, the EC2 service cannot associate the IAM role with the newly launched instances, resulting in an authorization error.

Step-by-Step Solution

Analyze the error message 'You are not authorized to perform this operation' in the ASG activity history.

Determine that the failure is caused by an IAM authorization issue when attempting to launch instances with an associated IAM role.

The launch template includes an IAM instance profile, meaning the launching entity must have permission to pass this role to EC2.

Identify the required IAM action for passing roles to AWS services.

The iam:PassRole action is identified as the required permission on the calling identity's policy.

AWS enforces iam:PassRole to prevent users from escalating their privileges by passing roles with greater permissions than they have.

Add the iam:PassRole permission targeting the specific IAM role ARN to the administrator's IAM policy.

The ASG successfully passes the IAM role to EC2, allowing instances to launch without authorization errors.

This completes the required permission chain for the ASG to launch instances with the specified IAM role.

Key Concept

IAM PassRole requirement for EC2 Auto Scaling launches

Question 3Question →

A company hosts a web application on Amazon EC2 instances behind an Application Load Balancer (ALB) in the us-east-1 Region. The company wants to set up an active-passive failover configuration at the zone apex (example.com). If the ALB or the backend instances become unhealthy, Route 53 must automatically redirect traffic to a static maintenance website hosted in an Amazon S3 bucket in the us-west-2 Region. Which configuration will meet these requirements with the fastest failover response and the least configuration overhead?

Create an Alias record at the zone apex using a Failover routing policy. Set the primary record to point to the ALB with Evaluate Target Health set to Yes. Set the secondary record to point to the S3 bucket website endpoint.

Create a CNAME record at the zone apex using a Failover routing policy. Set the primary record to point to the ALB DNS name and associate a Route 53 health check. Set the secondary record to point to the S3 bucket website endpoint.

Create a Weighted routing policy at the zone apex. Set the primary record to point to the ALB with a weight of 100 and associate a Route 53 health check. Set the secondary record to point to the S3 bucket website endpoint with a weight of 0.

Create an Alias record at the zone apex using a Failover routing policy. Set the primary record to point to the ALB. Create a Route 53 health check that monitors a CloudWatch alarm based on standard 5-minute ALB metrics, and associate it with the primary record. Set the secondary record to point to the S3 bucket website endpoint.

Show answer & explanation

Answer: Create an Alias record at the zone apex using a Failover routing policy. Set the primary record to point to the ALB with Evaluate Target Health set to Yes. Set the secondary record to point to the S3 bucket website endpoint.

Answer

Create an Alias record at the zone apex using a Failover routing policy, pointing the primary record to the Application Load Balancer with Evaluate Target Health enabled, and pointing the secondary record to the Amazon S3 bucket website endpoint.

The correct option is the configuration that creates an Alias record at the zone apex using a Failover routing policy, points the primary record to the Application Load Balancer (ALB) with 'Evaluate Target Health' enabled, and points the secondary record to the Amazon S3 bucket website endpoint. This setup is standard, complies with zone apex limitations by using an Alias record instead of a CNAME, and provides rapid failover by having Route 53 directly evaluate the ALB target health without needing a separate health check or a delayed CloudWatch alarm.

Step-by-Step Solution

Select the zone apex record (example.com) and set the routing policy to Failover.

Allows creation of primary and secondary records for active-passive failover.

Failover routing is the standard policy for active-passive disaster recovery setups.

Configure the primary record as an Alias record pointing to the Application Load Balancer, and set 'Evaluate Target Health' to Yes.

Route 53 will automatically check the health of the ALB and its targets without requiring a manual Route 53 health check setup.

Alias records to ALBs can leverage 'Evaluate Target Health' to quickly detect ALB target group health changes.

Configure the secondary record as an Alias record pointing to the S3 bucket website endpoint.

Traffic will failover to the S3 static website when the ALB is determined to be unhealthy.

Provides a cost-effective and highly available passive backup endpoint.

Key Concept

Route 53 active-passive DNS failover using Alias records and target health evaluation.

Question 4Question →

A SysOps Administrator is setting up an active-passive disaster recovery solution using Amazon Route 53 for a public web application. The primary infrastructure runs in the us-west-2 Region behind an Application Load Balancer (ALB), and the backup infrastructure runs in the us-east-1 Region behind another ALB. The administrator wants to route all user traffic to us-west-2 under normal conditions, and automatically redirect traffic to us-east-1 if the primary application becomes unavailable. Which combination of actions must the administrator perform to configure this failover mechanism? (Select TWO.)

Select all that apply

Create an Alias record pointing to the primary Application Load Balancer in us-west-2, select the Failover routing policy, set the Failover Record Type to Primary, and set Evaluate Target Health to Yes.

Create an Alias record pointing to the backup Application Load Balancer in us-east-1, select the Failover routing policy, set the Failover Record Type to Secondary, and set Evaluate Target Health to Yes.

Create a primary record using the Weighted routing policy with a weight of 100, and a secondary record using the Weighted routing policy with a weight of 0.

Enable detailed monitoring on the primary Application Load Balancer to configure a Route 53 health check that monitors a CloudWatch alarm for target response times.

Associate the primary Route 53 record with a custom health check that monitors the replication lag metric of an RDS Read Replica in the backup region.

Show answer & explanation

Answer: Create an Alias record pointing to the primary Application Load Balancer in us-west-2, select the Failover routing policy, set the Failover Record Type to Primary, and set Evaluate Target Health to Yes.; Create an Alias record pointing to the backup Application Load Balancer in us-east-1, select the Failover routing policy, set the Failover Record Type to Secondary, and set Evaluate Target Health to Yes.

Answer

The correct configuration requires creating a primary Failover Alias record pointing to the primary Application Load Balancer in us-west-2 with Evaluate Target Health set to Yes, and a secondary Failover Alias record pointing to the backup Application Load Balancer in us-east-1 with Evaluate Target Health set to Yes.

To configure an active-passive failover in Amazon Route 53 using Alias records pointing to Application Load Balancers, the administrator must create a primary record for the active endpoint and a secondary record for the standby endpoint. Setting the routing policy to Failover and configuring the Failover Record Type to Primary and Secondary respectively aligns with active-passive design. Enabling 'Evaluate Target Health' on both Alias records allows Route 53 to automatically evaluate the health of the load balancers based on the health of their registered targets, triggering the failover when the primary ALB's targets become unhealthy.

Step-by-Step Solution

Identify the routing policy and record type required for the primary endpoint.

A Failover routing policy with the Failover Record Type set to Primary pointing to the primary Application Load Balancer.

Active-passive disaster recovery setups in Route 53 require a Failover routing policy where the primary record represents the main active resource.

Determine how to monitor the health of the Application Load Balancer without extra cost or configuration.

Enable the 'Evaluate Target Health' setting on the Alias record.

When Evaluate Target Health is set to Yes, Route 53 inherits the health status of the Application Load Balancer from the backend EC2 targets registered with the ALB's target groups.

Configure the standby endpoint for failover.

A Failover routing policy with the Failover Record Type set to Secondary pointing to the backup ALB in the us-east-1 Region, with Evaluate Target Health set to Yes.

This ensures Route 53 will route DNS queries to the standby ALB when the primary ALB's health checks fail.

Key Concept

Active-passive Route 53 DNS failover configuration using Alias records and the Evaluate Target Health feature.

Question 5Question →

A company is designing a backup and disaster recovery strategy for a critical multi-tier application. The application stores transaction logs in an Amazon S3 bucket and uses an Amazon RDS for PostgreSQL DB instance. The backup policy requires all database backups to be replicated to a secondary AWS Region to enable point-in-time recovery (PITR) with a minimum recovery time. Additionally, the S3 transaction logs must be replicated to the secondary Region while retaining full version history. Which combination of actions should the SysOps Administrator take to meet these requirements? (Select TWO.)

Select all that apply

Enable versioning on both the source S3 bucket and the destination S3 bucket, and configure S3 Cross-Region Replication (CRR).

Enable cross-Region automated backups replication for the Amazon RDS DB instance to replicate automated backups to the secondary Region.

Configure Amazon S3 Cross-Region Replication (CRR) on the source S3 bucket without enabling versioning on the destination S3 bucket.

Configure an Amazon RDS Read Replica in the secondary Region to serve as the automatic failover target for point-in-time recovery if the primary DB instance fails.

Create an S3 lifecycle rule to transition replicated objects directly to the S3 Glacier Flexible Retrieval storage class within 15 days of creation.

Show answer & explanation

Answer: Enable versioning on both the source S3 bucket and the destination S3 bucket, and configure S3 Cross-Region Replication (CRR).; Enable cross-Region automated backups replication for the Amazon RDS DB instance to replicate automated backups to the secondary Region.

Answer

To meet the requirements, the SysOps Administrator must enable versioning on both the source and destination S3 buckets and configure S3 Cross-Region Replication (CRR), and enable cross-Region automated backups replication for the Amazon RDS DB instance.

Enabling versioning on both the source and destination S3 buckets is a prerequisite for configuring Cross-Region Replication (CRR). Replicating RDS automated backups to a secondary Region provides the capability to restore the DB instance to any point in time within the backup retention window in the destination Region.

Step-by-Step Solution

Enable versioning on both S3 buckets.

Both source and destination S3 buckets are versioning-enabled.

S3 Cross-Region Replication (CRR) requires versioning to be enabled on both the source and destination buckets to function properly.

Configure Cross-Region Replication.

S3 objects and version history are automatically copied to the secondary Region.

This configuration satisfies the S3 replication requirements while maintaining version history.

Configure Amazon RDS cross-Region automated backup replication.

RDS automated backups are replicated to the secondary Region.

This allows the administrator to perform point-in-time recovery (PITR) in the secondary Region directly from the replicated automated backups.

Key Concept

Configuring S3 Cross-Region Replication with versioning and RDS cross-Region automated backup replication for disaster recovery.

Question 6Question →

A company hosts a critical web application on Amazon EC2 instances behind an Application Load Balancer (ALB) in the eu-central-1 (Frankfurt) region. The company wants to implement an active-passive disaster recovery strategy using Amazon Route 53. If the application's response latency exceeds 5 seconds, traffic must fail over to a static maintenance page hosted on an Amazon S3 bucket configured for website hosting in the eu-west-1 (Ireland) region. The latency metric is monitored via a custom CloudWatch metric. Which two configuration steps must the SysOps Administrator perform to set up this Route 53 DNS failover configuration? (Select TWO.)

Select all that apply

Create the CloudWatch alarm for the latency metric in the us-east-1 (N. Virginia) Region, and associate the Route 53 health check with this alarm.

Create the CloudWatch alarm for the latency metric in the eu-central-1 Region, and link the Route 53 health check directly to this local alarm.

Create a primary Route 53 Failover record pointing to the ALB with the custom health check associated, and a secondary Route 53 Failover record pointing to the S3 bucket website endpoint.

Configure the secondary Failover record to point to an Amazon RDS Read Replica endpoint in eu-west-1 to handle database write availability during a failover event.

Enable Detailed Monitoring on the Application Load Balancer to retrieve sub-minute metrics, allowing the Route 53 health check to query the load balancer latency directly without an associated alarm.

Show answer & explanation

Answer: Create the CloudWatch alarm for the latency metric in the us-east-1 (N. Virginia) Region, and associate the Route 53 health check with this alarm.; Create a primary Route 53 Failover record pointing to the ALB with the custom health check associated, and a secondary Route 53 Failover record pointing to the S3 bucket website endpoint.

Answer

Creating the CloudWatch alarm for the latency metric in the us-east-1 Region to link with the Route 53 health check, and creating a primary Route 53 Failover record pointing to the ALB alongside a secondary Route 53 Failover record pointing to the S3 website endpoint.

To set up Route 53 active-passive failover based on custom metrics like latency, the SysOps Administrator must use a CloudWatch alarm. Route 53 can only integrate with CloudWatch alarms residing in the us-east-1 region, meaning the alarm must be created there even if the metric data originates elsewhere. Additionally, the DNS configuration requires defining a primary Failover record associated with the health check and a secondary Failover record pointing to the passive destination (the S3 bucket website hosting endpoint).

Step-by-Step Solution

Configure metric publishing to the us-east-1 region, or configure a cross-region CloudWatch alarm in us-east-1 that evaluates the custom metric data coming from the eu-central-1 region.

A CloudWatch alarm monitoring the response latency is created in the us-east-1 Region.

Amazon Route 53 health checks are global and only integrate with CloudWatch alarms created in the us-east-1 region.

Create a Route 53 health check that monitors the state of the newly created CloudWatch alarm in us-east-1.

A Route 53 health check is established that reports unhealthy status when the CloudWatch alarm transitions to the ALARM state.

This links the application-layer latency metric directly to the DNS failover logic.

Create a primary routing record (e.g., an Alias A record for the zone apex or a standard CNAME) pointing to the ALB in eu-central-1, configure it with the Failover routing policy, and associate it with the created Route 53 health check.

The primary record will route traffic to the ALB as long as the health check reports healthy.

Associating the health check ensures that Route 53 will detect latency spikes and stop resolving queries to the primary ALB.

Create a secondary routing record with the same name, configure it with the Failover routing policy, and point it to the S3 bucket website endpoint in eu-west-1.

The secondary record will serve traffic to the maintenance page when the primary endpoint is unhealthy.

Completes the active-passive failover configuration.

Key Concept

Amazon Route 53 DNS Active-Passive Failover with CloudWatch Alarms

Estimated Time:2m 30s

Question 7Question →

A company is designing a backup, restore, and high availability strategy for a critical transactional database running on Amazon RDS. The SysOps Administrator must satisfy the following requirements:
1. Automated daily backups must be replicated to a destination bucket in a secondary AWS Region.
2. In the event of an Availability Zone outage, the database must automatically failover to a standby instance in another Availability Zone within 2 minutes without requiring changes to application connection strings.
3. The replicated backups must be encrypted with a Customer Managed Key (CMK) in the destination Region, and access to decrypt these backups must be managed using IAM policies.

Which configuration must the SysOps Administrator implement to satisfy these requirements?

Configure the primary database to use Multi-AZ deployment. Enable S3 versioning on both the source and destination buckets, and configure S3 Cross-Region Replication (CRR) to copy the backups. In the destination Region, use IAM policies to grant decrypt permissions on the destination KMS key to authorized users, without modifying the destination KMS key's policy to permit IAM-based access control.

Configure the primary database to use Multi-AZ deployment. Enable S3 versioning on both the source and destination buckets, and configure S3 Cross-Region Replication (CRR) to copy the backups. In the destination Region, configure the KMS key policy to allow the destination account's root principal to delegate key permissions, then use IAM policies to grant decrypt permissions to authorized users.

Configure the primary database to use Multi-AZ deployment. Configure S3 Cross-Region Replication (CRR) to copy the backups from the source bucket to the destination bucket without enabling S3 versioning on either bucket. In the destination Region, configure the KMS key policy to allow the destination account's root principal to delegate key permissions, then use IAM policies to grant decrypt permissions to authorized users.

Deploy a database Read Replica in a different Availability Zone to handle automatic failover. Enable S3 versioning on both the source and destination buckets, and configure S3 Cross-Region Replication (CRR) to copy the backups. In the destination Region, configure the KMS key policy to allow the destination account's root principal to delegate key permissions, then use IAM policies to grant decrypt permissions to authorized users.

Show answer & explanation

Answer: Configure the primary database to use Multi-AZ deployment. Enable S3 versioning on both the source and destination buckets, and configure S3 Cross-Region Replication (CRR) to copy the backups. In the destination Region, configure the KMS key policy to allow the destination account's root principal to delegate key permissions, then use IAM policies to grant decrypt permissions to authorized users.

Answer

Configure the primary database to use Multi-AZ deployment, enable S3 versioning on both the source and destination buckets for CRR, and modify the destination KMS key policy to allow the root principal to delegate key permissions via IAM.

The correct configuration combines Multi-AZ deployment to achieve automated, synchronous failover within 2 minutes without altering connection strings, enables S3 versioning on both buckets to allow S3 Cross-Region Replication (CRR) of the database backups, and configures the destination KMS key policy to permit the root principal to delegate key operations, enabling IAM policies to successfully control decryption access.

Step-by-Step Solution

Select Multi-AZ deployment for Amazon RDS

Synchronous database replication is established across Availability Zones, enabling automatic DNS failover in under 2 minutes without endpoint changes.

Meets the high availability RTO requirement without requiring application configuration changes.

Enable S3 versioning on the source and destination buckets and configure S3 CRR

Automated backups uploaded to the source S3 bucket are successfully replicated to the secondary Region destination S3 bucket.

S3 Cross-Region Replication has a hard prerequisite that versioning must be enabled on both source and destination buckets.

Modify the Customer Managed Key (CMK) policy in the destination Region to enable IAM policy delegation

The KMS key policy includes the default statement allowing the root principal (`arn:aws:iam::ACCOUNT_ID:root`) to perform key actions, which delegates policy control to IAM.

Without this statement in the KMS key policy, IAM policies cannot grant permissions to access or decrypt using the KMS key due to KMS policy evaluation precedence.

Key Concept

Integrating high availability, backup replication prerequisites, and KMS key policy delegation

Question 8Question →

A SysOps administrator needs to configure active-passive DNS failover for a public-facing API. The primary endpoint is hosted in an on-premises datacenter, and the secondary disaster recovery endpoint is hosted on an Amazon EC2 instance in AWS. If the on-premises endpoint becomes unreachable, Route 53 must automatically redirect traffic to the EC2 instance. How should the administrator configure Amazon Route 53 to meet these requirements?

Configure a Route 53 health check for the on-premises endpoint. Create a primary record with a Failover routing policy pointing to the on-premises IP address and associate it with the health check. Create a secondary record with a Failover routing policy pointing to the EC2 instance IP address.

Create weighted routing records for both endpoints, setting the weight of the primary record to 100 and the secondary record to 0, and associate a Route 53 health check with both records.

Configure a CloudWatch alarm using standard monitoring metrics to check on-premises health, and use a Simple routing record that automatically redirects traffic to the secondary IP when the alarm triggers.

Create a primary record with a Failover routing policy pointing to the on-premises IP, and configure the secondary record to point directly to an Amazon RDS Read Replica endpoint to handle application traffic during a failover.

Show answer & explanation

Answer: Configure a Route 53 health check for the on-premises endpoint. Create a primary record with a Failover routing policy pointing to the on-premises IP address and associate it with the health check. Create a secondary record with a Failover routing policy pointing to the EC2 instance IP address.

Answer

The correct configuration is to configure a Route 53 health check for the on-premises endpoint, then create a primary record with a Failover routing policy pointing to the on-premises IP address and associate it with the health check, and finally create a secondary record with a Failover routing policy pointing to the EC2 instance IP address. This properly defines an active-passive failover configuration where DNS queries resolve to the primary endpoint until the associated health check fails, at which point Route 53 begins responding with the secondary endpoint IP address.

Step-by-Step Solution

Create a Route 53 health check that monitors the IP address or domain name of the primary on-premises API endpoint.

Amazon Route 53 will begin actively probing the on-premises endpoint to determine its health status.

Route 53 requires a health check to monitor the primary record's health state before it can execute an automated failover.

Create the primary DNS record in the hosted zone using the Failover routing policy, point it to the on-premises IP, and associate it with the created health check.

A primary failover record is established with an active monitor.

This establishes the default path for client traffic under normal operating conditions.

Create the secondary DNS record with the same record name, select the Failover routing policy, configure it as the secondary record, and point it to the EC2 instance's public IP address.

A secondary failover record is created.

This provides a backup destination for DNS queries when Route 53 detects that the primary endpoint is unhealthy.

Key Concept

Route 53 active-passive DNS failover requires a primary record with a health check and a secondary record, both configured with the Failover routing policy.

Question 9Question →

A company hosts a web application behind an Application Load Balancer (ALB) in the us-west-2 Region. The company uses Amazon Route 53 with active-passive failover routing to redirect traffic to a backup static website in Amazon S3 if the primary application goes down. The SysOps Administrator configures a Route 53 health check to monitor a CloudWatch alarm. The alarm is based on the UnHealthyHostCount metric for the ALB's target group in us-west-2. During an application outage where all backend instances become unresponsive and stop reporting metrics, the Route 53 health check status remains 'Healthy' and failover does not occur. Which of the following configuration changes are required to resolve this issue? (Select TWO.)

Select all that apply

Recreate the CloudWatch alarm in the us-east-1 Region, referencing the ALB metrics from the us-west-2 Region.

Configure the Route 53 health check to treat insufficient data (INSUFFICIENT_DATA state) as unhealthy.

Change the routing policy of the primary Route 53 record from Failover to Weighted, and set the weight of the primary record to 0.

Enable detailed monitoring on the ALB target group to increase the metric resolution to 1 minute, which automatically resolves the INSUFFICIENT_DATA status.

Configure the S3 bucket to act as an RDS Multi-AZ standby replica to allow synchronous database-level replication and DNS redirection.

Show answer & explanation

Answer: Recreate the CloudWatch alarm in the us-east-1 Region, referencing the ALB metrics from the us-west-2 Region.; Configure the Route 53 health check to treat insufficient data (INSUFFICIENT_DATA state) as unhealthy.

Answer

Recreating the CloudWatch alarm in the us-east-1 Region (referencing the us-west-2 ALB metrics) and configuring the Route 53 health check to treat insufficient data (INSUFFICIENT_DATA state) as unhealthy.

The correct configurations involve recreating the CloudWatch alarm in us-east-1 because Route 53 health checks can only monitor alarms in that specific Region, and configuring the health check to treat the INSUFFICIENT_DATA state as unhealthy to trigger failover when metrics stop reporting.

Step-by-Step Solution

Identify the regional requirements for Route 53 health checks monitoring CloudWatch alarms.

Confirm that Route 53 can only integrate with CloudWatch alarms created in the us-east-1 Region, regardless of the target resource's Region.

Route 53's integration with CloudWatch is globally anchored in the N. Virginia Region.

Analyze the behavior of the CloudWatch alarm when metrics are missing.

Recognize that when all backend instances go down and stop reporting metrics, the alarm status changes to INSUFFICIENT_DATA.

Without active reporting from targets, no metric values are sent, resulting in missing data points.

Adjust the health check state configuration for missing data.

Configure the Route 53 health check to treat the INSUFFICIENT_DATA state as unhealthy so that the primary record is marked unhealthy and traffic fails over.

By default, Route 53 may not treat insufficient data as a failure state, which prevents failover.

Key Concept

Route 53 DNS Failover using CloudWatch Alarms

Question 10Question →

A SysOps Administrator is managing cross-Region disaster recovery using AWS Elastic Disaster Recovery (AWS DRS) to protect a critical business application. The application's EC2 instances in us-east-1 are replicated to a staging area in us-west-2. The instances are configured with an IAM instance profile associated with a role named ApplicationStorageAccessRole that permits access to Amazon S3. During a disaster recovery drill in us-west-2, the administrator attempts to launch recovery instances, but the launch fails. The EC2 launch history shows an authorization error indicating that the administrator is not authorized to perform the action on the resource. Which action must the administrator take to successfully launch the recovery instances during the drill?

Update the trust policy of ApplicationStorageAccessRole to allow the AWS Elastic Disaster Recovery service (drs.amazonaws.com) to assume the role.

Add the iam:PassRole permission for the ApplicationStorageAccessRole to the IAM identity of the administrator initiating the drill.

Configure an Amazon Route 53 active-active failover routing policy to automatically route application traffic to the staging subnet in us-west-2 during the drill.

Modify the administrator's IAM policy to grant kms:Decrypt permissions on the AWS DRS replication key, ignoring the key policy restrictions in the destination Region.

Show answer & explanation

Answer: Add the iam:PassRole permission for the ApplicationStorageAccessRole to the IAM identity of the administrator initiating the drill.

Answer

Add the iam:PassRole permission for the ApplicationStorageAccessRole to the IAM identity of the administrator initiating the drill.

To launch recovery instances with an IAM instance profile, the IAM identity initiating the drill or failover (the SysOps Administrator) must have the iam:PassRole permission for the IAM role associated with the instance profile. This allows the administrator to pass the role to the EC2 service when the instances are created in the target Region.

Step-by-Step Solution

Identify the IAM role specified in the EC2 Launch Template of the source instances, which is ApplicationStorageAccessRole.

Confirming the target role that must be associated with the recovery instances.

AWS Elastic Disaster Recovery uses EC2 Launch Templates to launch target recovery instances with their original configurations, including IAM roles.

Evaluate the IAM permissions of the administrator initiating the disaster recovery drill.

Recognize that the administrator lacks the iam:PassRole permission for the ApplicationStorageAccessRole.

To prevent privilege escalation, AWS requires users who launch EC2 instances with an IAM role to possess the iam:PassRole permission for that specific role.

Add an IAM policy granting the iam:PassRole permission for the ApplicationStorageAccessRole to the administrator's IAM user or role.

The administrator is now authorized to initiate the drill launch with the instance profile.

This permission allows the administrator to pass the role to the EC2 service, enabling the launch of the recovery instances with the required role.

Key Concept

AWS Elastic Disaster Recovery (AWS DRS) utilizes EC2 Launch Templates to deploy target recovery instances. When these instances require an IAM role via an instance profile, the user initiating the recovery or drill must have the iam:PassRole permission for that role to successfully complete the launch.

Question 11Question →

A financial transaction application uses a Multi-AZ Amazon RDS for PostgreSQL DB instance. Following an unplanned failover event, logs indicate that the database successfully transitioned to the standby instance within 40 seconds. However, the application server pool was unable to reconnect to the database for over five minutes, resulting in dropped client requests. A SysOps Administrator discovers that the application servers continued resolving the RDS endpoint to the IP address of the failed primary instance.

Which combination of actions should the SysOps Administrator take to resolve this issue and minimize failover recovery time? (Select TWO.)

Select all that apply

Deploy Amazon RDS Proxy between the application servers and the database instance, and update the application to connect to the proxy endpoint.

Reduce the DNS caching Time to Live (TTL) value in the application server's Java Virtual Machine (JVM) configuration settings.

Promote an existing Amazon RDS Read Replica to primary by using an AWS Lambda function triggered by an Amazon EventBridge database event.

Configure an Amazon Route 53 Active-Passive failover routing policy mapped directly to the private IP addresses of the primary and standby database instances.

Create an Amazon Route 53 CNAME record pointing to the RDS Multi-AZ secondary endpoint, and associate it with a Route 53 health check.

Show answer & explanation

Answer: Deploy Amazon RDS Proxy between the application servers and the database instance, and update the application to connect to the proxy endpoint.; Reduce the DNS caching Time to Live (TTL) value in the application server's Java Virtual Machine (JVM) configuration settings.

Answer

Deploying Amazon RDS Proxy between the application and the database instance, and reducing the DNS caching Time to Live (TTL) value in the application server's JVM configuration settings.

Deploying Amazon RDS Proxy allows the application to remain connected to the proxy endpoint while the proxy handles the backend failover to the promoted standby instance transparently. Additionally, reducing the JVM DNS caching TTL forces the application servers to discard cached IP records and query DNS again, enabling them to discover the new CNAME target quickly.

Step-by-Step Solution

Analyze failover behavior and DNS resolution caching.

The application server continues to connect to the cached IP address of the failed primary instance instead of performing a new DNS lookup for the updated CNAME.

Identify why the application server experienced a prolonged outage despite a successful database-level failover.

Configure the JVM DNS cache TTL.

The JVM DNS cache TTL is lowered (e.g., to 30 seconds), forcing the application server to query the DNS name server again shortly after the failover.

Ensure the application server resolves the new IP address of the promoted standby instance once the RDS CNAME record is updated.

Implement Amazon RDS Proxy.

Active application connections are preserved by the proxy during failover, and queries are automatically routed to the new primary database instance.

Provide connection pooling and abstract the failover process from the application layer to minimize client reconnection delays.

Key Concept

RDS Multi-AZ failovers update the CNAME record of the database endpoint. Applications must either bypass DNS lookup delays using a proxy (like Amazon RDS Proxy) or configure their client-side DNS caching (like JVM TTL) to expire stale records quickly.

Question 12Question →

A company is designing a disaster recovery (DR) architecture for a critical web application. The application's database runs on an Amazon RDS for MySQL DB instance, and its static backup archives are stored in an Amazon S3 bucket. The SysOps administrator must configure the infrastructure to meet the following requirements:

1. The database must automatically fail over to a standby instance in a different Availability Zone during an outage, achieving a Recovery Time Objective (RTO) of under 2 minutes.
2. The S3 backup archives must be automatically replicated to a secondary AWS Region to protect against regional disasters, achieving a Recovery Point Objective (RPO) of 15 minutes.

Which combination of actions must the SysOps administrator perform to meet these requirements? (Select TWO.)

Select all that apply

Enable Multi-AZ deployment on the Amazon RDS for MySQL DB instance.

Enable bucket versioning on both the source S3 bucket and the destination S3 bucket, then configure Amazon S3 Cross-Region Replication (CRR) to the secondary Region.

Deploy an Amazon RDS Read Replica in a different Availability Zone and configure it as the automatic failover target using an Amazon Route 53 CNAME record.

Configure Amazon S3 Cross-Region Replication (CRR) on the source S3 bucket to replicate objects without enabling bucket versioning.

Configure Amazon Route 53 active-active failover routing to distribute database write operations between the primary RDS DB instance and the standby instance in the secondary Availability Zone.

Show answer & explanation

Answer: Enable Multi-AZ deployment on the Amazon RDS for MySQL DB instance.; Enable bucket versioning on both the source S3 bucket and the destination S3 bucket, then configure Amazon S3 Cross-Region Replication (CRR) to the secondary Region.

Answer

To meet the requirements, the administrator must enable Multi-AZ deployment on the Amazon RDS for MySQL DB instance, and enable bucket versioning on both the source and destination S3 buckets before configuring S3 Cross-Region Replication (CRR).

The correct options are enabling Multi-AZ deployment on the RDS instance and enabling bucket versioning on both S3 buckets before configuring Cross-Region Replication. RDS Multi-AZ provides synchronous replication and automatic failover to a standby instance in another Availability Zone, typically completed within 60 to 120 seconds, satisfying the strict recovery time requirement. Amazon S3 Cross-Region Replication automatically replicates new objects to a bucket in a different Region, but requires versioning to be enabled on both the source and destination buckets to track object versions.

Step-by-Step Solution

Configure database high availability by modifying the Amazon RDS for MySQL DB instance.

Select the Multi-AZ deployment option to provision a synchronous standby DB instance in a different Availability Zone.

This ensures automatic failover and DNS redirection in the event of an infrastructure failure, meeting the RTO of under 2 minutes.

Prepare the source S3 bucket and a new destination S3 bucket in the secondary AWS Region.

Enable versioning on both S3 buckets.

Versioning is a strict requirement for S3 replication; replication cannot be enabled without it.

Establish S3 Cross-Region Replication (CRR) between the source and destination buckets.

Configure replication rules to copy all objects to the destination bucket in the secondary Region.

This satisfies the requirement to automatically replicate backup archives to another Region for disaster recovery.

Key Concept

Setting up high availability via RDS Multi-AZ and cross-region durability via S3 Cross-Region Replication, including prerequisite bucket versioning.

Question 13Question →

A healthcare application uses an Amazon RDS for MySQL DB instance in a Single-AZ deployment. The database suffers from high CPU utilization due to a mix of transactional writes and read-intensive reporting queries. A SysOps Administrator must configure the database architecture to support automatic failover in the event of an Availability Zone outage and isolate the reporting workload from the transactional write operations. Which deployment strategy will satisfy these requirements?

Enable the Multi-AZ feature on the DB instance. Create an RDS Read Replica in a different Availability Zone, and configure the reporting queries to use the Read Replica endpoint.

Create an RDS Read Replica in a different Availability Zone. Configure an Amazon Route 53 failover routing policy to redirect transactional write traffic to the Read Replica if the primary DB instance fails.

Enable the Multi-AZ feature on the DB instance. Identify the private DNS endpoint of the standby replica in the secondary Availability Zone, and configure the reporting workload to query that endpoint.

Create a read-writable RDS replica using Multi-Region replication. Configure Amazon Route 53 active-active routing to distribute both write and read traffic equally between the primary database and the replica.

Show answer & explanation

Answer: Enable the Multi-AZ feature on the DB instance. Create an RDS Read Replica in a different Availability Zone, and configure the reporting queries to use the Read Replica endpoint.

Answer

Enable the Multi-AZ feature on the DB instance. Create an RDS Read Replica in a different Availability Zone, and configure the reporting queries to use the Read Replica endpoint.

The correct solution involves enabling Multi-AZ on the database to ensure automatic failover and high availability, while creating a separate Read Replica to handle the reporting workload. In an RDS Multi-AZ deployment, replication to the standby replica is synchronous, but the standby replica is passive and cannot accept read queries. Therefore, to offload reporting queries, a separate Read Replica must be created.

Step-by-Step Solution

Analyze the database requirements: automatic failover for high availability and workload isolation for read-intensive reporting queries.

Identify that Multi-AZ provides synchronous replication and automatic failover, while Read Replicas provide asynchronous replication and read scaling.

To ensure transactional safety and high availability, Multi-AZ is required. To isolate read workloads, a separate readable endpoint is required because Multi-AZ standby instances are passive and cannot be read from.

Evaluate the proposed solutions against Amazon RDS capabilities.

The correct solution uses Multi-AZ for failover and a Read Replica for reporting queries.

This aligns with AWS best practices for scaling reads while maintaining a high availability posture.

Key Concept

Distinction between RDS Multi-AZ deployments for high availability and RDS Read Replicas for read scaling and workload isolation.

Estimated Time:1m 30s

Question 14Question →

A SysOps Administrator is setting up Amazon S3 Same-Region Replication (SRR) between a source bucket and a destination bucket in the same AWS account. The administrator enables versioning on the source bucket, creates an IAM role with the necessary S3 permissions, and defines the replication configuration. When the administrator runs the AWS CLI command `aws s3api put-bucket-replication` to apply the configuration, the command fails with an error. Which of the following is the most likely cause of this failure?

The destination bucket does not have S3 versioning enabled.

The IAM user running the CLI command is missing the iam:PassRole permission to pass the replication role to the Amazon S3 service.

The KMS key policy for the destination bucket's default KMS encryption fails to allow the replication IAM role to perform key operations.

The replication IAM role's trust relationship policy contains specific S3 bucket action permissions rather than trust permissions for the service principal.

Show answer & explanation

Answer: The destination bucket does not have S3 versioning enabled.

Answer

The destination bucket does not have S3 versioning enabled.

Amazon S3 replication requires versioning to be enabled on both the source and destination buckets. If versioning is not enabled on the destination bucket, S3 will reject the replication configuration with an error when attempting to apply it.

Step-by-Step Solution

Review the requirements for configuring Amazon S3 replication.

Identify that S3 replication requires bucket versioning to be enabled on both the source and destination buckets.

S3 replication relies on version IDs to track and copy object updates accurately across buckets.

Analyze the validation behavior of the put-bucket-replication API call.

Confirm that the S3 API validates the versioning state of both the source and target buckets during configuration application.

Amazon S3 performs synchronous validation to ensure the destination bucket is ready to receive versioned replicas.

Enable versioning on the destination bucket.

The destination bucket is properly configured for versioned object storage, allowing replication to succeed.

This satisfies the S3 replication pre-requisite, resolving the validation failure.

Key Concept

Amazon S3 replication requires bucket versioning to be enabled on both the source and destination buckets.

Question 15Question →

A company hosts a processing application on Amazon EC2 instances in an Auto Scaling group (ASG). A SysOps administrator configures a step scaling policy based on a custom CloudWatch metric named QueueBacklog, which is published by the application every 60 seconds. During sudden load spikes, the administrator notices that although the metric exceeds the alarm threshold almost immediately, the ASG takes 5 minutes before launching new instances.

What is the most likely cause of this delay in scaling?

The Auto Scaling group's default cooldown period is set to 300 seconds, which blocks the step scaling policy from scaling out.

The EventBridge rule routing the metric to the step scaling policy has a default propagation delay of 300 seconds.

The CloudWatch alarm associated with the step scaling policy is configured with a period of 300 seconds instead of 60 seconds.

The IAM role assigned to the Auto Scaling group is missing the iam:PassRole permission for the CloudWatch namespace.

Show answer & explanation

Answer: The CloudWatch alarm associated with the step scaling policy is configured with a period of 300 seconds instead of 60 seconds.

Answer

The CloudWatch alarm associated with the step scaling policy is configured with a period of 300 seconds instead of 60 seconds.

The correct answer is correct because CloudWatch alarms evaluate metrics over a specified period. Even if the application publishes the custom metric every 60 seconds, an alarm with a period of 300 seconds (5 minutes) will only evaluate the metric at 5-minute intervals. To reduce scaling latency, the alarm's period must be set to 60 seconds (1 minute) to match the publication frequency of the metric.

Step-by-Step Solution

Analyze how metrics are evaluated by the scaling policy trigger.

The scaling policy is triggered by a CloudWatch alarm, which uses a defined metric, evaluation periods, and period length.

To understand the scaling delay, the administrator must check the alarm configuration rather than the metric publication frequency.

Compare the metric publication frequency with the alarm evaluation period.

The custom metric is published every 60 seconds, but the alarm is configured with a 300-second period.

This mismatch means the alarm waits for 300 seconds of data aggregation before evaluating the threshold, causing a 5-minute delay.

Rule out incorrect mechanisms like default cooldowns or EventBridge.

Step scaling ignores default cooldowns for scale-out, and EventBridge is not the trigger mechanism for step scaling.

Eliminating these options confirms that the alarm period is the root cause of the delay.

Key Concept

Auto Scaling policies rely on CloudWatch alarms. If the alarm period is larger than the metric publication interval, scaling decisions will be delayed because the alarm aggregates data over that longer period.

Question 16Question →

A SysOps Administrator is configuring AWS Elastic Disaster Recovery (AWS DRS) to replicate on-premises virtual machines to AWS. The administrator faces two challenges: the replication servers in the staging area cannot communicate with the AWS DRS service, and subsequent attempts to launch drill instances fail due to permission authorization errors.

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

Select all that apply

Ensure the staging area subnet has a route to the AWS DRS service endpoints via a NAT gateway or through Interface VPC endpoints (AWS PrivateLink).

Grant the iam:PassRole permission to the IAM identity initiating the drill launch, allowing it to pass the required execution roles to the recovery instances.

Grant the sts:AssumeRole permission in the IAM user policy of the administrator to allow them to directly assume the replication server EC2 instance roles during launch.

Create a Gateway VPC endpoint for AWS DRS and associate it with the route table of the staging area subnet to enable private replication path routing.

Configure an Amazon Route 53 active-active failover routing policy to automatically redirect replication agent traffic to the staging area VPC.

Show answer & explanation

Answer: Ensure the staging area subnet has a route to the AWS DRS service endpoints via a NAT gateway or through Interface VPC endpoints (AWS PrivateLink).; Grant the iam:PassRole permission to the IAM identity initiating the drill launch, allowing it to pass the required execution roles to the recovery instances.

Answer

The correct actions are: ensuring the staging area subnet has a route to the AWS DRS service endpoints via a NAT gateway or Interface VPC endpoints, and granting the iam:PassRole permission to the IAM identity initiating the drill launch.

AWS DRS replication servers in the staging VPC require communication with the AWS DRS control plane, which can be accomplished either publicly via a NAT gateway or privately using Interface VPC endpoints. During a drill or recovery launch, the initiating IAM user or role must possess the iam:PassRole permission to pass the required execution and helper instance profile roles to the target recovery EC2 instances.

Step-by-Step Solution

Analyze the networking requirements for the staging area.

Identify that replication servers in the staging VPC must communicate with the AWS DRS control plane endpoints, which requires either public routing (NAT gateway) or private routing (Interface VPC endpoints).

This establishes the replication path between the source servers and the DRS service.

Analyze the IAM permission requirements for launching EC2 recovery instances.

Identify that launching EC2 instances with associated roles requires the launching user or role to have the iam:PassRole permission.

This resolves the authorization failure during the drill launch process.

Evaluate and eliminate incorrect alternatives.

Discard Gateway endpoints (unsupported for DRS), active-active Route 53 routing (not applicable to agent replication paths), and sts:AssumeRole (incorrect permission type for launching instances with roles).

This ensures the selected options are both technically valid and relevant to the scenario.

Key Concept

AWS Elastic Disaster Recovery (AWS DRS) staging network connectivity and IAM PassRole launch permissions

Question 17Question →

An e-commerce company operates an application on AWS where the frontend instances are managed by an Auto Scaling group (ASG). During scheduled flash sales, the company notices that CPU utilization spikes instantly on the active instances, causing the application to become temporarily unresponsive. However, the ASG fails to launch any new instances until exactly $5$ minutes after the flash sale starts, despite a target tracking policy being active. The ASG's launch template does not have detailed monitoring enabled.

Which configuration adjustment will resolve the delay in the initial scale-out actions?

Adjust the step scaling policy to reduce the scale-out cooldown timer to

0

seconds, allowing immediate scaling when the metric threshold is breached.

Create a custom EventBridge rule that triggers the Auto Scaling policy directly when the scaling metric threshold is exceeded, bypassing the default metric collection latency.

Enable detailed monitoring in the launch template of the Auto Scaling group so that metrics are sent to Amazon CloudWatch at

1

-minute intervals.

Attach an IAM policy with `iam:PassRole` permissions to the IAM instance profile of the EC2 instances, allowing the Auto Scaling service to execute scaling API calls.

Show answer & explanation

Answer: Enable detailed monitoring in the launch template of the Auto Scaling group so that metrics are sent to Amazon CloudWatch at $1$ -minute intervals.

Answer

Enable detailed monitoring in the launch template of the Auto Scaling group so that metrics are sent to Amazon CloudWatch at

1

-minute intervals.

Enabling detailed monitoring in the launch template sends EC2 metrics such as CPU utilization to CloudWatch at

1

-minute intervals instead of the default

5

minutes. This reduces the latency of alarm evaluation, permitting target tracking policies to scale out the group much more rapidly during traffic spikes.

Step-by-Step Solution

Analyze the observed delay pattern.

The delay is exactly

5

minutes, which matches the metric delivery interval of standard monitoring.

By default, basic or standard monitoring for EC2 instances posts metrics to CloudWatch at

5

-minute intervals, delaying any scaling alarms built on these metrics.

Determine the scaling metric source configuration.

Standard monitoring is currently active because detailed monitoring is disabled in the launch template.

Auto Scaling groups inherit monitoring settings from their launch configurations or templates.

Select the appropriate resolution to reduce metric latency.

Enabling detailed monitoring on the launch template reduces the metric update interval to

1

minute.

This allows CloudWatch to receive metrics more frequently and evaluate the target tracking policy's threshold alarm within

1

minute of a load spike.

Key Concept

Standard vs. Detailed CloudWatch Monitoring for Auto Scaling Groups

Estimated Time:1m 30s

Question 18Question →

An administrator is configuring a lifecycle hook (EC2_INSTANCE_TERMINATING) for an Amazon EC2 Auto Scaling group to back up application logs to an Amazon S3 bucket before instances are terminated. What is the correct chronological sequence of events starting from when the Auto Scaling group initiates the termination of an instance?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with the Auto Scaling group selecting the instance and transitioning it to the Terminating:Wait state. Next, Amazon EventBridge triggers a target function such as AWS Lambda. The target function performs the log backup to Amazon S3, and then calls the CompleteLifecycleAction API. Finally, the Auto Scaling group transitions the instance to the Terminating:Proceed state and terminates the instance.

The lifecycle hook flow requires that the Auto Scaling group first pauses termination (Terminating:Wait). This state change triggers EventBridge to invoke the cleanup script. Once the script backs up the logs to S3, it must call the CompleteLifecycleAction API with a CONTINUE result. The Auto Scaling group then changes the state to Terminating:Proceed and terminates the instance.

Step-by-Step Solution

Select and pause the instance.

The instance goes into the Terminating:Wait state, which pauses the termination.

This state transition allows custom actions to run before the instance is shut down.

Detect transition and trigger automation.

Amazon EventBridge catches the event and invokes the target Lambda function.

EventBridge orchestrates the event-driven notification of the lifecycle transition.

Execute cleanup scripts.

Logs are transferred to the Amazon S3 bucket.

The task must occur while the instance is still fully operational in the wait state.

Signal lifecycle completion.

The CompleteLifecycleAction API is called with the CONTINUE result.

This informs the Auto Scaling group that the custom action is finished.

Terminate the instance.

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

The Auto Scaling group resumes the termination workflow after the signal is received.

Key Concept

Auto Scaling Lifecycle Hooks

Question 19Question →

A SysOps administrator is managing an application running on Amazon EC2 instances inside an Auto Scaling group (ASG). The ASG uses a target tracking scaling policy based on the default `ASGAverageCPUUtilization` metric, with a target utilization of $50\%$ . The application experiences sudden, high-intensity traffic spikes that typically last for $10$ to $15$ minutes. However, during these spikes, the ASG takes $5$ to $7$ minutes to begin launching new instances, causing the existing instances to become overloaded and fail health checks. The launch template for the ASG does not explicitly configure monitoring.

Which of the following describes the root cause of this delayed scaling behavior, and the correct remediation step?

The default instance warmup period for the target tracking policy is set to the default value of

300

seconds, preventing the ASG from launching new instances until the warmup expires. The administrator should decrease the default cooldown period of the Auto Scaling group to

60

seconds.

The EC2 instances are reporting metrics at the default

5

-minute interval, causing a delay in the aggregation of the `ASGAverageCPUUtilization` metric. The administrator should enable detailed monitoring in the launch template.

The Auto Scaling group metrics collection is disabled, which prevents CloudWatch from gathering metrics at a

1

-minute frequency. The administrator should enable group metrics collection in the Auto Scaling group configuration.

The service-linked role for Auto Scaling lacks the `iam:PassRole` permission to pass the execution role to the new instances, causing CloudWatch alarm action executions to time out. The administrator should attach a policy allowing `iam:PassRole` to the Auto Scaling service role.

Show answer & explanation

Answer: The EC2 instances are reporting metrics at the default $5$ -minute interval, causing a delay in the aggregation of the `ASGAverageCPUUtilization` metric. The administrator should enable detailed monitoring in the launch template.

Answer

The correct answer is that the EC2 instances are reporting metrics at the default

5

-minute interval, and detailed monitoring must be enabled in the launch template.

The correct answer is the option indicating that the instances are reporting metrics at the default

5

-minute interval, and detailed monitoring must be enabled in the launch template. By default, EC2 instances send CPU utilization metrics to CloudWatch every

5

minutes. Because target tracking scaling policies rely on the aggregated `ASGAverageCPUUtilization` metric, the underlying alarm is bound by this

5

-minute reporting interval. Consequently, a sudden load spike is not registered quickly enough, leading to a scaling delay. Enabling detailed monitoring in the launch template changes this reporting interval to

1

minute, resolving the delay.

Step-by-Step Solution

Analyze the metrics source and default monitoring settings for Amazon EC2 instances.

Identify that by default, standard monitoring is active, which sends CPU metrics to Amazon CloudWatch at

5

-minute intervals.

Target tracking scaling policies evaluate aggregated metrics like `ASGAverageCPUUtilization` that rely on individual instance metrics.

Evaluate the delay in metric updates during traffic spikes.

Determine that a traffic spike starting right after a metric push can take up to

5

minutes to be reflected in CloudWatch, delaying alarm breach.

Without detailed monitoring, CloudWatch does not receive the granular data needed to trigger scale-out actions within

1

2

minutes.

Formulate the remediation strategy.

Enable detailed monitoring in the launch template to change the metric delivery interval to

1

minute.

This ensures the `ASGAverageCPUUtilization` metric is updated every minute, allowing the target tracking policy to trigger scaling quickly.

Key Concept

The difference between Standard and Detailed Monitoring on EC2 instances and its impact on Auto Scaling responsiveness.

Estimated Time:3m 0s

Question 20Question →

An Auto Scaling group uses a target tracking scaling policy based on average CPU utilization. During sudden load increases, the Auto Scaling group launches new EC2 instances. The application on these instances requires five minutes to complete initialization and begin serving requests. During this initialization period, the Auto Scaling group continues to launch additional, unnecessary EC2 instances because the average CPU utilization remains high. Which parameter should be configured to prevent this behavior?

The default instance warmup time on the Auto Scaling group

The scale-in cooldown period on the target tracking policy

Detailed monitoring for the EC2 instances in the launch template

The EventBridge rule delay timer for Auto Scaling group events

Show answer & explanation

Answer: The default instance warmup time on the Auto Scaling group

Answer

The default instance warmup time on the Auto Scaling group

Configuring the default instance warmup time tells the Auto Scaling group to exclude newly launched instances from the group's metric averages until they have warmed up for the specified duration. This prevents the scaling policy from launching additional instances while the first set of instances is still initializing.

Step-by-Step Solution

Identify the cause of the unnecessary scaling actions.

Newly launched instances are taking 5 minutes to boot, but their high initialization CPU utilization is being immediately included in the group average calculation, triggering further scale-out.

This helps locate the phase of the lifecycle where the problem occurs.

Determine the parameter that controls how long to wait before including new instances in Auto Scaling metrics.

The default instance warmup parameter (or policy-specific warmup) defines this exclusion window.

To choose the setting that directly pauses metric aggregation for booting instances.

Key Concept

Auto Scaling target tracking and instance warmup configuration

Page 1 / 8Next

Reliability and Business Continuity

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