A county elections office is deploying a voter-results API and needs high availability within one AWS Region. What design choice best meets that goal?
Select an answer to reveal the explanation.
Short Explanation
Think of Availability Zones like separate power grids in the same city—if one goes dark, the other can still serve results night. Spreading the voter-results API across at least two AZs in the Region is how you get high availability without leaving the Region. One AZ or one giant box is a single point of failure; edge cache alone is not your API compute.
Full Explanation
A county elections office deploying a voter-results API that needs high availability within one AWS Region should place the API across at least two Availability Zones in that Region. Multi-AZ design spreads load balancers, compute, and typically the data tier across isolated AZs so a failure in one AZ does not take down the entire API on election night. Within a single Region, multi-AZ is the foundational high-availability pattern Cloud Practitioner expects.
Running every instance in a single AZ simplifies networking only by accepting a larger blast radius—opposite of HA. Using only CloudFront edge locations instead of any Regional compute cannot host a typical dynamic voter-results API’s authoritative processing and data plane. Relying on one large EC2 instance creates a single point of failure rather than eliminating failovers.
Exam caveat: “High availability within one Region” → multi-AZ, not multi-Region (that is broader DR) and not single large instance. Edges help content delivery; they do not replace multi-AZ Regional architecture for APIs.
Operational check: put an Application Load Balancer across AZs, run API tasks/instances in at least two AZs, use a Multi-AZ database if relational state is required, test AZ impairment in a game day before elections, and document RTO/RPO separately if statewide multi-Region DR is also mandated.