A public-health team has an existing NFS export and wants static provisioning. What is the correct workflow?
Select an answer to reveal the explanation.
Short Explanation
Static provisioning means you hand-build the PV for storage that already exists, then let the PVC grab that prepared volume—like listing a house before someone rents it.
Full Explanation
A public-health team with an existing NFS export wanting static provisioning should have an administrator define a PersistentVolume describing that NFS export, then let a PVC bind to that PV. Static provisioning means you hand-build the PV for storage that already exists, then let the claim grab the prepared volume—like listing a house before someone rents it.
Creating only a StorageClass with no provisioner does not invent NFS servers automatically. Creating the PVC first does not make Kubernetes create an NFS export on the master. Annotating emptyDir with nfs.server does not make a PV optional for real NFS persistence.
Exam caveat: PV must include correct NFS server/path, accessModes, and capacity; PVC must be compatible. SELinux/mount options and network reachability from nodes matter operationally beyond the API objects.
Operational check: create the NFS PV, create a matching PVC, confirm Bound, mount in a health Pod, and read/write a test file on the export. 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.