CKA Storage Practice Question
Which THREE of the following are true about the interaction between PersistentVolumeClaims and pods?
⚠ Common exam trap
Test-takers frequently confuse PVCs with ephemeral volumes like emptyDir, assuming PVCs are automatically cleaned up with the pod, but Kubernetes explicitly separates PVC lifecycle from pod lifecycle to preserve data.
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 is namespace-scoped and can only be used by pods in the same namespace
Option A is correct because PersistentVolumeClaims are namespace-scoped API objects, so a pod can only reference a PVC that exists in its own namespace. Option D is correct because a pod that references a PVC requires that claim to exist and be bound (or bindable) before the pod can be successfully scheduled and started. Option E is correct because a PVC's access modes determine multi-pod use: ReadWriteMany or ReadOnlyMany allow multiple pods to mount the same claim, while ReadWriteOnce restricts it to a single node. Option B is wrong because a PVC can be shared by multiple pods when the access mode permits it, such as ReadWriteMany. Option C is wrong because deleting a pod does not delete its PVC; the claim persists until it is explicitly deleted, and its reclaim policy governs the underlying 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 is namespace-scoped and can only be used by pods in the same namespace
Why this is correct
A PersistentVolumeClaim is a namespaced resource, meaning it exists within a specific Kubernetes namespace. A pod can only reference a PVC by name within its own namespace; if a pod attempts to use a PVC from another namespace, the claim will not resolve. This namespacing mirrors other Kubernetes objects like ConfigMaps and Secrets. Thus, to share a volume across namespaces, you must use a distributed filesystem with subpaths or a ClusterRole, not cross-namespace PVC references.
- ✗
A PVC can only be used by a single pod at a time
Why it's wrong here
A single PVC is not restricted to one pod because access modes operate at the node level rather than the pod level. A ReadWriteOnce volume can be mounted by multiple pods simultaneously as long as they reside on the same node, while a ReadWriteMany volume allows pods across many nodes to mount it concurrently. The limitation, if any, comes from the underlying storage's access mode, not from any inherent single-use property of the PVC object itself. Therefore, the claim that only one pod can ever use a PVC is false.
- ✗
When a pod is deleted, its attached PVC is automatically deleted
Why it's wrong here
Deleting a pod does not delete its PersistentVolumeClaim because the PVC is an independent API resource with its own lifecycle. The PVC represents a request for storage that persists until explicitly deleted, even if no pods reference it. The underlying PersistentVolume's reclaim policy (Retain, Recycle, or Delete) only comes into play when the PVC itself is deleted, not when a pod is removed. This independence allows workloads to be rolled or redeployed without losing durable data.
- ✓
A PVC must be created before a pod that references it can be scheduled
Why this is correct
The Kubernetes scheduler cannot place a pod that references a nonexistent PersistentVolumeClaim because the scheduler must verify that the volume is available and can be mounted on a suitable node. Without an existing PVC, the scheduler lacks the binding status and access mode information required for volume placement. The pod will remain in a Pending state with an event indicating the PVC cannot be found, and it will not be assigned to a node until the PVC is created and becomes bound. This holds true for both static provisioning and dynamically provisioned volumes.
- ✓
Multiple pods can use the same PVC if the access mode allows
Why this is correct
Multiple pods can mount the same PersistentVolumeClaim when the access mode of the underlying volume permits it. Access modes like ReadWriteMany (RWX) explicitly allow concurrent access from many nodes, while ReadWriteOnce (RWO) allows multiple pods on the same node to mount the volume simultaneously. However, ReadOnlyMany (ROX) also supports multiple pods, though only for read-only access. Thus, the ability to share a PVC is determined by the capabilities of the storage class and the admission of the access mode at binding time.
Go deeper
Related to this question
Learn chapter
Troubleshooting Cluster and Node Issues
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.