Disaster Recovery practice questions

Which THREE factors should be considered when designing a disaster recovery plan for a multi-tier application using AWS? (Choose three.)

Trap 1: Deploying the application across multiple Availability Zones.

Multi-AZ deployment addresses high availability within one Region, not disaster recovery across Regions. It is tempting because it protects against a single Availability Zone failure, which is the correct resilience choice for uptime requirements, but a Region-wide disaster still takes the whole application offline.

Trap 2: Using larger instance sizes for better performance.

Instance sizing affects performance and cost, not recovery objectives or failover capability. It is tempting because right-sizing is a genuine design consideration, and larger instances would be the correct answer to a question about handling peak compute load rather than disaster recovery.

A
Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
RTO defines the maximum tolerable downtime and RPO the maximum tolerable data loss; together they drive every subsequent DR decision, including standby strategy, replication frequency and budget. They are the primary business requirements against which any multi-tier AWS DR design is validated.
B
Data replication strategy (e.g., synchronous vs. asynchronous).
Synchronous replication gives near-zero RPO but adds write latency, while asynchronous replication lowers latency at the cost of some data loss. The chosen strategy directly determines whether the RPO target is achievable across the multi-tier application's data stores.
C
DNS failover using Amazon Route 53.
Route 53 health checks and failover routing redirect traffic to the standby Region when the primary becomes unhealthy, which directly controls how quickly users reach recovered tiers. It is the mechanism that realises the RTO target for client-facing endpoints.
D
Deploying the application across multiple Availability Zones.
Why it fails: Multi-AZ deployment addresses high availability within one Region, not disaster recovery across Regions. It is tempting because it protects against a single Availability Zone failure, which is the correct resilience choice for uptime requirements, but a Region-wide disaster still takes the whole application offline.
E
Using larger instance sizes for better performance.
Why it fails: Instance sizing affects performance and cost, not recovery objectives or failover capability. It is tempting because right-sizing is a genuine design consideration, and larger instances would be the correct answer to a question about handling peak compute load rather than disaster recovery.

Question 2mediummultiple choice

A company is migrating a stateful application to AWS. The application runs on a single on-premises server and uses local storage for persistent data. The company wants to achieve high availability and scalability. Which migration approach should the company use?

Trap 1: Use multiple EC2 instances behind an Application Load Balancer with…

Using multiple EC2 instances behind an ALB with sticky sessions still ties state to individual instances. If an instance fails, its sessions are lost, and scaling requires rebalancing sessions. This does not achieve true HA or scalability for state.

Trap 2: Lift and shift to a single Amazon EC2 instance with an EBS volume.

A single EC2 instance with one EBS volume remains a single point of failure and cannot scale horizontally, so the availability and scalability goals go unmet. It is tempting as the quickest lift-and-shift, and would suit a workload needing minimal change with no HA or scaling requirement.

Trap 3: Use an EC2 Auto Scaling group with lifecycle hooks to persist state…

Auto Scaling lifecycle hooks manage instance launch and termination, but EBS snapshots cannot serve as shared live state for a stateful application across instances. This approach suits stateless fleets needing graceful deregistration, not persistent per-node data.

A
Use multiple EC2 instances behind an Application Load Balancer with sticky sessions.
Why it fails: Using multiple EC2 instances behind an ALB with sticky sessions still ties state to individual instances. If an instance fails, its sessions are lost, and scaling requires rebalancing sessions. This does not achieve true HA or scalability for state.
B
Lift and shift to a single Amazon EC2 instance with an EBS volume.
Why it fails: A single EC2 instance with one EBS volume remains a single point of failure and cannot scale horizontally, so the availability and scalability goals go unmet. It is tempting as the quickest lift-and-shift, and would suit a workload needing minimal change with no HA or scaling requirement.
C
Refactor the application to store state in Amazon ElastiCache or Amazon DynamoDB.
Externalising session and persistent state into ElastiCache or DynamoDB removes the single-server dependency, letting the application tier scale horizontally behind a load balancer. This satisfies both the high-availability and scalability constraints that local storage on one server prevents.
D
Use an EC2 Auto Scaling group with lifecycle hooks to persist state to EBS snapshots.
Why it fails: Auto Scaling lifecycle hooks manage instance launch and termination, but EBS snapshots cannot serve as shared live state for a stateful application across instances. This approach suits stateless fleets needing graceful deregistration, not persistent per-node data.

