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 Amazon CloudFront with origins in each region and configure origin failover.

  Why it's wrong here

  Amazon CloudFront origin failover is intended for static content served from edge caches; it triggers only on HTTP status codes (e.g., 503/504) and cannot detect network-level outages or TCP connection failures. Dynamic ALB endpoints return per-request responses that are not safely cached, and CloudFront would neither provide active-active cross-region load balancing nor traffic shifting. Its origin groups fail over to a secondary origin only after the primary errors, not based on continuous health checks, so it is not a multi-region traffic management solution.

• ✗

  Use a Network Load Balancer in each region and configure Route 53 with failover routing.

  Why it's wrong here

  Network Load Balancers operate at Layer 4 and therefore lack the HTTP-layer features—like path-based routing, host conditions, and HTTP health checks—that a multi-region application typically requires. While Route 53 failover routing can direct traffic away from a failed NLB, failover relies on DNS TTL propagation, which can take minutes and is not acceptable for real-time failover. Additionally, NLB health checks are TCP-based and cannot verify application health, so an unresponsive application behind a healthy TCP listener would not be detected.

• ✗

  Use Route 53 with latency-based routing and health checks on the ALB endpoints.

  Why it's wrong here

  Route 53 latency-based routing responds to each DNS query with the region that gives the lowest latency, but it does not automatically fail over to another region unless you separately attach health checks to every record. Even with health checks, clients may continue using a failed endpoint until the DNS TTL expires, and latency-based routing distributes traffic purely on latency, not on regional capacity or active failover intent. DNS-based routing cannot provide the sub-second, connection-oriented failover and traffic-dial control that an anycast-based service like Global Accelerator offers.

• ✓

  Use AWS Global Accelerator with endpoint groups in each region and health checks.

  Why this is correct

  AWS Global Accelerator allocates static anycast IP addresses and directs traffic to endpoint groups in each Region, using health checks on ALB endpoints to continuously assess availability. When an endpoint becomes unhealthy, traffic is automatically rerouted to the next healthy endpoint group within seconds—no DNS TTL dependency—and traffic dials let you shift traffic percentages between Regions for gradual rollouts. It supports both TCP and UDP traffic, preserves the client IP, and works with ALBs, NLBs, and Elastic IPs, making it the correct choice for deterministic, low-latency multi-Region failover.

Go deeper

Related to this question