TL;DR: Instances spread across AZs while their dependencies do not: single-AZ databases, zonal load balancers or caches, zone-pinned stateful workloads, and capacity headroom that vanishes during regional stress. Availability is a property of every layer being multi-AZ plus enough slack to absorb the loss, not of where your VMs live.
How to approach it
State the principle first: a required dependency can cap end-to-end availability; serial dependency availability can be lower than that of any one layer, and spreading only one layer changes nothing. Then walk the coupling points where services silently re-attach themselves to one zone.
A strong answer
The compute tier gets all the attention because it is the easiest to make multi-AZ (an ASG with three subnets). The outage then arrives through everything behind and around it:
1. A single-AZ data tier. The app tiers are in three zones; the primary database is in one. Primary's zone degrades, writes fail, and read-heavy endpoints fail with them. Multi-AZ replication fixes promotion but not client behaviour (the previous question's territory), and sharded systems often place each shard's leader somewhere specific: lose that zone, lose those leaders.
2. Zonal chokepoints in front of or beside the compute. A self-managed nginx pair active/passive both registered in one zone, a NAT gateway in a single AZ for private subnets in others (traffic crosses zones, and when that zone goes, egress dies fleet-wide), an ElastiCache primary in the degraded zone serving sessions: any of these converts zonal impairment into global unavailability.
3. Zone-pinned scheduling and storage. Kubernetes nodes exist in three zones, but if most pods land in two (bin-packing pressure, no topology spread constraints) the third zone is decorative. StatefulSets with zonal volumes cannot reschedule out of the impaired zone at all: the PV lives in one zone by definition, so its pod waits there until the zone returns.
4. Headroom arithmetic under stress. Even perfectly spread fleets fail here. When one of three zones disappears, survivors must absorb 50 percent more traffic. If you run at 70 percent utilisation, survivors need 105 percent: they queue and fall over in sequence, which presents as "the whole region is sick" when actually each layer was fine until crowding finished it. This is the NALSD point wearing an operations hat: design for N+1 at peak, not at average.
The honest checklist I would audit against: every dependency named on the architecture diagram asked "which zones are YOU in?", including NAT, DNS, caches, queues and auth. Topology spread enforced rather than hoped for. Load tested at N-minus-one-zone with production-shaped traffic. And graceful degradation defined per dependency, because some functionality should keep working when a zone (and its cache tier) goes away.
Worth naming the deeper pattern too: cell-based architecture partitions the service into bounded, independently operating units behind a routing tier. A cell may span AZs or use a zonal design with a recovery strategy. One failed cell limits impact to its assigned users only if shared dependencies and routing preserve isolation. AWS cell architecture.
What interviewers probe next
"How do you test for zonal coupling before it costs you?" Inject zone-level failure in staging (block routes to one zone) and measure what breaks. Chaos tooling makes this routine; the discipline to run it quarterly is the rare part.
"Is multi-region the answer?" It answers a different question (regional outage) at much higher cost and consistency complexity. Fix zonal correctness first; most "we need multi-region" conclusions are unfixed multi-AZ gaps.
"What about the routing tier itself?" It must be genuinely global and boring: managed DNS with health checks, anycast edges. If your cell router is a single instance, you built a new single point in front of nine solved ones.
Common mistakes
Equating "instances in three subnets" with resilience. Subnet placement of web servers is the cheapest and least sufficient part of the design.
Auditing only first-order dependencies. The queue cluster's own single-AZ broker, the metrics store behind dashboards you need mid-incident: second-order failures decide incident quality.
Sizing for average load and calling it headroom. Peak times 1.5 is the number that matters when a zone leaves.