CKA Storage Practice Question
Exhibit
Refer to the exhibit. $ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pv-data 10Gi RWO Retain Bound default/data-claim manual 5h $ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE data-claim Bound pv-data 10Gi RWO manual 5h
A developer accidentally runs 'kubectl delete pvc data-claim'. What is the immediate effect on the PersistentVolume pv-data?
⚠ Common exam trap
Candidates often assume the PV's reclaim policy is 'Delete' by default, or that deleting a PVC automatically makes the PV 'Available' for reuse, when in fact the default policy is 'Retain' and the PV enters 'Released'.
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 PV pv-data enters the Released state and is not deleted.
When a PVC is deleted, the associated PV enters the 'Released' state, not 'Available'. This is because the PV still contains data from the previous claim (the retain policy is 'Retain' by default), and Kubernetes does not automatically delete or reuse it. The PV remains in 'Released' until an administrator manually clears the claimRef or deletes the PV.
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 pv-data is automatically deleted.
Why it's wrong here
The Retain reclaim policy explicitly instructs Kubernetes to preserve the PersistentVolume object when its bound PVC is deleted. Therefore, kubectl delete pvc data-claim does not trigger any deletion of the PV; instead, the PV object continues to exist in the cluster. Automatic PV deletion only occurs when the reclaim policy is set to Delete, not Retain, so this scenario leaves the PV intact. The PV's lifecycle is therefore not terminated by the PVC deletion.
- ✗
The PV pv-data remains Bound to the deleted PVC.
Why it's wrong here
When a PVC is deleted, Kubernetes immediately breaks the binding between the PVC and the PV by altering the PV's status from Bound to Released. A PV can only remain Bound if its bound PVC still exists; after the claim is gone, the PV's claimRef becomes stale and the status changes. Thus the PV cannot remain Bound because the deleted PVC no longer holds the binding reference that caused the Bound state. The release transition is automatic and unavoidable once the PVC is removed.
- ✗
The PV pv-data immediately becomes Available and can be reused.
Why it's wrong here
The Retain policy does not automatically move the PV into the Available state; instead, after the PVC is deleted, the PV transitions to Released, not Available. A PV in Released state is not eligible for immediate reuse by a new claim because its claimRef still points to the deleted PVC, so Kubernetes will not rebind it automatically. To make it Available again, an administrator must manually clear the claimRef or delete and recreate the PV. Therefore, the PV cannot be reused immediately after the PVC deletion.
- ✓
The PV pv-data enters the Released state and is not deleted.
Why this is correct
With the Retain reclaim policy configured, deleting the bound PVC causes the PV to enter the Released state rather than being deleted or recycled. This means the PV still exists and its underlying storage resources—such as disk data—remain intact, but it is no longer bound to any claim. The PV will remain in Released status until an administrator manually intervenes, typically by deleting the PV and recreating it or by editing its claimRef to allow rebinding. This preserves data for recovery but leaves the PV unused until explicit manual action is taken.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
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.
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.
About these practice questions
Courseiva writes every CKA question from scratch — 302 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.