Review the full routing breakdown →

Question 3hardmultiple choice

A company is designing a multi-region active-active application using Amazon Route 53, Application Load Balancers, and Auto Scaling groups. They need to route users to the closest region with the lowest latency. Which routing policy should they use?

Trap 1: Weighted routing

Weighted routing distributes traffic by assigned proportions across records, ignoring user location, so it cannot deliver lowest-latency selection. It suits gradual traffic shifting, canary releases or A/B testing where controlled percentage splits matter, not proximity-based routing for active-active regions.

Trap 2: Failover routing

Failover routing directs traffic to a standby region only when the primary health check fails, so it cannot distribute load across active regions by proximity. It is tempting because it delivers resilience for disaster recovery, where a secondary region serves traffic only after the primary becomes unhealthy.

Trap 3: Geolocation routing

Geolocation routing maps users to regions by their geographic origin, which may not be the lowest-latency region and requires per-country or continent records. It suits content localisation, licensing or language requirements, not latency-optimised routing, which needs latency records instead.

A
Latency routing
Latency routing uses latency measurements between users and AWS Regions to direct each request to the Region with the lowest latency, matching the closest-region requirement. Weighted, failover and geolocation policies do not optimise for measured network latency.
B
Weighted routing
Why it fails: Weighted routing distributes traffic by assigned proportions across records, ignoring user location, so it cannot deliver lowest-latency selection. It suits gradual traffic shifting, canary releases or A/B testing where controlled percentage splits matter, not proximity-based routing for active-active regions.
C
Failover routing
Why it fails: Failover routing directs traffic to a standby region only when the primary health check fails, so it cannot distribute load across active regions by proximity. It is tempting because it delivers resilience for disaster recovery, where a secondary region serves traffic only after the primary becomes unhealthy.
D
Geolocation routing
Why it fails: Geolocation routing maps users to regions by their geographic origin, which may not be the lowest-latency region and requires per-country or continent records. It suits content localisation, licensing or language requirements, not latency-optimised routing, which needs latency records instead.

Question 4easymultiple choice

A company is designing a new application that will be deployed on AWS. The application requires a relational database with automatic failover and high availability within a single AWS region. Which database deployment option meets these requirements?

Trap 1: Amazon RDS Single-AZ deployment

A Single-AZ deployment runs one instance in one Availability Zone with no standby, so an AZ failure causes downtime and no automatic failover occurs. It is tempting as the cheapest RDS option, and it is the correct choice when high availability is explicitly not required.

Trap 2: Amazon RDS with Read Replicas

Read Replicas serve read traffic and require manual promotion; they provide no automatic failover of the primary database. Multi-AZ standby does. Read Replicas are tempting because they improve availability for read-heavy workloads, but that is scaling, not automatic failover within a single region.

Trap 3: Amazon RDS cross-region replication

Cross-region replication copies data to a different region and provides no automatic failover within one region, so it cannot satisfy the single-region availability requirement. It is tempting because it does deliver disaster recovery and read scaling, which is the correct choice when the requirement spans multiple regions.

A
Amazon RDS Single-AZ deployment
Why it fails: A Single-AZ deployment runs one instance in one Availability Zone with no standby, so an AZ failure causes downtime and no automatic failover occurs. It is tempting as the cheapest RDS option, and it is the correct choice when high availability is explicitly not required.
B
Amazon RDS with Read Replicas
Why it fails: Read Replicas serve read traffic and require manual promotion; they provide no automatic failover of the primary database. Multi-AZ standby does. Read Replicas are tempting because they improve availability for read-heavy workloads, but that is scaling, not automatic failover within a single region.
C
Amazon RDS Multi-AZ deployment
RDS Multi-AZ maintains a synchronous standby replica in a second Availability Zone within the same region, with automatic DNS failover during an outage. This delivers the required high availability and automatic failover for a relational database without cross-region complexity.
D
Amazon RDS cross-region replication
Why it fails: Cross-region replication copies data to a different region and provides no automatic failover within one region, so it cannot satisfy the single-region availability requirement. It is tempting because it does deliver disaster recovery and read scaling, which is the correct choice when the requirement spans multiple regions.

