A city platform team wants SSD-backed volumes for municipal databases created automatically via CSI. What must their StorageClass define to enable that dynamic path?
Select an answer to reveal the explanation.
Short Explanation
A StorageClass is like a catalog card that says which workshop builds your disks. The provisioner name is the workshop—your CSI driver—and parameters are the build options (SSD, IOPS, and so on). Without that provisioner pointer, Kubernetes has no factory to call when a PVC shows up.
Full Explanation
A city platform team that wants SSD-backed volumes created automatically via CSI must define a StorageClass whose provisioner field names the CSI driver, plus any driver-specific parameters for disk type, IOPS, encryption, or zones. The StorageClass is the catalog card pointing at the workshop that builds disks on demand when a PVC references the class. Without that provisioner identity, Kubernetes has no factory to call for dynamic municipal database volumes.
A reclaimPolicy of Retain alone with no provisioner describes post-release cleanup for existing PVs; it does not enable CSI dynamic creation. A hostPath template under volumes is node-local and not a StorageClass CSI provisioner path. An Ingress class name has nothing to do with disk creation—HTTP routing does not trigger volume provisioning.
Exam caveat: the CSI driver controllers and node plugins must actually be installed and healthy; a StorageClass naming a missing provisioner leaves PVCs Pending. Parameters are opaque to Kubernetes core and interpreted by the driver—spell keys exactly as the driver documents.
Operational check: create a StorageClass with the CSI provisioner and SSD parameters, submit a PVC referencing that class, watch a PV appear Bound, and mount it in a database Pod to confirm the volume type matches the municipal SSD tier.