CKA Storage Practice Question
A new StorageClass 'fast' is created with volumeBindingMode: WaitForFirstConsumer. A PVC using this StorageClass is created but no pod consumes it. What is the state of the PVC immediately after creation?
⚠ Common exam trap
Candidates often assume a PVC with a StorageClass will immediately bind to a dynamically provisioned PV, but WaitForFirstConsumer explicitly defers binding until a pod is scheduled, making Pending the correct state.
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
✓
Pending
When a StorageClass uses volumeBindingMode: WaitForFirstConsumer, the PVC will remain in a Pending state until a pod that uses it is scheduled. This is because the volume binding and provisioning are deferred until the first consumer (pod) is created, allowing the scheduler to consider the pod's node constraints when selecting the volume. Since no pod consumes the PVC immediately after creation, it stays Pending.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Bound
Why it's wrong here
When a StorageClass uses volumeBindingMode: WaitForFirstConsumer, the control plane deliberately delays the provisioning and binding of the PersistentVolume. Consequently, the PVC cannot immediately transition to the Bound state upon creation because no PV exists yet to bind to. The binding process only triggers once a Pod referencing the PVC is scheduled to a node.
- ✓
Pending
Why this is correct
The PVC will remain in the Pending state because the WaitForFirstConsumer mode instructs the volume controller to defer volume creation. This delay ensures that the PV is provisioned in a topology (like a specific availability zone) compatible with the node where the Pod is scheduled. Once the Pod is assigned to a node, the PV is provisioned and the PVC transitions to Bound.
- ✗
Lost
Why it's wrong here
The Lost status is reserved for scenarios where a previously bound PersistentVolume is deleted or becomes unavailable to its associated PersistentVolumeClaim. It does not represent the initial state of a newly created PVC waiting for dynamic provisioning. In this scenario, the PVC is healthy and simply waiting for a consumer Pod to trigger provisioning.
- ✗
The PVC will not be created
Why it's wrong here
The Kubernetes API server successfully validates and persists the PVC object in etcd regardless of the StorageClass's binding mode. The volumeBindingMode parameter only dictates the timing of the volume provisioning and binding lifecycle, not the API-level creation of the PVC resource itself. Thus, the PVC object is created normally but stays unbound.
Go deeper
Related to this question
About these practice questions
This CKA question is part of Courseiva's 726-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.