A regional building-department portal must keep database latency low for local staff while surviving an Availability Zone outage, and later may serve a second metro Region for DR locality. How should the architect place the database tier for performance and HA?
Select an answer to reveal the explanation.
Short Explanation
Put the records desk next to the clerks who use it, then give that desk a twin in another fire zone. Multi-AZ covers the building fire; another Region covers the metro disaster—without shipping every click across the country for no reason.
Full Explanation
A regional building-department portal must keep database latency low for local staff while surviving an Availability Zone outage, and may later serve a second metro for disaster-recovery locality. The sound placement pattern is to keep the primary database near the application tier in the working Region so inspectors and clerks do not pay cross-Region round trips for every form submit, and to enable Multi-AZ so a standby in another AZ can take over if the primary AZ fails. When DR and citizen locality across metros become requirements, add Multi-Region replicas or a cross-Region promotion plan—without moving the day-to-day primary far from the staff who use it. Proximity for performance plus Multi-AZ for HA, then Multi-Region when metro DR demands it, is the layered civic design.
Running a single-AZ database only in the farthest Region maximizes distance and latency for local staff while still failing the AZ outage requirement—geographic distance is not a substitute for Multi-AZ. Disabling Multi-AZ to keep writes on one host with no standby intentionally removes the HA the stem requires; a single building fire or AZ event takes down permitting. Storing the only copy of the database on a laptop VPN into the VPC fails durability, HA, shared access, and operational standards for a municipal system of record.
Exam caveat: Multi-AZ and Multi-Region solve different failure domains. Multi-AZ protects against AZ loss inside a Region with synchronous (or engine-managed) standby patterns; Multi-Region addresses regional disasters and locality but adds replication lag and failover complexity. Do not treat “put it far away” as automatic high availability.
Operational check: measure application-to-database latency from the building-department VPC; confirm Multi-AZ failover drills complete within accepted RTO; document when cross-Region replicas will be introduced for the second metro; and ensure DNS or endpoint promotion runbooks are tested before claiming DR readiness.