Exercise 1: Why Both Multi-AZ and Read Replicas Are Needed — Possible Solution
====================================================================

Multi-AZ and read replicas solve two genuinely different real
problems, even though both involve additional copies of a database.

Multi-AZ exists specifically for HIGH AVAILABILITY: its standby
replica sits idle from an application's own perspective, doing
nothing but staying synchronized, ready for RDS to automatically fail
over to it the moment the primary instance fails. It does not serve
real read traffic during normal operation.

Read replicas exist specifically for READ SCALING: they are
asynchronous copies applications can actively query, spreading real
read load across multiple instances instead of hammering the primary
with every request. They are not designed as an automatic failover
target the way a Multi-AZ standby is.

ANSWER: A single feature can't satisfy both real requirements because
each is built around a different underlying behavior -- Multi-AZ's
standby is passive and failover-ready but not queryable for normal
traffic, while a read replica is actively queryable but not the
automatic failover target Multi-AZ provides. Achieving both
automatic failover AND read-traffic scaling genuinely requires both
features running together, since neither one substitutes for what the
other specifically does.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly treats "more copies of the database" as insufficient
justification on its own, and instead explains the specific,
different real PURPOSE each feature serves -- exactly the distinction
the chapter's own tip-box warns against conflating.