CKA Storage Practice Question
A cluster administrator creates a StorageClass with the following YAML:
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast provisioner: kubernetes.io/aws-ebs parameters: type: gp2 reclaimPolicy: Delete volumeBindingMode: Immediate
A developer creates a PVC using this StorageClass. The PVC is created and remains in Pending state. What is the most likely cause?
⚠ Common exam trap
The trap here is that candidates may focus on PVC spec details like access modes or reclaim policies, but the core issue is that the provisioner is incompatible with the underlying infrastructure, which is a common real-world misconfiguration tested in the CKA Storage domain.
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 cluster is not running on AWS or the AWS cloud provider is not configured.
The StorageClass uses the provisioner `kubernetes.io/aws-ebs`, which is specific to the AWS cloud provider. If the cluster is not running on AWS or the AWS cloud provider is not properly configured (e.g., missing IAM roles, cloud-controller-manager not running), the provisioner cannot create the underlying EBS volume, leaving the PVC in a Pending state indefinitely.
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 volumeBindingMode is Immediate, which requires a different access mode.
Why it's wrong here
The `volumeBindingMode` set to `Immediate` means the PersistentVolume (PV) is provisioned and bound as soon as the PersistentVolumeClaim (PVC) is created, without waiting for a Pod that uses it. This mode does not impose any specific access mode requirements (e.g., ReadWriteOnce, ReadOnlyMany) on the volume. The access mode is a separate characteristic of the volume itself, defining how it can be mounted, and is specified in the PVC and PV, not dictated by `volumeBindingMode`. Therefore, `Immediate` mode itself would not prevent binding based on access mode.
- ✓
The cluster is not running on AWS or the AWS cloud provider is not configured.
Why this is correct
The `kubernetes.io/aws-ebs` provisioner is specifically designed to interact with the AWS EC2 API to create EBS volumes. For this provisioner to function correctly, the Kubernetes cluster must be running within an AWS environment, and the `kube-controller-manager` must be configured with the AWS cloud provider integration. If the cluster is not on AWS, or if the cloud provider integration is misconfigured or missing, the provisioner cannot authenticate or make API calls to AWS, leading to the PVC remaining in a `Pending` state indefinitely as it cannot provision the underlying storage.
- ✗
The PVC does not specify an access mode.
Why it's wrong here
PVCs without an access mode will default to the first access mode in the PV's list? Actually, PVCs must specify access modes. If omitted, the PVC will fail validation? In practice, accessModes is required. But the question says a PVC is created, so it likely has access modes. Even if missing, it would be rejected, not remain Pending.
- ✗
The reclaim policy is Delete, which prevents binding.
Why it's wrong here
The `reclaimPolicy` in a StorageClass, whether `Delete` or `Retain`, dictates the behavior of the underlying physical volume after the associated PersistentVolumeClaim (PVC) is deleted. It determines if the provisioned volume is automatically removed or kept for manual reclamation. This policy has no bearing on the initial binding process between a PVC and a PV, nor does it affect the dynamic provisioning of the PV itself. Therefore, a `Delete` reclaim policy would not prevent a PVC from binding or a PV from being provisioned.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
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.
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.
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.