A public-health PVC remains Pending and events indicate the named StorageClass cannot provision. What is the most likely cause among these options?
Select an answer to reveal the explanation.
Short Explanation
A work order pointing at a workshop that isn’t on the map—or whose crew never showed up—just sits in Pending. If the StorageClass name is wrong or the CSI provisioner isn’t running, the PVC waits. DNS policy, RWO itself, and ServiceAccounts aren’t why the disk factory failed to start.
Full Explanation
When a public-health PVC remains Pending and events indicate the named StorageClass cannot provision, the most likely cause is that the referenced StorageClass does not exist or its provisioner/CSI driver is unavailable. A work order pointing at a missing workshop—or a workshop whose crew never showed up—simply waits. Fix the class name or restore the CSI controller before chasing unrelated Pod settings.
Pod dnsPolicy: ClusterFirst does not block PersistentVolumeClaims. Using accessModes: ReadWriteOnce does not forbid dynamic provisioning—RWO is a common mode for dynamically provisioned disks. Lacking a default ServiceAccount in the Namespace is unrelated to whether a StorageClass can provision volumes.
Exam caveat: also check ResourceQuota, topology constraints, and cloud credentials for the CSI driver—these can look like “cannot provision” too. Events on the PVC are the first evidence trail.
Operational check: kubectl get storageclass, describe the PVC for events, verify CSI controller Pods are Ready, fix class name or driver health, and watch the PVC become Bound. 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.