A city PVC must bind to an existing PV. Which combination of PVC requirements must match the PV for binding to succeed?
Select an answer to reveal the explanation.
Short Explanation
Think of the PVC as a rental request and the PV as the apartment. Size, how you need to enter (access modes), and the building class all have to fit—or the lease never binds.
Full Explanation
When a city PVC must bind to an existing PV, requested capacity, accessModes, and storage class (or matching labels/selectors when required) must be compatible with the PV. Think of the PVC as a rental request and the PV as the apartment: size, how you need to enter, and the building class all have to fit—or the lease never binds. Capacity on the PV must be at least what the claim requests, and access modes must be satisfiable by the volume.
Only matching PVC and PV names is insufficient; capacity and access modes are not ignored. A nodeSelector on the PVC is not the primary PVC-to-PV binding rule—node affinity belongs with Pods or volume topology. reclaimPolicy lives on the PV and is not a PVC field that must equal the PV for binding.
Exam caveat: volumeName can pin a PVC to a specific PV, but compatibility rules still apply. StorageClass empty-string versus unset semantics matter for static binding scenarios on some exam clusters.
Operational check: compare PVC requests and accessModes to candidate PVs, ensure class/selector criteria align, apply the claim, and confirm Bound status before mounting in a city workload Pod. 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.