Exercise 2: Why This Capstone Uses Deployment+PVC, Not a StatefulSet — Possible Solution
====================================================================

Why the capstone uses a Deployment+PVC:

Per the chapter's own warn-box, this is explicitly named as "a
deliberate simplification" -- the capstone's actual goal is to
demonstrate the multi-tier ARCHITECTURE (how a frontend, backend, and
database fit together using Chapter 1-11's concepts: namespaces,
ConfigMaps/Secrets, Deployments, Services, PVCs, Ingress, probes, and
resource limits), not to teach the deepest-correct production storage
pattern for a database specifically. Since a Deployment and a PVC were
ALREADY covered in full in Chapters 5 and 8, reusing them here keeps
the capstone entirely within Course 1's own toolset, rather than
introducing a brand-new concept (StatefulSets) that Course 1 never
actually taught.

What specific problem a StatefulSet would solve that this simplified
setup doesn't fully address:

A single-replica Deployment+PVC works acceptably for a SINGLE database
instance -- but it doesn't address what happens if that database needs
to be SCALED to multiple replicas, or if the pod is replaced. Per
Chapter 3's pod-disposability material, an ordinary Deployment's pods
get new, arbitrary names and (without special configuration) don't
have a guaranteed STABLE identity or a reliably matched, dedicated
storage volume PER REPLICA if scaled beyond one instance -- all
replicas from a plain Deployment are meant to be interchangeable
"cattle," per Chapter 3's own framing, which is exactly wrong for a
database where each replica typically needs its OWN distinct, stable
identity and its OWN distinct, consistently-reattached storage volume
(not a randomly-assigned one) every time it restarts.

A StatefulSet (Course 2's `k8s2-1`) specifically solves this: it
provides stable, predictable network identity and a dedicated,
consistently-matched PersistentVolumeClaim per replica, which is
exactly the property a genuinely production-grade, potentially
multi-replica database needs and this capstone's simplified
single-replica setup doesn't need to address, precisely because it
only ever runs one replica.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the capstone's own stated reasoning (staying within
Course 1's toolset, since the point is architecture not deepest-
correct storage) and then identifies the SPECIFIC gap (per-replica
stable identity and storage matching, relevant once scaling beyond one
replica) that a StatefulSet exists to close, rather than vaguely
asserting "StatefulSets are better for databases" without explaining
the actual underlying reason.