Exercise 1: Multi-AZ vs. Multi-Region High Availability — Possible Solution
====================================================================

Deploying across multiple Availability Zones within one Region gives
real fault tolerance against the most common failure this design
protects against -- a single data center losing power, network
connectivity, or cooling -- while keeping every AZ within the same
Region physically close together (typically single-digit milliseconds
apart). This means an application spread across two or three AZs can
replicate data and fail over between them with minimal added latency,
and AWS's own managed services (RDS Multi-AZ, load balancers, auto
scaling groups) are built specifically to make this pattern close to
automatic.

Spreading across two entirely separate Regions solves a different,
much rarer problem -- an entire Region becoming unavailable, or a
legal/compliance requirement to keep a second, geographically distant
copy of data. It comes at real, higher cost: cross-Region data
replication is slower (often hundreds of milliseconds), harder to keep
consistent, and requires far more deliberate architecture (most AWS
services don't replicate across Regions automatically the way they do
across AZs within one Region).

ANSWER: Multi-AZ is the better FIRST step because it defends against
the most likely real failure (a single data center outage) at low
added latency and largely automatic tooling; multi-Region is a real,
valid next step once single-Region resilience is already solid and a
genuine business need (disaster recovery, data residency, extreme
availability requirements) justifies its real added cost and
complexity.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly distinguishes the two techniques by what specific
failure mode each one actually protects against, rather than treating
"more spread out is always safer" as self-evidently true -- and
reflects the real, standard AWS Well-Architected guidance that
multi-AZ, not multi-Region, is the default starting point for high
availability.