Exercise 3: Scaling a StatefulSet Down Then Back Up — What Happens to the PVCs — Possible Solution
====================================================================

What happens during the scale-down (3 replicas -> 1):

Per the chapter's own warn-box, "scaling down does not delete the
removed replicas' PVCs" -- this is stated as "a deliberate data-safety
measure." When the StatefulSet is scaled from 3 down to 1, the pods
`db-1` and `db-2` are removed (in reverse order, per this chapter's
own ordered-deletion material -- `db-2` first, then `db-1`) -- but
their associated PersistentVolumeClaims (`data-db-1` and `data-db-2`,
following the naming pattern from `volumeClaimTemplates`) are
DELIBERATELY LEFT INTACT, untouched, and still consuming and billing
for storage, exactly as they were before the scale-down.

What happens on scaling back up (1 -> 3 again):

Because those PVCs were never deleted, when the StatefulSet is scaled
back up to 3 replicas, the newly recreated `db-1` and `db-2` pods will
be automatically REATTACHED to their SAME original PVCs
(`data-db-1`/`data-db-2`) -- meaning they come back with whatever data
was already on those volumes from before the scale-down, rather than
starting fresh and empty. This is actually the DESIRED behavior in
many cases -- if the scale-down was meant to be temporary, the data is
preserved and ready to resume exactly where it left off.

What this means for ongoing storage costs if not cleaned up manually:

If a team scales down and has NO intention of scaling back up again
(a genuinely permanent reduction, not a temporary one), those
orphaned PVCs continue to exist and continue billing for their
allocated storage INDEFINITELY, with nothing actively using them --
directly matching `cloud1-9`'s own orphaned-storage cost material from
Cloud Platforms (a terminated resource's leftover storage continuing
to accrue cost silently). Unless someone remembers to manually delete
the specific PVCs for replicas that are genuinely no longer needed,
this cost accumulates unnoticed, exactly the kind of "usual suspect"
cost anomaly that site's own Cloud Platforms course (`cloud2-7`)
teaches investigating for.

WHY THIS WORKS AS AN ANSWER
------------------------------
This traces the exact behavior the chapter's warn-box describes
(PVCs surviving scale-down) through both directions of the scenario --
what happens immediately at scale-down, and what happens later at
scale-up (data preserved, not lost) -- and then explicitly connects
the cost consequence to the specific Cloud Platforms cross-reference
the chapter itself makes, rather than treating the cost implication as
a new, disconnected point.