Library operators omit storageClassName on some PVCs and still receive dynamically provisioned volumes. What cluster setting explains that behavior?
Select an answer to reveal the explanation.
Short Explanation
Forget to pick a shelf label and the librarian still has a default shelf. Same idea: a StorageClass annotated as default quietly fills in when the PVC doesn’t name a class. That is convenience with a cost dial—know which class is default.
Full Explanation
Library operators who omit storageClassName on some PVCs yet still receive dynamically provisioned volumes are hitting a StorageClass marked as default. Kubernetes applies that default when the PVC leaves the class unset—convenient for common tiers, dangerous if the default is expensive or wrong for the workload. Knowing which class carries storageclass.kubernetes.io/is-default-class is part of municipal storage hygiene.
Omitting storageClassName does not always force static binding to any Available PV of any size. The API server does not invent an in-memory volume with no PersistentVolume object. An empty storageClassName does not disable persistence and mount emptyDir instead—emptyDir is a different volume type in the Pod spec.
Exam caveat: clusters may have zero or one intended default (multiple defaults are problematic). Explicitly setting storageClassName to an empty string can mean static binding only depending on API semantics—distinguish unset versus explicitly empty on exams.
Operational check: kubectl get storageclass and note the default marker, create a PVC without storageClassName, confirm it binds via that class’s provisioner, and document the default for application teams.