CKA Storage Practice Question
You create a StorageClass with volumeBindingMode: WaitForFirstConsumer. A PVC using this StorageClass is created but remains in 'Pending' state. The PVC expects a node with label 'disktype=ssd'. A suitable node exists. What is the MOST likely reason the PVC is still Pending?
⚠ Common exam trap
Many exam-takers assume a PVC will bind immediately if a matching node exists, overlooking that WaitForFirstConsumer deliberately delays binding until a pod consumes the PVC.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
No pod has been created that uses this PVC.
With volumeBindingMode: WaitForFirstConsumer, the PVC will not be bound to a PV until a pod that uses the PVC is scheduled. The PVC remains Pending because no pod has been created that references it, even though a matching node exists. The scheduler defers volume binding to ensure the PV is provisioned on the same node where the pod lands.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The node selector on the PVC is incorrect.
Why it's wrong here
PVCs do not have a nodeSelector field; only pods have nodeSelector, and StorageClass uses allowedTopologies or PV nodeAffinity to constrain where volumes can live. In WaitForFirstConsumer mode, the Kubernetes scheduler does not evaluate topology until a pod using the PVC exists. Even if node labels are missing or mismatched, the PVC would not become Pending at this stage; it is simply waiting for a consumer pod to trigger binding.
- ✗
The PVC requests a storage size larger than available.
Why it's wrong here
In WaitForFirstConsumer mode, no binding or provisioning attempt is made until a pod consumes the PVC, so the requested size is never compared against available PVs or storage capacity yet. A request that cannot be satisfied would still remain Pending after a pod appears, and the failure would surface as a volume provisioning error or an event, not as an immediate Pending state. Therefore, the size is not the cause of this particular Pending status.
- ✓
No pod has been created that uses this PVC.
Why this is correct
No pod has been created that uses this PVC, which is the defining characteristic of WaitForFirstConsumer. The storage controller intentionally defers PV binding and dynamic provisioning until a pod is scheduled, because it needs to know the pod's node and zone to select an appropriately local volume. Until that consumer exists, the PVC correctly remains in the Pending state.
- ✗
The persistentVolumeReclaimPolicy is set to Retain.
Why it's wrong here
persistentVolumeReclaimPolicy, whether Retain, Recycle, or Delete, governs the lifecycle of a PV after a PVC is released, not how or when a PVC becomes Bound. A Retain policy merely means an orphaned PV will keep its data for manual admin action after the PVC is deleted. This setting has no influence on the initial binding delay caused by WaitForFirstConsumer.
Go deeper
Related to this question
About these practice questions
This CKA question is part of Courseiva's 302-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.