Question 5hardmultiple choice

A company is designing a disaster recovery solution for a critical database using Amazon RDS Multi-AZ. However, they also need to protect against regional failures. Which additional AWS service should they use?

Trap 1: RDS Multi-AZ in the same region

Multi-AZ replicates synchronously to a standby in a second Availability Zone within one region, so a regional outage takes down both primary and standby. It is tempting because Multi-AZ already provides automatic failover, and would be the right answer if the requirement were only Availability Zone resilience rather than regional survival.

Trap 2: Amazon S3

Amazon S3 stores backups but cannot serve as a live database replica, so it provides no regional failover for RDS. It is tempting because S3 is durable, cross-region replication is straightforward, and it would be correct for protecting exported snapshots or static content rather than the running database.

Trap 3: AWS Database Migration Service

DMS migrates or replicates data between engines and endpoints on a schedule you configure; it does not provide a standby database that can be promoted during a regional failure. It is tempting because DMS performs continuous replication, and would be correct for ongoing migration or heterogeneous data movement, not disaster recovery failover.

A
RDS Multi-AZ in the same region
Why it fails: Multi-AZ replicates synchronously to a standby in a second Availability Zone within one region, so a regional outage takes down both primary and standby. It is tempting because Multi-AZ already provides automatic failover, and would be the right answer if the requirement were only Availability Zone resilience rather than regional survival.
B
RDS Cross-Region Read Replicas
RDS Cross-Region Read Replicas asynchronously copy data to a different Region, providing a standalone database that can be promoted during a regional outage. This satisfies the protection-against-regional-failures constraint that Multi-AZ, confined to one Region, cannot address.
C
Amazon S3
Why it fails: Amazon S3 stores backups but cannot serve as a live database replica, so it provides no regional failover for RDS. It is tempting because S3 is durable, cross-region replication is straightforward, and it would be correct for protecting exported snapshots or static content rather than the running database.
D
AWS Database Migration Service
Why it fails: DMS migrates or replicates data between engines and endpoints on a schedule you configure; it does not provide a standby database that can be promoted during a regional failure. It is tempting because DMS performs continuous replication, and would be correct for ongoing migration or heterogeneous data movement, not disaster recovery failover.

Question 6hardmulti select

A company is designing a new disaster recovery solution for a critical application running on Amazon EC2. They need to replicate data across AWS Regions with a Recovery Point Objective (RPO) of 15 minutes and a Recovery Time Objective (RTO) of 1 hour. Which THREE actions should they take to meet these objectives?

Trap 1: Manually create and copy AMIs to the secondary region weekly

Manual weekly copies do not meet the 15-minute RPO.

Trap 2: Configure the EC2 instances in a Multi-AZ Auto Scaling group

Multi-AZ Auto Scaling groups replicate EC2 instances across Availability Zones within a single AWS Region, not across AWS Regions, so they cannot achieve cross-region data replication for an RPO of 15 minutes. This option is tempting because Multi-AZ deployment is a standard pattern for high availability and fault tolerance within a Region, and it would be the correct choice if the requirement were to survive an Availability Zone failure rather than a full Region outage.

A
Manually create and copy AMIs to the secondary region weekly
Why it fails: Manual weekly copies do not meet the 15-minute RPO.
B
Create a CloudFormation template to provision the infrastructure in the secondary region
CloudFormation allows rapid deployment of infrastructure in the DR region.
C
Use AWS Backup to automate cross-region EBS snapshot copies
AWS Backup can automate EBS snapshot copies across regions with frequent schedules.
D
Enable cross-region replication on the Amazon S3 buckets containing application data
S3 cross-region replication replicates data with low RPO.
E
Configure the EC2 instances in a Multi-AZ Auto Scaling group
Why it fails: Multi-AZ Auto Scaling groups replicate EC2 instances across Availability Zones within a single AWS Region, not across AWS Regions, so they cannot achieve cross-region data replication for an RPO of 15 minutes. This option is tempting because Multi-AZ deployment is a standard pattern for high availability and fault tolerance within a Region, and it would be the correct choice if the requirement were to survive an Availability Zone failure rather than a full Region outage.

