Building-permits admins debate pre-creating PersistentVolumes versus letting a StorageClass mint them. Which statement correctly contrasts the workflows?
Select an answer to reveal the explanation.
Short Explanation
Static is stocking shelves ahead of time; dynamic is ordering from the warehouse when a claim arrives. Pre-create PVs if you want hand-picked binding, or point PVCs at a StorageClass and let the provisioner build volumes. Mixing up Ingress, hostPath-only myths, or “StorageClass does nothing” misses that fork.
Full Explanation
Building-permits admins contrasting workflows should remember: dynamic provisioning uses a StorageClass provisioner when a PVC is created, while static provisioning pre-creates PersistentVolumes for claims to bind. Static is stocking shelves ahead of time; dynamic is ordering from the warehouse when a claim arrives. Both end with a Bound PVC, but who creates the PV differs—and that choice matters for NFS exports, hand-tuned disks, or fully automated CSI clouds.
Static provisioning does not require Ingress, and dynamic provisioning is not “ConfigMaps only.” Dynamic provisioning does not always use hostPath, nor does static always use CSI—the plugin/CSI choice is orthogonal to static versus dynamic. Static and dynamic are not identical; PVCs do honor StorageClass names when configured for dynamic paths.
Exam caveat: a PVC can be written to bind a specific PV via selectors or volumeName in static scenarios. Mixing a dynamic class with expectations of a pre-created PV confuses troubleshooting.
Operational check: for a lab, create one PV manually and bind a PVC without a dynamic class, then create another PVC against a StorageClass and watch the provisioner mint a PV—compare events side by side for the permits team runbook.