Add the secondary ALB as an origin in an origin group that fails over on HTTP 5xx and use it as the default behavior
Short answer
B Put both ALBs in an origin group that fails over on HTTP 5xx and make it the default behavior.
Question
Key Takeaways
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.
Common mistake: 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.
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
This link opens the official vendor documentation in a new tab.
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 4 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 4
-
WhyIronMan 👍 4 Answered BB, mazon CloudFront offers origin failover, where if a given request to the primary endpoint fails, CloudFront routes the request to the secondary endpoint. Unlike the failover operations described previously, all subsequent requests still go to the primary endpoint, and failover is done per each request. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html#concept_origin_groups.creating
-
CloudHell 👍 4 Answered BIt's B for me. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html
-
dkp 👍 3 Answered Banswer B
-
youonebe 👍 2 Answered Bvote for b
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All DOP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full DOP-C02 Practice Test →