Exercise 1: The Two StatefulSet Guarantees, and Why a Multi-Replica Database Needs Both — Possible Solution
====================================================================

The two guarantees, per the chapter:

1. STABLE, PREDICTABLE NETWORK IDENTITY -- each pod gets a predictable,
   persistent name (like `db-0`, `db-1`, `db-2`) that stays the SAME
   even if that specific pod is recreated or rescheduled, unlike a
   Deployment's pods, which get a new random suffix each time they're
   replaced.

2. STABLE STORAGE -- each replica gets its OWN PersistentVolumeClaim,
   and when a pod is recreated, it's automatically REATTACHED to the
   SAME PVC it had before, not a fresh or randomly assigned one.

Why a multi-replica database needs BOTH:

Consider a 3-node database cluster where `db-0` is the primary (the
one that accepts writes) and `db-1`/`db-2` are replicas that
continuously sync data FROM the primary specifically.

Without STABLE IDENTITY: if `db-0` is replaced and comes back with an
entirely different, unpredictable name/address (as a Deployment's pod
would), every other component that was configured to know "the
primary is at db-0" would lose track of which pod is now actually the
primary -- there would be no reliable way to keep addressing the
correct, specific node after a replacement.

Without STABLE STORAGE: even if `db-1` kept the same identity after
being recreated, if it were reattached to a DIFFERENT, empty PVC
instead of the one holding its actual replicated data, it would come
back with NO DATA at all -- effectively becoming a brand-new, empty
replica rather than resuming from where it left off, which would be
catastrophic for a database expected to retain its own copy of the
data.

Both guarantees are needed TOGETHER because a database replica's
IDENTITY and its DATA are meaningless without each other -- knowing
which specific node `db-1` is (identity) is only useful if `db-1`
consistently comes back with `db-1`'s own actual data (storage)
attached, not a stranger's or an empty one. A StatefulSet providing
only one of the two guarantees would still leave the other half of the
problem completely unsolved.

WHY THIS WORKS AS AN ANSWER
------------------------------
This states both guarantees directly from the chapter and then
constructs a concrete failure scenario for EACH ONE missing
individually, showing that a multi-replica database genuinely needs
both simultaneously -- not just as separate, individually nice-to-have
features, but as two halves of a single coherent requirement (a
specific, addressable node consistently holding its own specific
data).