Question 7hardmultiple choice

A company is migrating a critical application to AWS and needs to ensure it meets a Recovery Time Objective (RTO) of 15 minutes and a Recovery Point Objective (RPO) of 5 minutes. The application runs on EC2 with an EBS volume. Which configuration should the company use?

Trap 1: Multi-AZ deployment with synchronous replication between two…

Multi-AZ synchronous replication across two instances gives an RPO near zero, not 5 minutes, and fails to meet the stated objective. It is tempting because synchronous replication maximises durability, so it would be correct if the requirement demanded zero data loss rather than a 5-minute RPO.

Trap 2: Single EC2 instance with EBS snapshots every 5 minutes.

Snapshots every 5 minutes meet the RPO, but restoring a snapshot to a new EBS volume and booting an instance takes far longer than 15 minutes, so the RTO fails. Snapshots suit backup and point-in-time recovery, not rapid failover; a warm standby with replicated data would satisfy both targets.

Trap 3: Two EC2 instances in an Auto Scaling group with a warm standby.

A warm standby in an Auto Scaling group still requires minutes to scale and boot, and EBS replication is not continuous, so it cannot meet a 5-minute RPO. It is tempting because warm standby suits cost-sensitive DR, and would be correct for looser RTO/RPO targets.

A
Multi-AZ deployment with synchronous replication between two instances.
Why it fails: Multi-AZ synchronous replication across two instances gives an RPO near zero, not 5 minutes, and fails to meet the stated objective. It is tempting because synchronous replication maximises durability, so it would be correct if the requirement demanded zero data loss rather than a 5-minute RPO.
B
Single EC2 instance with EBS snapshots every 5 minutes.
Why it fails: Snapshots every 5 minutes meet the RPO, but restoring a snapshot to a new EBS volume and booting an instance takes far longer than 15 minutes, so the RTO fails. Snapshots suit backup and point-in-time recovery, not rapid failover; a warm standby with replicated data would satisfy both targets.
C
Two EC2 instances in an Auto Scaling group with a warm standby.
Why it fails: A warm standby in an Auto Scaling group still requires minutes to scale and boot, and EBS replication is not continuous, so it cannot meet a 5-minute RPO. It is tempting because warm standby suits cost-sensitive DR, and would be correct for looser RTO/RPO targets.
D
EC2 instance with Elastic Disaster Recovery service.
AWS Elastic Disaster Recovery continuously replicates block-level data to a staging area, achieving RPOs of seconds and typical RTOs under 15 minutes. This satisfies both constraints directly: the 5-minute RPO via continuous replication and the 15-minute RTO through automated launch of recovery instances with attached EBS volumes.

Question 8hardmultiple choice

A company is designing a new cloud-native application that will be deployed across multiple AWS Regions for high availability. The application uses Amazon Aurora Global Database for its primary data store. The company needs to ensure that in the event of a regional failure, the secondary region can be promoted to primary with minimal data loss. Which configuration should be used?

Trap 1: Use Aurora Serverless v2 with data replication across regions using…

DMS performs logical replication and is intended for migrations or ongoing heterogeneous sync, not sub-second cross-Region failover. Aurora Global Database already replicates storage across Regions natively, so adding DMS introduces latency and manual promotion steps rather than the required minimal data loss.

Trap 2: Deploy Aurora Multi-AZ in the primary region and use a secondary…

Multi-AZ replicates synchronously only within a single Region, so a secondary Region warm standby would rely on separate replication with no promotion mechanism. Aurora Global Database provides cross-Region storage replication with a secondary cluster that can be promoted directly, satisfying the minimal data loss requirement.

Trap 3: Configure Aurora Cross-Region Read Replicas and use Amazon Route 53…

Aurora Cross-Region Read Replicas are a separate, older mechanism and are not part of an Aurora Global Database cluster, so they cannot be promoted as its secondary. It is tempting because it also spans Regions, but it would be correct for standalone Aurora clusters without Global Database.

