Exercise 2: PVC/PV Relationship, and the Parallel to Services/Pods — Possible Solution
====================================================================

The PVC/PV relationship:

Per the chapter, a PersistentVolumeClaim (PVC) is how a POD requests
storage -- specifying how much space and what access mode it needs,
"without needing to know the underlying storage details." A
PersistentVolume (PV) is the actual, concrete piece of cluster storage
that gets matched, or "bound," to a PVC that requests compatible
characteristics. The pod itself only ever interacts with the PVC
directly (by referencing its name in `spec.volumes`, per this
chapter's own example) -- it never needs to know which specific PV,
or which underlying storage backend, is actually providing that
storage.

The structural parallel to Chapter 6's Service/pod relationship:

Per this chapter's own tip-box, this is the SAME pattern as Chapter
6's Service: a Service provides a stable, decoupled INTERFACE (its DNS
name/IP) that clients connect to, while the actual PODS backing that
Service can change constantly (created, destroyed, replaced) without
the client ever needing to know or care which specific pod is
currently handling the request.

The PVC plays the exact same INTERFACE role that a Service plays: an
application only needs to know about its PVC (just like it only needs
to know a Service's name), and Kubernetes transparently handles
matching that PVC to whatever specific PV actually satisfies it,
exactly the way a Service transparently handles matching a client
request to whatever specific pod is currently healthy.

In both cases, the pattern is: a STABLE, DECOUPLED CLAIM/INTERFACE
(PVC or Service) sits in front of a DYNAMIC, POTENTIALLY-CHANGING
BACKING RESOURCE (a bound PV, or a set of matching pods) -- letting
consumers (a pod needing storage, or a client needing to reach an
application) depend only on the stable interface, never on the
specific underlying resource providing it at any given moment.

WHY THIS WORKS AS AN ANSWER
------------------------------
This states the PVC/PV relationship in the chapter's own terms and
then explicitly walks through why it's structurally IDENTICAL to the
Service/pod pattern from Chapter 6 -- both being an instance of the
same "stable claim/interface decoupled from a dynamic backing
resource" pattern the chapter's own tip-box names directly, rather
than treating the parallel as a vague, unexplained similarity.