Question 4
Domain 4: StorageIn a Kubernetes StorageClass using local volumes, what is the effect of setting volumeBindingMode to WaitForFirstConsumer on a PVC?
Correct answer: A
Explanation
With "WaitForFirstConsumer," the PVC is not bound immediately; it remains Pending until a Pod references it and the scheduler picks a node. This delays provisioning or binding so the local volume can be placed on the same node the Pod will run on, matching the storage topology.
Why each option is right or wrong
A. The PVC stays Pending until a Pod that uses it is scheduled, so binding happens after the scheduler selects a node
Under the Kubernetes StorageClass API, `volumeBindingMode: WaitForFirstConsumer` defers PV binding/provisioning until scheduling time, rather than binding a PVC immediately when it is created. In practice, the claim remains in `Pending` until a Pod that references it is considered by the scheduler, which then selects a node first and only afterward allows the volume to bind on a topology-compatible node; this is the intended behavior for local volumes, where the storage is node-specific.
B. The PVC binds immediately to any matching PV as soon as it is created
C. The PVC can only bind if the StorageClass uses the default provisioner
D. The PVC becomes Bound only after the PV is manually mounted into the node filesystem