A
Use Aurora Serverless v2 with data replication across regions using Database Migration Service (DMS).
Why it fails: DMS performs logical replication and is intended for migrations or ongoing heterogeneous sync, not sub-second cross-Region failover. Aurora Global Database already replicates storage across Regions natively, so adding DMS introduces latency and manual promotion steps rather than the required minimal data loss.
B
Deploy Aurora Multi-AZ in the primary region and use a secondary region as a warm standby.
Why it fails: Multi-AZ replicates synchronously only within a single Region, so a secondary Region warm standby would rely on separate replication with no promotion mechanism. Aurora Global Database provides cross-Region storage replication with a secondary cluster that can be promoted directly, satisfying the minimal data loss requirement.
C
Use Aurora Global Database with one primary region and one secondary region. Enable managed failover with a Recovery Point Objective (RPO) of 1 second.
Aurora Global Database replicates storage-level changes to secondary Regions with typical lag under one second, so managed failover promoting the secondary meets the 1-second RPO constraint. This is the only configuration that keeps cross-Region replication continuously active without application-level write forwarding.
D
Configure Aurora Cross-Region Read Replicas and use Amazon Route 53 for DNS failover.
Why it fails: Aurora Cross-Region Read Replicas are a separate, older mechanism and are not part of an Aurora Global Database cluster, so they cannot be promoted as its secondary. It is tempting because it also spans Regions, but it would be correct for standalone Aurora clusters without Global Database.

Question 9mediummultiple choice

A multinational corporation is migrating its on-premises Active Directory (AD) to AWS Managed Microsoft AD. The company has a hub-and-spoke VPC topology with a central transit gateway. The AD domain controllers must be deployed in two different AWS Regions for disaster recovery. The corporate security policy requires that all AD traffic between Regions must traverse the transit gateway and be inspected by a third-party firewall appliance deployed in the inspection VPC. Which architecture meets these requirements?

Trap 1: Deploy AD in two Regions and use a VPN connection between the VPCs…

Incorrect. VPN connections between VPCs do not require a transit gateway and do not integrate with a central inspection VPC.

Trap 2: Deploy a single AD domain in one Region and use AD replication over…

Incorrect. VPC peering does not support transitive routing through an inspection VPC, and cross-Region peering alone cannot enforce firewall inspection.

Trap 3: Deploy AD in two Regions, attach both VPCs to a transit gateway in…

Incorrect. VPCs in different Regions cannot be attached to the same transit gateway; transit gateway attachments are regional. This architecture is not feasible.

A
Deploy AD in two Regions and use a VPN connection between the VPCs to replicate data.
Why it fails: Incorrect. VPN connections between VPCs do not require a transit gateway and do not integrate with a central inspection VPC.
B
Deploy a single AD domain in one Region and use AD replication over a VPC peering connection to a second Region.
Why it fails: Incorrect. VPC peering does not support transitive routing through an inspection VPC, and cross-Region peering alone cannot enforce firewall inspection.
C
Deploy AD in two Regions, attach both VPCs to the transit gateway, and enable cross-Region transit gateway peering. Use route tables to direct AD traffic through the inspection VPC.
Cross-Region transit gateway peering carries AD replication traffic between the two Regional directories, while transit gateway route tables in each Region force that traffic through the inspection VPC attachment, satisfying the security policy's inspection mandate. AWS Managed Microsoft AD domain controllers stay Regional, so DR is met without exposing replication to the public internet.
D
Deploy AD in two Regions, attach both VPCs to a transit gateway in the primary Region, and use a transit gateway inter-Region peering attachment. Configure route tables to force traffic through the inspection VPC in the primary Region.
Why it fails: Incorrect. VPCs in different Regions cannot be attached to the same transit gateway; transit gateway attachments are regional. This architecture is not feasible.

Question 10hardmultiple choice

