SAP-C02 Practice Question 8: Warm Standby Cross Region DR
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 1 · question 8 of 10
Following a regional outage postmortem, an online booking platform must be given a cross-Region disaster recovery capability. The workload runs today in us-east-1 only: Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer, with an Amazon Aurora MySQL-Compatible Edition cluster holding all state. us-west-2 is the designated recovery Region.
The board has signed off on the following: an RTO of 5 minutes and an RPO of 1 minute; the recovery Region must be able to serve real customer traffic the instant failover is declared, with no instance launch, no stack deployment, and no data restore in the critical path; the recovery Region must then scale up to full production capacity on its own; and, to control cost, the recovery Region must not run full production capacity while us-east-1 is healthy.
Which disaster recovery design should the architect implement?
Show answer and explanation
Answer:
The stated constraints describe a warm standby strategy precisely: a scaled-down but fully functional copy of production is always running in the recovery Region, so it can take traffic immediately at reduced capacity and then scale out with EC2 Auto Scaling. Nothing has to be launched, deployed, or restored while the clock is running, which is what keeps RTO inside 5 minutes. On the data side, an Aurora global database replicates from the primary Region with typical latency under a second and is documented as an RPO measured in seconds and an RTO in the order of a minute for a cross-Region failover, comfortably inside a 1 minute RPO and a 5 minute RTO. Route 53 failover records with health checks move traffic automatically once the primary endpoint is unhealthy. Because the standby runs at reduced capacity rather than full production capacity, it costs less than a hot standby or an active/active deployment.
Option A is backup and restore. Hourly snapshot copies give an RPO of up to an hour, and deploying a CloudFormation stack plus restoring an Aurora cluster from a snapshot takes tens of minutes to hours. Both objectives are missed by orders of magnitude.
Option B misapplies AWS Elastic Disaster Recovery. DRS replicates server-hosted applications and databases at the block level; it cannot replicate an Amazon Aurora managed cluster, so the state that matters is not protected. DRS also implements a pilot light pattern in which the recovery instances are switched off until failover, which conflicts with the requirement to serve traffic with no launch step.
Option C is a pilot light. The data tier is right, but with an Auto Scaling group at desired capacity zero there is no compute serving requests at the moment of failover; a Lambda function must first scale the group out, instances must boot, pass health checks, and register with the load balancer. That is a launch step in the critical path, and the requirement explicitly forbids one.
Reference: Disaster recovery options in the cloud