CKA Storage Practice Question
A developer creates a YAML manifest for a pod that uses a PersistentVolumeClaim. The PVC requests 5Gi of storage but the only available PV has 10Gi. What will happen when the pod is created?
⚠ Common exam trap
A common mix-up: candidates assume the PVC must match the PV exactly in size, leading them to incorrectly choose that the PVC will not bind and the pod will remain Pending.
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 PVC will bind to the PV and the pod will run.
PersistentVolumeClaims (PVCs) bind to PersistentVolumes (PVs) based on satisfying the requested storage size and access modes. Kubernetes allows a PVC to bind to a PV that has equal or greater capacity than requested; the PVC will consume only its requested amount (5Gi) from the larger PV (10Gi). Once bound, the pod referencing the PVC can start successfully because the storage claim is satisfied.
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 will be resized to 5Gi to match the PVC.
Why it's wrong here
Kubernetes never resizes a PersistentVolume to match a PVC's requested capacity. A PV's size is fixed when it is created, and the binding process only evaluates whether the PV already has enough capacity to satisfy the claim. Resizing a PV would require an explicit update (or volume expansion, if enabled) and is not triggered by PVC creation.
- ✓
The PVC will bind to the PV and the pod will run.
Why this is correct
The PVC binds to the PV because the PV's capacity is greater than the requested storage, which Kubernetes allows. Once bound, the pod's volume mount is fulfilled and the pod can schedule and run normally. The PV capacity just needs to be equal to or larger than the PVC request, along with satisfying access modes and storage class.
- ✗
The PVC will not bind and the pod will remain Pending.
Why it's wrong here
The PVC will not remain Pending because there is an existing PV that meets the claim's capacity and other binding requirements. Pending happens only when no PV can satisfy the request, such as when every available PV has less storage than requested. Here the larger PV can be bound, so the pod's scheduler will not be blocked by an unbound claim.
- ✗
The PVC will bind but the pod will be OOMKilled.
Why it's wrong here
OOMKilled is a container runtime state caused by a container exceeding its memory limit, which is unrelated to PVC binding or volume access. Binding a PVC does not allocate memory or alter the pod's memory limits, so it cannot cause an out-of-memory kill. The pod will run its containers normally after the volume is successfully mounted.
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
One of 302 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.