What are PersistentVolumes and PersistentVolumeClaims for?

WHAT THIS TESTS Whether you grasp the producer-consumer model Kubernetes uses for durable storage and why that indirection exists.

A GOOD ANSWER COVERS A PersistentVolume represents a real piece of storage in the cluster, such as an EBS volume, an NFS export, or a Ceph RBD image. It is a cluster-scoped resource with its own lifecycle, independent of any Pod that uses it. A PersistentVolumeClaim is how a workload asks for storage: it states the requested capacity, the desired access mode, and optionally a StorageClass, without naming a specific volume. The control plane's binding logic finds or provisions a PV that satisfies the claim and binds the two one-to-one. The Pod then references the PVC by name in its volumes, and the kubelet mounts the bound PV into the container. The value is decoupling: app authors think in terms of I need 10Gi read-write, while administrators or a provisioner handle which backend supplies it, how it is provisioned, and its reclaim behavior.

COMMON WRONG ANSWERS Saying the Pod mounts the PV directly, skipping the claim. Treating PV and PVC as interchangeable. Thinking a PVC creates storage by itself without a PV or provisioner. Forgetting the binding is one-to-one.

LIKELY FOLLOW-UPS What is dynamic provisioning and how does StorageClass fit in? What are access modes? What happens to the PV when the PVC is deleted, and how do reclaim policies differ?

ONE CONCRETE EXAMPLE An admin defines a 20Gi PV backed by NFS; a developer creates a PVC requesting 20Gi ReadWriteOnce; Kubernetes binds them; the Pod lists that PVC under volumes and mounts it at /data, never needing to know it is NFS underneath.