CKA Storage Practice Question
A cluster uses a CSI driver for dynamic provisioning. An administrator creates a StorageClass with 'volumeBindingMode: WaitForFirstConsumer' and a PVC. The pod using the PVC is scheduled to a node. However, the PV is never provisioned. What is the most likely cause?
⚠ Common exam trap
Many candidates assume 'WaitForFirstConsumer' delays binding indefinitely or that a missing PV is the root cause, rather than recognizing that dynamic provisioning requires a functioning CSI driver to create the PV after scheduling.
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
✓
The CSI driver is not installed or malfunctioning.
When `volumeBindingMode: WaitForFirstConsumer` is set, the PV is not provisioned until a pod using the PVC is scheduled to a node. If the PV is never provisioned after scheduling, the most likely cause is that the CSI driver is not installed or malfunctioning, because the dynamic provisioning request is sent to the CSI driver, and without a functioning driver, the PV creation will fail silently or not occur at all.
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 PVC is not bound to a PV because no PV exists.
Why it's wrong here
While the PVC will indeed remain unbound as long as no PV exists, the real defect is that dynamic provisioning never invoked the CSI driver to create a PV. In a WaitForFirstConsumer StorageClass, it is expected that no PV exists until a Pod consuming the PVC is scheduled; at that point the external-provisioner should contact the CSI driver and construct a PV. Because the PV is missing even after scheduling, the statement is merely a symptom, not the underlying cause—the driver's CreateVolume call has not succeeded.
- ✓
The CSI driver is not installed or malfunctioning.
Why this is correct
The StorageClass references a CSI provisioner (e.g., csi.contoso.com), and Kubernetes relies on the external-provisioner sidecar to send CreateVolume RPCs to the CSI driver controller. If that driver controller is not installed, the DaemonSet pods are CrashLooping, or the CSI socket is unavailable, the provisioner cannot create the backend volume, so no PV is bound and the PVC remains Pending with events like 'Failed to provision volume with storage class'. Inspecting the csi-controller logs and the driver DaemonSet status will confirm the malfunction.
- ✗
The pod does not have the correct node selector.
Why it's wrong here
Node selectors constrain where a Pod can be scheduled, not how storage is provisioned. The question states the Pod is already scheduled, meaning the selector, if any, already matched a node, so it cannot be responsible for the missing PV. Moreover, even if the Pod had an incorrect selector, it would remain Pending indefinitely and the WaitForFirstConsumer binding would never be triggered—but that is a scheduling failure, not a storage provisioning failure, and is not the situation described.
- ✗
The StorageClass uses 'Immediate' binding mode.
Why it's wrong here
The binding mode on a StorageClass controls when the volume is provisioned and bound. If it were 'Immediate', the PVC would trigger provisioning right away, even before a Pod exists, and would also require a functioning CSI driver to succeed. Since the described scenario uses WaitForFirstConsumer, the delay is intentional and correct: it lets the scheduler pick a node and only then asks the CSI driver to create a volume. Thus, this setting is not a malfunction—the driver being unresponsive is the actual reason the volume is never provisioned.
Go deeper
Related to this question
Learn chapter
Configuring Core Cluster Components
Key term
Storage Classes
A Storage Class in Kubernetes is a template that defines how persistent storage is provisioned automatically, including the type of storage, performance characteristics, and provisioning policies.
Key term
Persistent Volumes
A Persistent Volume is a piece of storage in a Kubernetes cluster that has been provisioned by an administrator and exists independently of any single pod that uses it.
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.