A county storage vendor integrates a driver that dynamically provisions volumes for PersistentVolumeClaims. Which extension interface is that driver implementing?
Select an answer to reveal the explanation.
Short Explanation
When a PVC asks for a disk, the storage vendor’s driver answers through CSI—think “disk dock,” not “network cable” or “container starter.” CNI and CRI solve different problems. Dynamic provisioning for PVCs is classic CSI territory.
Full Explanation
A county storage vendor’s driver that dynamically provisions volumes for PVCs implements CSI—the interface for storage plugins and dynamic provisioning. When a PVC asks for a disk, the vendor answers through the disk dock, not the network cable or container starter. CNI assigns Pod IPs rather than provisioning disks. CRI manages container lifecycles for kubelet, not PVC provisioning. The Metrics Server API scrapes CPU/memory and does not provision volumes. Exam caveat: Dynamic provisioning for PVCs via StorageClass is classic CSI territory. Operational check: Install the CSI driver, create a StorageClass/PVC, confirm a PV binds, and mount it in a test Pod for the county workload. In municipal platform operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the cluster’s current minor version and addon revisions used by the civic platform team. Keep the verification evidence—command output or config snippets—with the municipal runbook so audits can prove the control was applied as designed.