DOP-C02 Resilient Cloud Solutions Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Use RDS cross-Region replication to a standby DB instance in another Region. Maintain a warm standby environment (Auto Scaling group, ALB) in the disaster Region. Configure Route 53 health checks to fail over automatically.

  Why this is correct

  Cross-Region replication maintains a continuously updated standby database in the DR Region, so the RPO is reduced to the replication lag, which is typically seconds for RDS MySQL/PostgreSQL. The pre-provisioned Auto Scaling group and Application Load Balancer constitute a warm standby that can receive traffic immediately after Route 53 health checks detect a regional impairment and automatically update DNS records to point to the DR endpoint. This combination of async data replication and warm infrastructure is what enables a low RPO and an RTO well under the 30-minute requirement.

• ✗

  Use RDS cross-Region snapshot copy every 15 minutes. In the disaster Region, manually launch a new environment and restore the latest snapshot.

  Why it's wrong here

  RDS automated snapshots are created once per day by default, and while you can manually trigger snapshots, you cannot reliably create and copy a snapshot every 15 minutes because the copy is asynchronous and takes time to complete. Even if the snapshot copy succeeded, a manual runbook to launch the entire environment and restore from the snapshot would not meet a 30-minute RTO, and the data would be at least 15 minutes old, potentially violating the RPO. The operational overhead and recovery time are fundamentally incompatible with the stated targets.

• ✗

  Use RDS Multi-AZ in us-east-1. In the disaster Region, keep a standby Auto Scaling group and ALB. On failure, promote the Multi-AZ standby to primary and update DNS.

  Why it's wrong here

  RDS Multi-AZ provides a synchronous standby in a different Availability Zone within the same Region, not in another Region, so it gives zero protection against a Region-wide failure. The Multi-AZ standby is not a separate DB you can promote; when you fail over, the primary simply moves to the other AZ, and the same single Region is still the failure domain. Even with a standby ASG and ALB in the DR Region, those compute resources would have no database to connect to, so this option does not constitute a viable cross-Region DR plan.

• ✗

  Use RDS read replicas in another Region. On failure, promote the read replica to a standalone instance and update the application.

  Why it's wrong here

  Promoting an RDS read replica in another Region gives you a writable database, but the promotion is a manual action and the replica is asynchronous, so you may lose a small amount of recent transactions. The option omits any pre-provisioned compute, load balancer, or DNS failover, meaning you would need to manually launch the application stack and update DNS after promotion, which would blow past the 30-minute RTO. Simply updating the application pointing to the promoted replica does not address the missing infrastructure that must be ready to serve traffic.

Go deeper

Related to this question