A financial services company runs a critical application on Amazon EC2 instances in an Auto Scaling group across multiple Availability Zones. The application uses an Amazon RDS for MySQL database with Multi-AZ deployment. The company has a recovery time objective (RTO) of 15 minutes and a recovery point objective (RPO) of 1 hour for the database. During a recent disaster recovery drill, the solutions architect simulated an Availability Zone failure by terminating all EC2 instances and the primary RDS instance in one AZ. The Auto Scaling group launched new instances in the other AZ, and the RDS Multi-AZ failover completed in about 2 minutes. However, the application remained unavailable for 30 minutes because the new EC2 instances could not connect to the RDS secondary instance. The security groups are configured correctly. The RDS instance is not publicly accessible. What is the MOST likely cause of the connectivity issue?

Trap 1: The security group for the EC2 instances does not allow outbound…

The stem explicitly states the security groups are configured correctly, so outbound rules cannot be the cause. It tempts because security group misconfiguration is the most common cause of EC2-to-RDS connection failures, and would be correct if the EC2 security group lacked an outbound rule permitting MySQL traffic to the database.

Trap 2: The RDS Multi-AZ failover took longer than expected, exceeding the…

The stem states failover completed in about 2 minutes, so the 30-minute outage cannot stem from failover duration; the RTO was already met on that axis. It tempts because Multi-AZ failover time is a genuine RTO consideration, and would be the answer if the drill had shown failover itself exceeding 15 minutes.

Trap 3: The RDS endpoint DNS record did not update to point to the new…

Multi-AZ failover updates the RDS DNS endpoint to the new primary automatically, and the stem's 2-minute failover confirms this succeeded; the 30-minute gap points elsewhere. It tempts because stale DNS is a real failure mode, and would be correct if clients had cached the old IP beyond the TTL.

A
The security group for the EC2 instances does not allow outbound traffic to the RDS instance.
Why it fails: The stem explicitly states the security groups are configured correctly, so outbound rules cannot be the cause. It tempts because security group misconfiguration is the most common cause of EC2-to-RDS connection failures, and would be correct if the EC2 security group lacked an outbound rule permitting MySQL traffic to the database.
B
The RDS Multi-AZ failover took longer than expected, exceeding the RTO.
Why it fails: The stem states failover completed in about 2 minutes, so the 30-minute outage cannot stem from failover duration; the RTO was already met on that axis. It tempts because Multi-AZ failover time is a genuine RTO consideration, and would be the answer if the drill had shown failover itself exceeding 15 minutes.
C
The RDS endpoint DNS record did not update to point to the new primary.
Why it fails: Multi-AZ failover updates the RDS DNS endpoint to the new primary automatically, and the stem's 2-minute failover confirms this succeeded; the 30-minute gap points elsewhere. It tempts because stale DNS is a real failure mode, and would be correct if clients had cached the old IP beyond the TTL.
D
The application is using a hardcoded IP address or an endpoint that points to the old primary RDS instance instead of the RDS DNS name.
The application is likely using a hardcoded IP address or an endpoint pointing to the old primary RDS instance instead of the RDS DNS name, which fails after failover. This is the most likely cause. Option D is correct.

Question 11easymultiple choice

A company is migrating a critical application to AWS and wants to ensure business continuity during the cutover. The migration plan includes a pilot light strategy. Which of the following BEST describes the pilot light pattern?

Trap 1: Take regular backups and restore them in AWS during cutover.

Backup-and-restore recreates the workload only at cutover, so no core services run continuously in AWS; pilot light keeps a scaled-down copy of the application's core components always running and scales them up during failover. It tempts because backups suit low-RPO archival recovery, not rapid continuity.

Trap 2: Run a scaled-down but fully functional version of the environment…

A scaled-down but fully functional environment describes a warm standby, where all components run continuously; pilot light keeps only core services such as databases and identity running, scaling the rest on demand. It is tempting because warm standby is the correct mechanism when near-immediate recovery with minimal scaling delay is required.

Trap 3: Run the application simultaneously in both environments and route…

Running both environments simultaneously with traffic to both describes an active-active or multi-site pattern, not pilot light, which keeps only core services running and scales the rest on failover. It is tempting because simultaneous dual-environment operation is the correct mechanism for zero-downtime continuous availability.

