A records app must keep uploaded PDFs across Pod restarts and reschedules to other nodes. Which volume approach should the developer choose?
Select an answer to reveal the explanation.
Short Explanation
If the filing cabinet must still be there after the office moves floors, you need real persistent storage—a PVC—not a notepad that vanishes with the Pod (emptyDir).
Full Explanation
A records app that must keep uploaded PDFs across Pod restarts and reschedules to other nodes needs a PersistentVolumeClaim. The PVC abstracts durable storage so data outlives individual Pods; when the municipal records Pod moves to another node, the claim can reattach (subject to access mode and storage provider) and the files remain.
emptyDir sized large enough that Kubernetes “replicates it to every node” is fiction—emptyDir is Pod-local and deleted with the Pod. Relying only on the container writable layer loses data on restart. A hostPath that assumes the Pod always returns to the same node name is fragile under eviction and cluster maintenance.
Exam caveat: CKAD application developers create PVCs and mount them; StorageClass/PV provisioning is often admin-scoped. Match accessModes to the workload (RWO vs RWX).
Operational check: kubectl get pvc; mount claim in the Deployment; write a PDF; delete the Pod; confirm the new Pod still lists the file; kubectl describe pvc for Bound status. In municipal environments, document the chosen pattern in the service runbook so on-call engineers apply the same kubectl checks during incidents, and keep the change tied to the application Deployment or Job rather than ad-hoc node mutation.