Serve global game assets with Route 53 latency records and health checks

Answer Correct answer: D — Create health checks for each ALB and a latency alias record with Evaluate Target Health set to Yes for closest-Region routing and failover.

A company that is developing a mobile game is making game assets available in two AWS Regions. Game assets are served from a set of Amazon EC2 instances behind an Application Load Balancer (ALB) in each Region. The company requires game assets to be fetched from the closest Region. If game assets become unavailable in the closest Region, they should be fetched from the other Region. What should a solutions architect do to meet these requirements?

  1. Create an Amazon CloudFront distribution. Create an origin group with one origin for each ALB. Set one of the origins as primary.
  2. Create an Amazon Route 53 health check for each ALCreate a Route 53 failover routing record pointing to the two ALBs. Set the Evaluate Target Health value to Yes.
  3. Create two Amazon CloudFront distributions, each with one ALB as the origin. Create an Amazon Route 53 failover routing record pointing to the two CloudFront distributions. Set the Evaluate Target Health value to Yes.
  4. Create an Amazon Route 53 health check for each ALB. Create a Route 53 latency alias record pointing to the two ALBs. Set the Evaluate Target Health value to Yes. Correct Answer

Community Votes

D
57%
A
43%

57% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

Route 53 latency-based alias records pick the Region with the lowest measured latency, and attaching health checks with Evaluate Target Health set to Yes removes an unhealthy target from the record so failover happens without manual intervention.

Game assets are served from ALBs in two Regions. Players must be served from the geographically closest Region, and if the closest Region becomes unavailable, requests must fall to the other Region automatically.

Using a CloudFront origin group with a primary origin. CloudFront uses one primary origin, so it always fetches from the primary Region and does not select the Region closest to the player, and failover needs extra origin-group configuration.

Community Discussion (20 comments)