A
Take regular backups and restore them in AWS during cutover.
Why it fails: Backup-and-restore recreates the workload only at cutover, so no core services run continuously in AWS; pilot light keeps a scaled-down copy of the application's core components always running and scales them up during failover. It tempts because backups suit low-RPO archival recovery, not rapid continuity.
B
Run a scaled-down but fully functional version of the environment in AWS at all times.
Why it fails: A scaled-down but fully functional environment describes a warm standby, where all components run continuously; pilot light keeps only core services such as databases and identity running, scaling the rest on demand. It is tempting because warm standby is the correct mechanism when near-immediate recovery with minimal scaling delay is required.
C
Replicate data to AWS and run a minimal version of the application that can be scaled up during cutover.
Replicating data continuously and running only a minimal core of the application satisfies the pilot light requirement: a small always-on footprint that can be scaled up rapidly during cutover. This differs from warm standby, which runs a fully functional but scaled-down copy, and from backup-and-restore, which provisions nothing until disaster.
D
Run the application simultaneously in both environments and route traffic to both.
Why it fails: Running both environments simultaneously with traffic to both describes an active-active or multi-site pattern, not pilot light, which keeps only core services running and scales the rest on failover. It is tempting because simultaneous dual-environment operation is the correct mechanism for zero-downtime continuous availability.

Question 12hardmulti select

A company is designing a multi-region disaster recovery solution for a critical application running on Amazon EC2. The application uses an Amazon Aurora MySQL database. The RTO is 15 minutes and RPO is 1 minute. Which THREE steps should the solutions architect take to meet these requirements?

Trap 1: Configure a cross-region read replica in the DR region and promote…

Promoting a read replica takes longer than 15 minutes.

Trap 2: Take frequent snapshots of the Aurora cluster and copy them to the…

Snapshot restore takes too long (more than 15 minutes).

A
Pre-provision EC2 instances in the DR region with the application code and configuration.
Ensures compute capacity is ready for failover.
B
Use Route 53 health checks with failover routing policy to direct traffic to the DR region.
Automates DNS failover to meet RTO.
C
Configure a cross-region read replica in the DR region and promote it during failover.
Why it fails: Promoting a read replica takes longer than 15 minutes.
D
Take frequent snapshots of the Aurora cluster and copy them to the DR region.
Why it fails: Snapshot restore takes too long (more than 15 minutes).
E
Use Amazon Aurora Global Database for replication to the DR region.
Aurora Global Database provides low-latency replication and fast failover.

Question 13hardmultiple choice

A company is designing a disaster recovery solution for a critical application that runs on Amazon EC2 instances in a single AWS Region. The application uses an Amazon RDS for MySQL database. The company wants to achieve a recovery point objective (RPO) of 5 seconds and a recovery time objective (RTO) of 15 minutes. Which solution should the company use?

Trap 1: Configure an RDS Multi-AZ DB cluster with a standby instance in…

Incorrect. RDS Multi-AZ DB clusters do not support a standby instance in another Region for MySQL; cross-Region synchronous replication is not available.

Trap 2: Use EC2 Auto Scaling to launch new instances in another Region and…

Incorrect. This addresses compute scalability but does not replicate the database, failing to meet the RPO of 5 seconds.

Trap 3: Take automated snapshots of the RDS instance every 5 seconds and…

Incorrect. Automated snapshots cannot be taken every 5 seconds; the minimum interval is 5 minutes, which would result in an RPO of at least 5 minutes.

A
Configure an RDS Multi-AZ DB cluster with a standby instance in another Region.
Why it fails: Incorrect. RDS Multi-AZ DB clusters do not support a standby instance in another Region for MySQL; cross-Region synchronous replication is not available.
B
Use EC2 Auto Scaling to launch new instances in another Region and use an Application Load Balancer.
Why it fails: Incorrect. This addresses compute scalability but does not replicate the database, failing to meet the RPO of 5 seconds.
C
Take automated snapshots of the RDS instance every 5 seconds and copy them to another Region.
Why it fails: Incorrect. Automated snapshots cannot be taken every 5 seconds; the minimum interval is 5 minutes, which would result in an RPO of at least 5 minutes.
D
Deploy RDS Read Replicas in another Region and promote them during a disaster.
Correct. Cross-Region Read Replicas use asynchronous replication, typically achieving an RPO of seconds, and can be promoted to primary within minutes, meeting both RPO and RTO requirements.