A school district workload uses only emptyDir volumes and no PersistentVolumeClaims. Must the cluster install a CSI driver for those Pods to run?
Select an answer to reveal the explanation.
Short Explanation
emptyDir is like a scratch pad the node creates for the Pod’s lifetime—no external SAN ticket required. CSI shines when you want dynamic disks for PVCs. Scratch-only workloads can run without a CSI driver.
Full Explanation
A school district workload using only emptyDir volumes does not need a CSI driver: emptyDir is node-local ephemeral storage tied to the Pod lifecycle, like a scratch pad with no external SAN ticket. CSI shines for dynamic disks behind PVCs; scratch-only labs can run without it. Not every volume type requires CSI; emptyDir is provided by kubelet without an external driver. emptyDir is not provisioned only through an external StorageClass and CSI. emptyDir is not implemented exclusively by the CNI plugin. Exam caveat: Require CSI when PVCs need external/dynamic volumes—not for emptyDir-only apps. Operational check: Deploy the emptyDir workload without CSI, confirm the volume works, and introduce CSI only when PVC-backed storage is required. 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.