CKA Storage Practice Question
Which THREE of the following are true about expanding a PersistentVolumeClaim?
⚠ Common exam trap
Many candidates think a pod must be recreated for the new size to take effect, but Kubernetes handles filesystem resizing automatically for supported plugins, making option A a common distractor.
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 StorageClass must have allowVolumeExpansion: true.
Option C is correct because a PersistentVolumeClaim can only be expanded if its StorageClass explicitly sets allowVolumeExpansion: true; without this field, the API server rejects the resize request. Option D is correct because even with allowVolumeExpansion enabled, the underlying CSI or in-tree volume plugin must actually support online or offline expansion for the operation to succeed. Option E is correct because the standard way to request more capacity is to edit the PVC's spec.resources.requests.storage field to a larger value, which triggers the resize workflow. Option A is not universally true: many CSI drivers support online expansion so the pod does not need to be recreated, and only certain filesystem-resize cases require a pod restart. Option B is incorrect because Kubernetes does not support shrinking a PVC; the requested storage can only be increased, never decreased.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
After expanding the PVC, the pod must be recreated for the new size to take effect.
Why it's wrong here
In Kubernetes, expanding a PersistentVolumeClaim does not require recreating the Pod that uses it. For volume plugins that support online expansion, the increased capacity becomes available to the Pod immediately, and the kubelet automatically resizes the filesystem while the Pod remains running. If the underlying volume plugin does not support online expansion, the volume may have to be detached from a node before the new size takes effect, but this is handled by the system and does not involve deleting and recreating the Pod.
- ✗
You can reduce the size of a PVC after creation.
Why it's wrong here
A PersistentVolumeClaim's requested storage size can only be increased, never decreased. The spec.resources.requests.storage field is immutable in terms of reducing the value; the API server rejects any attempt to set a lower capacity, and the Kubernetes storage controller has no shrink operation. This limitation exists because shrinking an underlying storage volume would risk data corruption or loss and is not supported by any volume plugin or CSI driver.
- ✓
The StorageClass must have allowVolumeExpansion: true.
Why this is correct
The StorageClass referenced by a PersistentVolumeClaim must have the allowVolumeExpansion field set to true for PVC expansion to be permitted. This field tells the PersistentVolumeController that claims using this class are eligible for resizing, and it enables the controller to process updates to the requested storage size. If the field is false or omitted, the API server—or the external controller—will not allow the PVC's storage request to be increased, and any such edit will either be rejected or have no effect on the actual volume.
- ✓
The volume plugin must support expansion.
Why this is correct
Even if the StorageClass allows expansion, the actual volume plugin or CSI driver must implement the resize capability in its provisioning and node-stage code. Kubernetes can only update the PVC object; it relies on the plugin to call the underlying storage system to enlarge the volume and then resize the filesystem on the host. Some legacy in-tree volume plugins and certain CSI drivers do not support expansion, so the PVC's status.capacity will remain unchanged even after the request is increased.
- ✓
You can expand a PVC by editing its spec.resources.requests.storage field.
Why this is correct
The supported way to increase a PersistentVolumeClaim's capacity is to edit its spec.resources.requests.storage field, for example via kubectl edit pvc <name>, changing the request to a larger value. After the edit is saved, the volume controller compares the requested size with the current status.capacity and triggers an expansion operation on the storage backend. Once the backend completes the resize, the PVC's status.capacity is updated, and, if needed, the kubelet performs a filesystem expansion on the attached volume.
Go deeper
Related to this question
Learn chapter
Installing Kubernetes with kubeadm
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
Volumes
In Kubernetes, a volume is a storage resource that outlives the pod it belongs to, enabling data to persist across container restarts and be shared between containers in the same pod.
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 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.