Coastal residents report high latency to a single inland Region hosting a permit portal. What multi-Region reason best addresses that user experience?
Select an answer to reveal the explanation.
Short Explanation
Distance still matters—bits crawling across a continent feel sluggish on a permit form. Standing up a second Region nearer the coast is a classic reason to go multi-Region for lower end-user latency. One AZ, Glacier cold storage, or hard-coded IPs will not fix round-trip time for those coastal users.
Full Explanation
When coastal residents report high latency to a single inland Region hosting a permit portal, adding a second Region closer to those coastal users is the multi-Region reason that best addresses end-user latency. Placing compute and data closer to users—or steering users to the nearest healthy Regional endpoint—reduces round-trip time compared with forcing every coastal client inland.
Collapsing all traffic into one Availability Zone shortens nothing meaningful for distant users and hurts availability. Moving the database exclusively to S3 Glacier Deep Archive increases retrieval latency dramatically and is wrong for an interactive portal. Disabling DNS so clients hard-code a single IP removes failover and geographic flexibility.
Exam caveat: Multi-Region drivers commonly tested—DR/continuity, proximity/latency for users, and residency. Here the stem emphasizes user latency, so proximity is the rationale.
Operational check: evaluate a coastal Region for a read replica or active stack, use Route 53 latency-based routing or Global Accelerator as appropriate, measure citizen page-load times before/after, and keep residency and sovereignty constraints in the same design conversation so latency fixes do not break legal placement rules.