What is a StorageClass and dynamic provisioning?

WHAT THIS TESTS Whether you understand how Kubernetes automates storage creation and how that contrasts with manually pre-creating volumes.

A GOOD ANSWER COVERS A StorageClass is an admin-defined template describing a category of storage. It names a provisioner, typically a CSI driver, sets backend-specific parameters such as disk type or IOPS, and specifies a reclaimPolicy and a volumeBindingMode like WaitForFirstConsumer. In static provisioning, an administrator must manually create a PersistentVolume for each anticipated need, and PVCs bind only if a matching PV already exists, which does not scale and wastes capacity. With dynamic provisioning, a PVC simply references a StorageClass by name; the control plane invokes that class's provisioner, which creates the underlying disk and a corresponding PV sized to the claim, then binds them automatically. This means developers request storage self-service and the right volume appears without any manual admin step, while WaitForFirstConsumer can delay provisioning until a Pod is scheduled so the disk lands in the correct zone.

COMMON WRONG ANSWERS Thinking the StorageClass stores the data itself. Believing volumes always must be pre-created. Ignoring the provisioner field. Forgetting volumeBindingMode and its impact on zone-aware scheduling.

LIKELY FOLLOW-UPS What does WaitForFirstConsumer solve? How does the default StorageClass work? Can you set allowVolumeExpansion? How does the reclaimPolicy on a StorageClass propagate to dynamically created PVs?

ONE CONCRETE EXAMPLE An admin creates a StorageClass named fast with provisioner ebs.csi.aws.com and type gp3; a developer's PVC sets storageClassName fast and requests 50Gi; the CSI driver provisions a 50Gi gp3 volume and a PV, binding it automatically with no manual admin action.