A latency-sensitive GIS app tier chats constantly with Redis and a database. Architects also require Multi-AZ resilience for the overall stack. How should they place resources?
Select an answer to reveal the explanation.
Short Explanation
Chatty neighbors should live on the same street for speed, but the city still needs a spare street if one floods. Keep caches and DBs close for latency, and keep Multi-AZ so an AZ loss is not a total outage.
Full Explanation
A latency-sensitive GIS application tier that chats constantly with Redis and a database needs physical and logical proximity: keep app, cache, and database nodes close within the same Region, favoring same-AZ locality for the chatty paths that dominate latency, while still deploying Multi-AZ architectures so the overall stack can fail over when an AZ is lost. Municipal GIS users feel every extra millisecond on map interactions; cross-Region placement of hot dependencies is the wrong “safety” trade for day-to-day performance, whereas Multi-AZ provides resilience without making every Redis GET travel to a distant metro.
Pinning every cache and database node exclusively in a distant Region from the app maximizes latency and undermines the sensitivity requirement. Placing caches only in public subnets in another account with no VPC connectivity breaks private data-plane access. Disabling Multi-AZ permanently so every dependency stays in one rack forever rejects the resilience requirement in the stem.
Exam caveat: same-AZ locality improves latency but concentrates risk; production designs often combine local preference with Multi-AZ replicas/failovers and careful DNS or client retry behavior. Cross-AZ data transfer also has cost and latency implications—know the tradeoff rather than always forcing cross-AZ for “best practice” slogans.
Operational check: measure app-to-Redis and app-to-DB latency in the chosen placement; perform an AZ failure drill and confirm GIS sessions recover via Multi-AZ standbys; and ensure security groups and subnets keep cache/DB private while remaining reachable from the app tier.