CKA Storage Practice Question
Which THREE statements about PersistentVolumeClaims (PVCs) are correct?
⚠ Common exam trap
Watch out — candidates often confuse PVCs as cluster-scoped resources (like PVs) or assume PVCs control PV reclaim policies, when in fact PVCs are namespaced and only request storage characteristics.
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
✓
A PVC binds to a PersistentVolume that satisfies its storage request and access modes.
Option B is correct because the PersistentVolume controller matches a PVC to a PV whose capacity meets or exceeds the PVC's spec.resources.requests.storage and whose access modes (e.g., ReadWriteOnce, ReadWriteMany) satisfy the PVC's spec.accessModes, then binds them. Option C is correct because a PVC can request a larger size by editing spec.resources.requests.storage, and the resize succeeds only if the bound StorageClass has allowVolumeExpansion: true and the underlying CSI driver supports expansion. Option E is correct because access modes are enforced by the PV/PVC binding: a PVC requesting ReadWriteMany that binds to a PV supporting ReadWriteMany can be mounted read-write by multiple Pods simultaneously (e.g., NFS or CephFS). Option A is wrong because the reclaim policy (Retain, Delete, Recycle) is defined on the PersistentVolume or inherited from the StorageClass, not on the PVC. Option D is wrong because a PVC is a namespaced resource, unlike the cluster-scoped PersistentVolume.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A PVC defines the reclaim policy for the underlying PersistentVolume.
Why it's wrong here
Reclaim policy is a property of the PersistentVolume object, not the claim. It is defined in the PV's `persistentVolumeReclaimPolicy` field and determines whether the underlying storage is Retained, Recycled, or Deleted after the PVC is released. A PVC cannot influence this lifecycle decision because its spec only expresses storage requirements such as capacity, access modes, and storage class.
- ✓
A PVC binds to a PersistentVolume that satisfies its storage request and access modes.
Why this is correct
Kubernetes matches a PVC to a PV by comparing requested capacity and access modes; the selected PV must have at least the requested storage size and advertise access modes that satisfy the claim. The control plane performs this binding automatically, and when a match is found, the claim and volume are bound in a one-to-one relationship, meaning no other PVC can use that same PV until the bound is released. If no suitable PV exists, the claim stays in Pending, awaiting either an administrator-created PV or a dynamically provisioned volume from the named StorageClass.
- ✓
A PVC can request storage expansion if the StorageClass allows it.
Why this is correct
StorageClass objects can set `allowVolumeExpansion: true`, which permits a PVC to increase its requested storage size post-creation. The expansion is performed on the underlying PersistentVolume, and the file system is automatically resized for supported volume plugins (e.g., CSI drivers, cloud disks). However, the operation can only enlarge capacity; decreasing the request is not supported, and the volume plugin must support online resizing for the change to take effect without restarting the Pod.
- ✗
A PVC is a cluster-scoped resource.
Why it's wrong here
PersistentVolumeClaims are namespaced resources: they exist within a specific Namespace and can only be used by Pods in that same Namespace. PersistentVolumes, in contrast, are cluster-scoped objects that are not tied to any Namespace and represent actual storage that exists across the entire cluster. This distinction is key to multi-tenancy: each Namespace can have its own claims, but they all compete for the same set of cluster-wide PVs (unless a StorageClass provisions dynamic volumes).
- ✓
A PVC can be mounted by multiple Pods if it is bound to a PV with ReadWriteMany access mode.
Why this is correct
Multiple Pods can mount the same PVC simultaneously only if the bound PersistentVolume uses an access mode that supports concurrent read/write from multiple nodes, such as ReadWriteMany (RWX). Access modes are an advertised capability of the storage backend (NFS, GlusterFS, CephFS), and the PV is annotated with the mode it supports. ReadWriteOnce (RWO) limits mounting to a single node, and ReadOnlyMany (ROX) permits multiple nodes but only for read-only access, so RWX is the required mode for this scenario.
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
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
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.