VerRi 👍 11 Selected: D
A - Need to set cache behaviour for another origin B - Failover routing record cannot point to 2 ALBs C - Works but does not meet the requirement. By default, when there is no unhealthy distribution, the traffic will always be sent to the primary but not the closest region. D - Sending the traffic to the closest region unless the closest region becomes unhealthy
gustori99 👍 6 Selected: A
It is either A or D but both are not perfect. In A Cloudfront will always fetch from the primary region not the closest region. In D latency based routing might not choose the closest region but the one with best latency. For the following reasons I go with A: A is correct: the user will always use the nearest edge location in the closest region to fetch the game assets. Cloudfront will either respond from the cache or load the game assets from the primary origin (or in case the primary origin is not available from the fail over origin). B is incorrect because the game assets would always be fetched from the primary region. C is wrong because this setup is essentially the same as A but much more complicated. D is wrong because latency based routing does not necessarily choose the nearest region but the region with the best latency (geolocation routing policy would be the correct to fulfill the requirement)
eesa 👍 1 Selected: D
D: Route 53 health check for each ALB + latency alias record ✅ Latency-based routing chooses the closest ALB ✅ Health checks ensure traffic is routed only to healthy endpoints ✅ Automatic failover if one Region becomes unavailable ✅ Fully satisfies both requirements ✅ This is the correct and most efficient solution
Spike2020 👍 1 Selected: D
A is not possible. You can have only 1 active origin behind CFN
TomTom 👍 1 Selected: B
Option B is more appropriate. Below explanation: If the primary goal is to ensure that if one Region's assets become unavailable, traffic should seamlessly switch to another Region without user impact, Option B is more appropriate due to its explicit failover mechanism. However, if minimizing latency is also a critical factor alongside availability, Option D could be a viable solution but may require additional considerations for handling complete failures in one Region.
AzureDP900 👍 1
C is right in my opinion. By using CloudFront distributions with ALBs as origins and setting up a failover routing record in Route 53 (Option C), you can create a setup where traffic is directed to the distribution (and thus the ALB) in the closer region, and automatically switched to the other Region if game assets become unavailable in the first one. This approach meets all of the requirements specified in the question.
chris_spencer 👍 2 Selected: A
A - This option leverages Amazon CloudFront, which is a global content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency, high transfer speeds, all within a developer-friendly environment. By setting up an origin group with the ALBs as origins and designating a primary origin, CloudFront automatically routes traffic to the second origin if the primary is unavailable. This setup addresses both the latency (by serving content from the nearest location due to CloudFront's global presence) and failover requirements effectively. B - does not serve geographic location C - works to but A is less complex D - It lacks a CDN which if preffered for this kind of solution
JoeTromundo 👍 2 Selected: D
Option D is the best solution because it uses Route 53 latency alias records to ensure that users access the closest AWS Region and provides failover capability with health checks, fulfilling both the proximity and reliability requirements. For option A to be correct, it should be described as CloudFront with Origin Groups. This allows you to set up a primary and a secondary origin. If the primary origin (the ALB in the primary Region) becomes unavailable, CloudFront automatically switches to the secondary origin (the ALB in the secondary Region). This provides the failover functionality, which means if the assets are unavailable in one Region, they can be fetched from the other Region.
Spike2020 👍 1
D - closest region indicate DNS based on latency. Not a failover scenario.
neta1o 👍 1 Selected: D
There are many factors in this question. But this "The company requires game assets to be fetched from the closest Region" points to 'D' latency based routing R53.
Moghite 👍 2 Selected: A
Option D incorrect because there is no automatic failover like in cloudFront option A
michele_scar 👍 3 Selected: A
We are talking about "GAME ASSETS" that by definitions are STATIC CONTENT. So for this reason we should keep A or C (CDN). The correct is A.
titi_r 👍 1 Selected: D
Answer: D.
yog927 👍 4 Selected: D
It is A or D. Not A because the request will be always routed to the primary origin, the requirement wants it to be routed to the closest region.
pangchn 👍 1 Selected: D
I vote for D reason same as Dgix mentioned in the correction, since question request game asset fetched from closed region
Russs99 👍 3 Selected: A
In option D, game will always be fetched from on region except the if the primary region fails. Option A allows for multiple origin, and caching.
AWSPro1234 👍 1
Answer is C Question ask in case of failover , not to monitor latency.
Dgix 👍 3 Selected: D
Moderator, please change my previous answer to D.
Dgix 👍 3 Selected: A
A, as CloudFront does both geographical proximity and origin failover and serves the assets from the closest region to the client. B doesn't do geo proximity. C is overengineered and does the same as A. D is viable, but uses DNS rather than CDN. So it's either A or D. Of the two, A is simpler.
CMMC 👍 3 Selected: C
CF for closest region, Route 53 failover to route and failover when one of the CFs is unavailable.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

Route 53 latency-based routing measures the latency between the client and each ALB and directs the request to the closest Region. Health checks on each ALB, combined with Evaluate Target Health set to Yes, cause the record to be replaced when the closest target becomes unhealthy, so requests fail over to the healthy Region. This satisfies both the closest-Region requirement and the availability requirement.

Why the Other Options Are Wrong

A: A CloudFront origin group with a designated primary origin always fetches from the primary and only uses the secondary on failure, so it does not fetch from the Region closest to the player, and per-origin cache behaviour must be configured. B: Route 53 failover routing records require two healthy targets and always prefer the primary, so it does not select the closest Region, and a failover record cannot be a plain latency choice. C: Two distributions behind a failover record would work for availability but still always prefer the primary distribution, so it does not meet the closest-Region requirement.

Community Comment Notes

The community was split 52 to 40 between D and A. The deciding argument was that latency-based routing is the only option that actually selects the closest Region, while CloudFront origin groups always resolve to the primary origin and only fail over on error.

Official Reference

Related Analysis

Practice All SAP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full SAP-C02 Practice Test →

← Back to SAP-C02 Study Guide