A citizen API is deployed in us-east-1 and us-west-2. The architect wants DNS to send each user to the Region that currently offers the lower latency. Which Route 53 policy fits?
Select an answer to reveal the explanation.
Short Explanation
Latency-based routing is the traffic cop that points each citizen toward whichever Regional API answers snappier from where they stand—no manual hosts files on phones.
Full Explanation
When a citizen API is deployed in us-east-1 and us-west-2 and DNS should send each user to the Region that currently offers lower latency, Amazon Route 53 latency-based routing is the matching policy. Route 53 maintains latency measurements between user networks and Regional endpoints and answers DNS with the record set that should yield better latency for that client, steering municipal API consumers toward the nearer/faster stack without hard-coding a single Region.
A single A record to one static IP that never changes Region cannot choose the lower-latency Region dynamically. Weighted routing used only to deliberately send everyone to the slower Region contradicts the latency goal (weights are for intentional traffic splitting, not latency optimization). Disabling geoproximity and replacing DNS with manual hosts-file entries on each phone is not an enterprise traffic-management design for citizens.
Exam caveat: latency-based routing is not health checking by itself—combine it with Route 53 health checks and failover or multi-value answers as required so unhealthy Regions are avoided. Latency routing differs from geolocation (based on user location maps) and geoproximity (bias from a geographic point). Pick latency when the stem stresses lower latency rather than political geography.
Operational check: create latency records for both Regional API endpoints with health checks; test resolution from multiple client networks; simulate a Region outage and confirm DNS stops handing out the unhealthy endpoint; and monitor citizen API latency by geography after cutover.