The voting results API SLA requires survival of an availability-zone failure. How should resources be provisioned?
Select an answer to reveal the explanation.
Short Explanation
If one city block loses power, the results API still has to answer from another block. Multi-AZ placement is that second block—redundancy for the SLA, not a lone laptop.
Full Explanation
Multi-AZ placement with redundant capacity provisions the voting results API so an availability-zone failure does not take the service down, matching an SLA that requires zone survival for election-night civic trust. Placing every production instance in a single AZ for simpler networking fails the SLA because a zone event becomes a total outage. Relying on a single laptop bastion as the only failover path fails as capacity and HA design; a bastion is not redundant API capacity. Disabling health checks to avoid false failovers during elections fails because unhealthy nodes would continue receiving citizen traffic. Exam caveat: availability requirements that name AZ failure map to multi-AZ (or equivalent) redundant provisioning—not to operational shortcuts that disable health. Operational check: deploy compute and load balancing across zones, test zone-loss drills before election windows, confirm data-plane replication meets RPO/RTO, and keep health checks armed with validated thresholds. In municipal platform operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand the failure modes avoided for citizen services. Re-check the decision after the next provider feature change or compliance update to ensure the same answer still holds for the city's estate.