CKA Storage Practice Question
You are a cluster administrator managing a production Kubernetes cluster that hosts a stateful application using StatefulSets with PersistentVolumeClaims (PVCs) backed by a cloud provider's persistent disk. A developer reports that a new pod in the StatefulSet is stuck in 'Pending' state. You describe the StatefulSet and see that it has 3 replicas. Two pods are Running, but the third pod (pod-2) is Pending. You check the PVC for pod-2 and see it is 'Pending'. The StorageClass uses 'WaitForFirstConsumer' volume binding mode. The node where pod-2 should run has sufficient resources. Other PVCs in the same namespace bound successfully. What is the most likely cause of the pending PVC and pod?
⚠ Common exam trap
Many candidates assume a Pending PVC is always due to insufficient storage capacity or quota, ignoring the impact of volume binding modes and nodeAffinity constraints on 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 PV that should bind to the PVC has a nodeAffinity that does not match any available node.
With 'WaitForFirstConsumer' volume binding mode, the PVC binding is deferred until a pod using it is scheduled. The PV that should bind to the PVC has a nodeAffinity that does not match any available node, preventing the scheduler from binding the PVC and scheduling the pod. This results in both the PVC and pod remaining in 'Pending' state, even though the node has sufficient resources.
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 PV that should bind to the PVC has a nodeAffinity that does not match any available node.
Why this is correct
When a PersistentVolumeClaim (PVC) uses the WaitForFirstConsumer binding mode, the selection or provisioning of a PersistentVolume (PV) is delayed until a pod requiring that PVC is scheduled. If the selected PV has nodeAffinity rules that do not match the node where pod-2 was scheduled, the volume attachment will fail. This mismatch prevents the volume from being mounted, causing pod-2 to remain in a Pending state, unable to start its containers.
- ✗
The CSI driver is not installed on the node where pod-2 is scheduled.
Why it's wrong here
If the Container Storage Interface (CSI) driver were genuinely missing or improperly installed on the specific node where pod-2 is scheduled, it would likely affect all pods attempting to use CSI-provisioned storage on that node. Since other pods are successfully mounting their volumes and running, it indicates the CSI driver is operational on at least some nodes. A missing driver would typically manifest as volume attachment errors for any pod on that node, not just an isolated incident for pod-2.
- ✗
The PVC's requested storage size exceeds the available capacity in the cloud provider's quota.
Why it's wrong here
Cloud provider quotas typically apply to the total amount of resources provisioned within a project or account, or to individual resource creation limits. If the requested storage size exceeded the quota, the PersistentVolumeClaim (PVC) itself would likely fail to bind or provision a PersistentVolume (PV) in the first place, often with a specific error indicating quota exhaustion. The fact that other PVCs have successfully bound and are in use suggests that the overall quota is not the primary issue preventing pod-2's PVC from functioning.
- ✗
The PVC's access mode is ReadWriteOnce, but the pod requires ReadWriteMany.
Why it's wrong here
PersistentVolumeClaims (PVCs) with ReadWriteOnce access mode can only be mounted by a single node at a time, whereas ReadWriteMany allows multiple nodes to mount the volume concurrently. If pod-2 truly required ReadWriteMany but the PVC was ReadWriteOnce, it would cause a volume mount error. However, the problem statement implies other pods are using similar PVC configurations successfully, suggesting the access mode itself is not inherently incompatible with the application's general requirements across the cluster, or that pod-2's specific requirement is not unique.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
About these practice questions
Courseiva writes every CKA question from scratch — 302 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.