Add the secondary ALB as an origin in an origin group that fails over on HTTP 5xx and use it as the default behavior
A company needs to implement failover for its application. The application includes an Amazon CloudFront distribution and a public Application Load Balancer (ALB) in an AWS Region. The company has configured the ALB as the default origin for the distribution. After some recent application outages, the company wants a zero-second RTO. The company deploys the application to a secondary Region in a warm standby configuration. A DevOps engineer needs to automate the failover of the application to the secondary Region so that HTTP GET requests meet the desired RTO. Which solution will meet these requirements?
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The requirement is a zero-second RTO for HTTP GET requests, which rules out DNS-based approaches since Route 53 failover records with Evaluate Target Health still depend on resolution and caching behavior (A and C). CloudFront origin failover is performed at the request level within the distribution itself, so the very next request after a 5xx is routed to the secondary origin (B). Option D uses a CloudFront function to return a redirect response, which hands the client back to DNS resolution and therefore reintroduces the delay that origin failover avoids.
A zero-second RTO with HTTP GET requests cannot be achieved through DNS, because DNS resolution and client-side caching introduce delay. Amazon CloudFront origin failover handles it inside the distribution: a second origin is added for the secondary ALB, both origins are placed in an origin group with the primary ALB as primary, and the group is configured to fail over to the secondary origin on HTTP 5xx responses. Pointing the distribution's default behavior at that origin group makes CloudFront redirect requests to the standby without any DNS change.
Creating a second CloudFront distribution and using Route 53 alias records with a failover policy and Evaluate Target Health (A) — this changes which distribution resolves, so recovery depends on DNS TTLs and client resolver behavior, which cannot deliver a zero-second RTO. Using Route 53 failover records with a TTL of 0 and pointing the distribution origin at the record set (C) — a TTL of 0 still requires a DNS lookup and does not remove the resolution step from the request path. Returning a 307 Temporary Redirect from a CloudFront function (D) — a redirect instructs the client to make a new request that must be resolved and re-established, adding latency rather than eliminating it.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
A zero-second RTO for HTTP GET requests means failover must occur within the request path, without any DNS resolution step. CloudFront origin failover provides exactly that: a second origin is created for the secondary ALB, an origin group is created containing both origins with the original ALB designated as primary, and the group is configured to fail over on HTTP 5xx status codes. Updating the distribution's default behavior to use the origin group means CloudFront routes a request to the secondary origin as soon as the primary returns a 5xx, entirely inside the distribution (B). Because the standby is already deployed and warm, no scaling or DNS propagation is involved.Why the Other Options Are Wrong
A creates a second CloudFront distribution and creates Route 53 alias records with a failover policy and Evaluate Target Health set to Yes, then updates the application to use the new record set. Failover at the DNS layer necessarily depends on record resolution and on how long clients cache the previous answer, so it cannot achieve a zero-second RTO for in-flight requests. C uses Route 53 alias records with a failover policy and a TTL of 0 and points the distribution's origin at the record set. A zero TTL removes client caching but still requires a DNS lookup on the request path, so the zero-second objective is not met. D creates a CloudFront function that detects 5xx responses and returns a 307 Temporary Redirect to the secondary ALB. A redirect sends the client on a new request that must be resolved and established, which is precisely the extra latency the requirement is trying to eliminate. WhyIronMan and CloudHell both noted that CloudFront origin failover routes requests to the secondary endpoint on failure, unlike DNS-based failover. B is the correct answer.Community Comment Notes
Community voted B unanimously. WhyIronMan explicitly contrasted origin failover, where CloudFront routes the request to the secondary endpoint on failure, with DNS-based failover. CloudHell cited the CloudFront high availability origin failover documentation. dkp and youonebe also selected B without further qualification, and no commenter proposed an alternative.Official Reference
Related Analysis
Practice All DOP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full DOP-C02 Practice Test →