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 the application in multiple AWS Regions and use Route 53 with failover routing policy.

  Why this is correct

  This configuration provides global DNS-level failover by associating Route 53 health checks with endpoints in each region. If the primary region's health check fails, Route 53 automatically rewrites DNS responses to direct traffic to the standby region, with failover typically occurring within a few minutes depending on TTL and health-check intervals. However, this requires the application to be designed for multi-region operation, with data replication between regions and compute capacity pre-provisioned in the secondary region to actually serve traffic. This is the core pattern for regional disaster recovery and meets the requirement for a highly available architecture across regions.

• ✗

  Use Amazon CloudFront with multiple origins in the same region.

  Why it's wrong here

  Amazon CloudFront is a content delivery network that caches content at edge locations for faster delivery, but its origin-failover capability (using origin groups) only protects against an origin failure such as an unhealthy web server or an unreachable S3 bucket. If all origins are in the same region, a regional outage—for example, a full loss of the region's infrastructure—makes every origin unavailable simultaneously, so CloudFront cannot serve fresh content or fail over to a healthy origin. Static cache hits may still be served from edge locations for a while, but dynamic requests and cache misses will fail, and no regional resilience is provided. Thus, multiple origins in the same region are inadequate for regional high availability.

• ✗

  Enable S3 cross-Region replication for static assets.

  Why it's wrong here

  S3 Cross-Region Replication automatically copies objects from a source bucket to a destination bucket in another region, but it only replicates the static data layer, such as images, CSS, and JavaScript files. It does not replicate the compute infrastructure (EC2 instances, containers, or Lambda functions), the application configuration, or any stateful backend like databases or user sessions. Furthermore, replication is asynchronous, so the RPO is typically a few minutes, and even with a complete copy of assets, there is no automatic mechanism to redirect traffic to the destination region or to spin up the application compute environment. This option supports durable backups but is not a substitute for a multi-region active/passive architecture.

• ✓

  Configure Amazon RDS for Multi-AZ and enable cross-Region read replicas.

  Why this is correct

  Configuring Amazon RDS for Multi-AZ creates a synchronous standby replica in a different Availability Zone within the same region, enabling automatic failover when an individual AZ becomes unavailable. Adding cross-Region read replicas maintains an asynchronous copy of the database in a separate region, which can be promoted to a fully writable primary instance during a regional event, giving you a recovery point objective (RPO) of minutes and a recovery time objective (RTO) that depends on manual or automated promotion. While this covers the database tier, it must be combined with compute resources and a traffic-routing mechanism like Route 53 in the secondary region to make the overall application available. In a larger multi-region design, RDS cross-Region replicas are a critical component, though not sufficient by themselves.

• ✗

  Use Auto Scaling groups in a single region with multiple Availability Zones.

  Why it's wrong here

  Auto Scaling groups in a single region with multiple Availability Zones are designed to launch instances in any healthy AZ within that region, allowing the application to survive instance failure or an entire Availability Zone outage by redistributing capacity. However, they cannot help when a regional outage occurs—an event that takes all AWS services in that region offline—because there is no mechanism to launch compute in another region or to reroute traffic to a different regional infrastructure. The architecture is confined to a single geographic boundary, and data persists only within that region, so the application becomes completely unavailable. This provides high availability at the AZ level but does not meet the requirement for regional resilience.

Go deeper

Related to this question