A PDF-render sidecar needs scratch space that must disappear when the Pod is deleted. Which volume type fits best?
Select an answer to reveal the explanation.
Short Explanation
emptyDir is a whiteboard in the meeting room: great while the meeting (Pod) is going, wiped when everyone leaves. Perfect scratch space for a PDF sidecar.
Full Explanation
A PDF-render sidecar that needs scratch space which must disappear when the Pod is deleted should use an emptyDir volume. emptyDir exists for the Pod’s lifetime, can be mounted by multiple containers in that Pod, and is deleted when the Pod goes away—perfect for municipal render scratch that must not linger on nodes after the job finishes.
A cluster-wide NFS PersistentVolume claimed for every render Pod adds durability you do not want for ephemeral scratch and complicates cleanup. A hostPath to the node’s root disk can survive rescheduling poorly and risks filling node disks with leftover PDFs. A ConfigMap storing binary PDF scratch as keys is the wrong API: ConfigMaps are for configuration data with size limits, not scratch binaries.
Exam caveat: emptyDir may use disk or medium: Memory. It is not replicated across nodes. Choose PVC when uploads must survive Pod replacement.
Operational check: mount emptyDir at /scratch in app and sidecar; render a file; kubectl delete pod and confirm the node path is gone; compare with a PVC-backed path that would retain objects. 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.