CKA Storage Practice Question
An administrator needs to expand a PersistentVolumeClaim (PVC) that is currently bound to a PersistentVolume (PV). The PV is provisioned by a storage class that supports volume expansion. What must the administrator do to increase the PVC's storage size?
⚠ Common exam trap
The trap here is that candidates mistakenly think they must delete the PVC or PV to change storage size, but Kubernetes allows in-place expansion via PVC spec update when the StorageClass supports it.
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
✓
Update the PVC's spec.resources.requests.storage to a larger value.
Kubernetes supports expanding PersistentVolumeClaims (PVCs) if the underlying StorageClass has `allowVolumeExpansion: true`. The administrator only needs to edit the PVC's `spec.resources.requests.storage` field to a larger value; the system automatically triggers the expansion of the bound PersistentVolume (PV) and the actual storage backend, provided the volume driver supports it. No pod deletion or PVC recreation is required.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Delete the pod that uses the PVC and recreate it with a larger claim.
Why it's wrong here
Deleting and recreating the pod does not affect the size of the underlying PersistentVolumeClaim, as pods only reference claims rather than defining their storage capacity. To resize a volume, the administrator must modify the PVC resource definition itself. Depending on the StorageClass configuration, the pod might only need a restart to mount the expanded file system, but the expansion process itself must be initiated on the PVC.
- ✗
Edit the PV's capacity and then the PVC's capacity.
Why it's wrong here
Manually editing the PersistentVolume (PV) object directly is an anti-pattern because the PV's capacity is managed and dynamically updated by the external volume provisioner. Modifying the PV directly can lead to state desynchronization between the Kubernetes control plane and the actual storage backend. The correct workflow is to edit the PVC, which triggers the controller to resize both the physical volume and the PV object automatically.
- ✗
Delete the PVC and recreate it with a larger size.
Why it's wrong here
Deleting the PVC is highly destructive and will trigger the volume's reclaim policy, potentially deleting the underlying physical storage and all its data if set to Delete. Kubernetes natively supports online or offline non-destructive volume expansion. Modifying the existing PVC in-place preserves the binding, the PV, and the stored data while requesting additional capacity from the storage provider.
- ✓
Update the PVC's spec.resources.requests.storage to a larger value.
Why this is correct
Increasing the value of spec.resources.requests.storage in the PVC manifest is the standard, declarative way to trigger volume expansion in Kubernetes. For this operation to succeed, the underlying StorageClass must have the allowVolumeExpansion field set to true. Once updated, the control plane coordinates with the CSI driver to resize the physical volume and subsequently expand the file system on the node.
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
Troubleshooting Storage Persistence
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.
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.
About these practice questions
One of 726 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.