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.

• ✓

  Deploy an ALB with a warm standby ECS service in us-west-2. Use Route 53 health checks to route traffic to the secondary region if primary fails. Use ElastiCache Global Datastore for Redis to replicate data across regions.

  Why this is correct

  A warm standby architecture places a fully functional but possibly smaller ECS service behind an ALB in us-west-2, and Route 53 health checks automatically shift user traffic when us-east-1's ALB or service is unhealthy. ElastiCache Global Datastore for Redis maintains a cross-region replica with sub-second replication lag, so the secondary can serve reads and writes after promote without a point-in-time restore. This combination keeps both RPO and RTO under 30 minutes because failover is automated and data is already in the secondary region.

• ✗

  Deploy an Active-Active configuration across two AWS regions using Route 53 latency routing. Use ElastiCache for Redis Global Datastore with multi-region writes.

  Why it's wrong here

  This option wrongly assumes ElastiCache Global Datastore can accept writes from both regions. In reality, Global Datastore implements a primary-secondary model where only the primary cluster accepts writes, and the secondary replicates from it; there is no native multi-region write support. Route 53 latency routing optimizes for minimum network latency, not for automated failover based on health, so it does not provide the deterministic health-check-driven recovery required to meet a 30-minute RTO. Active-Active also demands application-level conflict resolution that would add significant complexity.

• ✗

  Deploy a Pilot Light environment in us-west-2 with a scaled-down ECS service and Redis cluster. Use Route 53 DNS failover. On disaster, scale up the ECS service and promote the Redis cluster.

  Why it's wrong here

  A pilot light keeps the core data plane (Redis) and minimal compute running, but the scaled-down ECS service and Redis cluster are not ready to serve full production traffic instantly. The described plan requires human intervention to scale up the ECS service and to promote or reconfigure the Redis cluster, and those manual actions can easily exceed the 30-minute RTO. Additionally, if the Redis cluster is scaled down or not continuously receiving writes, the promotion step may involve data recovery rather than a quick switch. Route 53 DNS failover can send traffic, but it cannot complete the infrastructure scale-up.

• ✗

  Use Amazon ECS with Fargate in us-east-1 only, and schedule daily snapshots of ElastiCache for Redis. In case of disaster, restore the snapshot in a new region and update DNS.

  Why it's wrong here

  This is a backup-and-restore strategy, not a live DR site. Daily snapshots mean the RPO is up to 24 hours because changes made after the last snapshot are lost, and if the snapshot is taken during the day the window may be even less deterministic. Restoring an ElastiCache snapshot in a new region and rebuilding the ECS environment can take longer than 30 minutes, particularly when loading large datasets from Amazon S3. The lack of any running infrastructure in a second region also means DNS cutover happens only after all restoration, so the RTO is already blown.

Go deeper

Related to this question