PersistentVolume (PV) definition in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of kubectl get pv command

You have created a PersistentVolume (PV) in Kubernetes with the following YAML. What will be the output of kubectl get pv after applying this configuration?

Kubernetes

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/data

A Error from server (NotFound): persistentvolumes "pv-example" not found

B

NAME         CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv-example   5Gi        RWX            Delete           Available           standard      1m

C

NAME         CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv-example   5Gi        RWO            Retain           Available           <unset>      1m

D

NAME         CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv-example   5Gi        RWO            Retain           Bound               standard      1m

💡 Hint

Check the persistentVolumeReclaimPolicy and status fields after creation.

When a PV is created but not yet claimed by any PersistentVolumeClaim, its status is 'Available'. The reclaim policy is 'Retain' as specified. Access mode is ReadWriteOnce (RWO).

🧠 Conceptual

intermediate

Understanding PersistentVolume reclaim policies

Which reclaim policy for a PersistentVolume causes the volume to be deleted automatically when the PersistentVolumeClaim is deleted?

A Archive

B Recycle

C Retain

D Delete

💡 Hint

Think about what happens to the storage after the claim is removed.

The 'Delete' reclaim policy deletes the underlying storage resource when the PersistentVolumeClaim is deleted. 'Retain' keeps the data, and 'Recycle' is deprecated.

❓ Configuration

advanced

Correct PersistentVolume YAML for NFS storage

Which of the following PersistentVolume YAML snippets correctly defines a PV using NFS storage with 10Gi capacity and ReadWriteMany access mode?

A

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 10.0.0.1
  persistentVolumeReclaimPolicy: Retain

B

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /exported/path
    server: 10.0.0.1
  persistentVolumeReclaimPolicy: Retain

C

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadOnlyMany
  hostPath:
    path: /exported/path
  persistentVolumeReclaimPolicy: Retain

D

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  nfs:
    path: /exported/path
    server: 10.0.0.1
  persistentVolumeReclaimPolicy: Delete

💡 Hint

Check the access mode and the storage type fields carefully.

Option B correctly uses 'nfs' with both 'server' and 'path' fields, sets capacity to 10Gi, and access mode to ReadWriteMany. Option B uses ReadWriteOnce which is less common for NFS. Option B uses hostPath instead of nfs. Option B misses the 'path' field under nfs.

❓ Troubleshoot

advanced

Troubleshooting PV binding failure

A PersistentVolumeClaim (PVC) requesting 20Gi with access mode ReadWriteOnce is stuck in Pending state. The cluster has a PV with 10Gi capacity and access mode ReadWriteOnce. What is the most likely reason the PVC is not binding?

A The PV capacity is less than the PVC requested size

B The PV access mode does not match the PVC access mode

C The PV reclaim policy is set to Retain

D The PV is already bound to another PVC

💡 Hint

Check if the PV can satisfy the PVC size requirement.

PVCs can only bind to PVs that have equal or greater capacity than requested. Here, the PV has only 10Gi but PVC requests 20Gi, so binding fails.

✅ Best Practice

expert

Best practice for PersistentVolume naming and labels

Which of the following is the best practice when defining PersistentVolumes in a production Kubernetes cluster to facilitate management and selection by PersistentVolumeClaims?

A Use descriptive names and add labels that indicate storage type and environment

B Use random UUIDs as names and avoid labels to keep PVs simple

C Name PVs after the node they are on and do not use labels

D Use numeric names and label PVs only with reclaim policy

💡 Hint

Think about how labels help in selecting PVs for PVCs.

Using descriptive names and meaningful labels (like storage type, environment) helps administrators and PVCs select appropriate PVs easily. Random or numeric names and lack of labels reduce clarity and management ease.

Practice

1. What is the main purpose of a PersistentVolume (PV) in Kubernetes?

easy

A. To manage container images

B. To define network policies for pods

C. To schedule pods on specific nodes

D. To provide storage that can persist beyond the lifecycle of a pod

Solution

1. Step 1: Understand the role of PersistentVolume

   A PersistentVolume provides storage resources independent of pod lifecycle.

2. Step 2: Compare with other options

   Network policies, pod scheduling, and image management are unrelated to PV.

3. Final Answer:

   To provide storage that can persist beyond the lifecycle of a pod -> Option D

4. Quick Check:

   PV = persistent storage [OK]

Hint: PV stores data beyond pod life, not network or scheduling [OK]

Common Mistakes:

• Confusing PV with pod scheduling
• Thinking PV manages network policies
• Assuming PV handles container images

2. Which of the following is the correct minimal YAML snippet to define a PersistentVolume with 5Gi storage and ReadWriteOnce access mode?

easy

A. apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-example\nspec:\n capacity:\n storage: 5GB\n accessModes:\n - ReadOnlyMany\n hostPath:\n path: /mnt/data

B. apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-example\nspec:\n capacity:\n storage: 5Gi\n accessModes:\n - ReadWriteOnce\n hostPath:\n path: /mnt/data

C. apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-example\nspec:\n size: 5Gi\n accessModes:\n - ReadWriteMany\n hostPath:\n path: /mnt/data

D. apiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n name: pvc-example\nspec:\n storage: 5Gi\n accessModes:\n - ReadWriteOnce

Solution

1. Step 1: Check correct kind and apiVersion

   PersistentVolume uses kind: PersistentVolume and apiVersion: v1.

2. Step 2: Validate capacity and accessModes syntax

   Capacity must be under spec.capacity.storage with unit Gi, and accessModes is a list with ReadWriteOnce.

3. Final Answer:

   YAML with capacity 5Gi, accessModes ReadWriteOnce, kind PersistentVolume -> Option B

4. Quick Check:

   Correct YAML keys and values = apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-example\nspec:\n capacity:\n storage: 5Gi\n accessModes:\n - ReadWriteOnce\n hostPath:\n path: /mnt/data [OK]

Hint: PV uses spec.capacity.storage with units like Gi, not size or GB [OK]

Common Mistakes:

• Using PersistentVolumeClaim instead of PersistentVolume
• Wrong key 'size' instead of 'capacity.storage'
• Incorrect storage unit like GB instead of Gi
• Wrong access mode or misspelled keys

3. Given this PersistentVolume YAML snippet, what is the reclaim policy of the PV?

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-sample
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/data

medium

A. Delete the volume after release

B. Recycle the volume automatically

C. Retain the volume after release

D. No reclaim policy set

Solution

1. Step 1: Locate the reclaim policy field

   The field persistentVolumeReclaimPolicy is set to Retain in the spec.

2. Step 2: Understand reclaim policy meaning

   Retain means the volume is kept after the claim is released, not deleted or recycled.

3. Final Answer:

   Retain the volume after release -> Option C

4. Quick Check:

   persistentVolumeReclaimPolicy = Retain [OK]

Hint: Look for persistentVolumeReclaimPolicy field value [OK]

Common Mistakes:

• Confusing Retain with Delete or Recycle
• Ignoring the reclaim policy field
• Assuming default policy without checking

4. You defined this PersistentVolume YAML but get an error when applying it:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-error
spec:
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  hostPath:
    path: /mnt/data
  storageClassName: fast

What is the likely cause of the error?

medium

A. hostPath volumes cannot have storageClassName set

B. accessModes value ReadWriteOnce is invalid

C. Missing volumeMode field

D. persistentVolumeReclaimPolicy Delete is not allowed

Solution

1. Step 1: Check hostPath volume restrictions

   hostPath volumes do not support storageClassName because they are local paths.

2. Step 2: Validate other fields

   accessModes and reclaim policy values are valid; volumeMode is optional.

3. Final Answer:

   hostPath volumes cannot have storageClassName set -> Option A

4. Quick Check:

   hostPath + storageClassName = error [OK]

Hint: hostPath volumes must not set storageClassName [OK]

Common Mistakes:

• Assuming volumeMode is mandatory
• Thinking accessModes ReadWriteOnce is invalid
• Believing Delete reclaim policy is disallowed

5. You want to create a PersistentVolume that allows multiple pods to read and write simultaneously and automatically deletes the volume when released. Which YAML snippet correctly defines these requirements?

hard

A. apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-multi\nspec:\n capacity:\n storage: 15Gi\n accessModes:\n - ReadWriteMany\n persistentVolumeReclaimPolicy: Delete\n nfs:\n path: /exports/data\n server: 10.0.0.1

B. apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-single\nspec:\n capacity:\n storage: 15Gi\n accessModes:\n - ReadWriteOnce\n persistentVolumeReclaimPolicy: Retain\n hostPath:\n path: /mnt/data

C. apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-multi\nspec:\n capacity:\n storage: 15Gi\n accessModes:\n - ReadOnlyMany\n persistentVolumeReclaimPolicy: Delete\n nfs:\n path: /exports/data\n server: 10.0.0.1

D. apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-multi\nspec:\n capacity:\n storage: 15Gi\n accessModes:\n - ReadWriteMany\n persistentVolumeReclaimPolicy: Retain\n nfs:\n path: /exports/data\n server: 10.0.0.1

Solution

1. Step 1: Identify access mode for multiple pods read/write

   ReadWriteMany allows multiple pods to read and write simultaneously.

2. Step 2: Check reclaim policy for automatic deletion

   persistentVolumeReclaimPolicy: Delete deletes the volume after release.

3. Step 3: Confirm storage type supports ReadWriteMany

   NFS supports ReadWriteMany; hostPath does not.

4. Final Answer:

   YAML with ReadWriteMany, Delete reclaim policy, and NFS volume -> Option A

5. Quick Check:

   ReadWriteMany + Delete + NFS = apiVersion: v1\nkind: PersistentVolume\nmetadata:\n name: pv-multi\nspec:\n capacity:\n storage: 15Gi\n accessModes:\n - ReadWriteMany\n persistentVolumeReclaimPolicy: Delete\n nfs:\n path: /exports/data\n server: 10.0.0.1 [OK]

Hint: Use ReadWriteMany + Delete + NFS for multi-pod writable PV [OK]

Common Mistakes:

• Using hostPath for multi-pod access
• Choosing ReadWriteOnce instead of ReadWriteMany
• Setting reclaim policy to Retain instead of Delete