CKA Troubleshooting Practice Question
You are troubleshooting a pod that is failing to start due to a volume mount error. The pod spec references a PersistentVolumeClaim (PVC) named 'data-pvc'. You run 'kubectl get pvc data-pvc -n default' and see the status is 'Pending'. Which of the following is the MOST likely cause?
⚠ Common exam trap
The trap here is assuming the PVC is waiting for a pod, when in fact PVC binding is independent of pod scheduling and depends on PV availability or provisioning.
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
✓
There is no available PersistentVolume that matches the PVC's storage class, access mode, and capacity requirements.
A PersistentVolumeClaim remains in Pending state when the Kubernetes control plane cannot find or provision a matching PersistentVolume. This typically happens when no PV meets the storage class, access mode, and capacity requirements, or when the dynamic provisioner fails. Investigating the PVC's events with 'kubectl describe pvc' will show the reason, such as 'no persistent volumes available for this claim' or provisioner errors. Ensuring a suitable PV or a working storage class is the resolution.
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 in the same namespace as the pod that is trying to use it.
Why it's wrong here
PVCs are namespace-scoped, and a pod can only reference a PVC in its own namespace. However, if the PVC were in a different namespace, the pod would fail to start with an error like 'persistentvolumeclaim not found', not because the PVC is Pending. The PVC status would be independent. The question states the PVC exists and is Pending, so namespace mismatch is not the cause of the Pending status.
- ✗
The PVC's storage class does not exist, so the PVC cannot be provisioned.
Why it's wrong here
If the storage class does not exist, the PVC would remain Pending, but the question does not specify that the storage class is missing. The more general cause is that no matching PV is available. While a missing storage class is a possible cause, it is not the most likely without additional evidence. The scenario implies the PVC is Pending due to lack of a suitable volume, which could be because the storage class is missing or because no PV matches.
- ✓
There is no available PersistentVolume that matches the PVC's storage class, access mode, and capacity requirements.
Why this is correct
A PVC remains Pending when the control plane cannot find a PV that satisfies its request. This could be because no PV exists, or existing PVs do not match the storage class, access modes, or capacity. If the PVC uses a storage class with a dynamic provisioner, the provisioner might be failing to create a volume. Checking the PVC events and the storage class configuration is necessary.
- ✗
The PVC is waiting for a pod to be scheduled before it can bind to a PersistentVolume.
Why it's wrong here
In Kubernetes, PVC binding is independent of pod scheduling. The PVC will bind to a suitable PersistentVolume (PV) as soon as one is available and matches the request, regardless of whether a pod is using it. If the PVC is Pending, it means no matching PV was found, or the storage class provisioner is failing. Waiting for a pod is not a valid reason for a PVC to remain Pending.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
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
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
Courseiva writes every CKA question from scratch — 726 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
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.