Courseiva
StoragehardMultiple ChoiceObjective-mapped

CKA Storage Practice Question

A cluster has a PersistentVolumeClaim (PVC) named 'data-claim' bound to a PersistentVolume (PV) with reclaim policy 'Retain'. The PVC is deleted. The PV now shows status 'Released'. What must be done so that the PV can be reused by a new PVC?

⚠ Common exam trap

The CKA exam often tests the misconception that a 'Released' PV will automatically become 'Available' over time, but the 'Retain' policy requires explicit administrative action to clear the claim reference.

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

Delete and recreate the PersistentVolume.

When a PVC is deleted and the PV has a reclaim policy of 'Retain', the PV enters a 'Released' state, meaning it still contains the data but is no longer bound to the original PVC. The PV cannot be directly reused by a new PVC because its claim reference is still set to the deleted PVC's UID. To make the PV available again, you must manually delete and recreate the PV (or at least delete it and re-create it with a clean claimRef), which resets its status to 'Available'.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Nothing; the PV will automatically become Available after some time.

    Why it's wrong here

    Under the Retain reclaim policy, Kubernetes preserves the underlying storage volume and its data after the bound PVC is deleted. The PersistentVolume transitions to the Released phase, where it remains indefinitely. It will never automatically transition back to Available without manual intervention by an administrator to clean up the claimRef or recreate the resource.

  • Delete and recreate the PersistentVolume.

    Why this is correct

    Deleting and recreating the PersistentVolume resource is a standard and clean way to make the underlying storage available for new claims. Because the reclaim policy is Retain, deleting the Kubernetes PV object does not destroy the actual data on the external storage provider. Recreating the PV with the same storage details allows a new PVC to bind to it successfully.

  • Create a new PVC with the same name.

    Why it's wrong here

    Simply creating a new PersistentVolumeClaim with the same name and namespace will not trigger a bind to the existing Released PV. The PV's spec.claimRef block still contains the unique UID of the previously deleted PVC. Because of this UID mismatch, the control plane's volume controller will reject any binding attempts from the new PVC.

  • Change the reclaim policy to Delete.

    Why it's wrong here

    Modifying the reclaim policy to Delete on an already Released PersistentVolume does not retroactively trigger volume reclamation or reset its status to Available. The volume controller only evaluates the reclaim policy at the exact moment the PVC is deleted. Once the PV is already in the Released state, changing this policy has no effect on its current binding status.

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 →

How Courseiva writes practice questions · Editorial policy

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.