A stateful inspection app needs data that outlives pod rescheduling onto another node. Which storage choice best fits?
Select an answer to reveal the explanation.
Short Explanation
Stateful apps need luggage that follows them when the pod changes hotels. A persistent volume is that luggage. The container's scratch layer is a hotel notepad—gone at checkout.
Full Explanation
A persistent volume provides durable storage whose lifetime is independent of any single pod instance, so data remains when the orchestrator reschedules a stateful workload onto another node. A stateful inspection app that must keep data across pod moves therefore needs persistent volumes or an equivalent external durable store, not only the container’s writable layer. Relying only on the container’s writable layer means inspection data vanishes whenever the pod is replaced or the node is drained. A laptop bind-mount that exists solely on a developer workstation is unavailable to production cluster nodes and fails HA. In-memory tmpfs with no backing store loses inspections on restart and never provides durable disk-backed evidence storage. Exam caveat: persistent volumes address durability; some clustered databases also need stable network identity (for example StatefulSets)—persistence alone may be incomplete for those engines. Operational check: provision a persistent volume in the required zone with snapshots or replication, mount it into the inspection app, delete and reschedule the pod to prove data survival, encrypt volumes at rest, and include volume restore steps in the municipal DR runbook.