A county app pod mounts a PersistentVolumeClaim as a volume. What must be true before that pod can become Ready using the claim?
Select an answer to reveal the explanation.
Short Explanation
The pod is asking for a claimed disk. If the claim is still shopping for a volume, the pod waits—no Bound claim, no happy Ready mount.
Full Explanation
A county app Pod that mounts a PersistentVolumeClaim can only become Ready using that claim once the PVC is Bound to a PersistentVolume so the volume can attach and mount. The Pod is asking for a claimed disk; if the claim is still shopping, the Pod waits. Pending claims are not silently swapped for emptyDir by kubelet.
The PVC does not need to live in kube-system regardless of the Pod namespace—claims are namespaced with the workload. Retain reclaimPolicy is not an admission requirement for Pod readiness. Leaving the PVC Pending indefinitely will not produce a healthy Ready mount of the intended persistent volume.
Exam caveat: mount failures after Bound can still occur (attach errors, filesystem issues, node mismatch for RWO). Binding is necessary but not always sufficient. Watch Pod events for FailedMount alongside PVC status.
Operational check: kubectl get pvc until Bound, describe the Pod for volume events, confirm the mount path inside the container, and only then treat the county app as storage-ready. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork.