Why persistent storage matters in Kubernetes - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to create a PersistentVolumeClaim in Kubernetes.

Kubernetes

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - [1]
  resources:
    requests:
      storage: 1Gi

Drag options to blanks, or click blank then click option'

AReadWriteOnce

BReadOnlyMany

CWriteOnce

DReadWriteMany

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing ReadOnlyMany when write access is needed.

Using WriteOnce which is not a valid Kubernetes access mode.

The accessModes field defines how the volume can be mounted. ReadWriteOnce allows the volume to be mounted as read-write by a single node, which is common for many use cases.

2fill in blank

medium

Complete the code to mount the PersistentVolumeClaim in a Pod.

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: [1]
  volumes:
  - name: my-volume
    persistentVolumeClaim:
      claimName: my-pvc

Drag options to blanks, or click blank then click option'

Amy-pvc

Bhtml-volume

Cmy-volume

Dnginx-volume

Attempts:

3 left

💡 Hint

Common Mistakes

Using the PersistentVolumeClaim name instead of the volume name.

Mismatching names causing the volume not to mount.

The volumeMounts name must match the volumes name in the Pod spec. Here, the volume is named my-volume, so the mount uses that name.

3fill in blank

hard

Fix the error in the PersistentVolumeClaim spec to request 5Gi of storage.

Kubernetes

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: [1]

Drag options to blanks, or click blank then click option'

A5Gi

B5GB

C5000Mi

D5G

Attempts:

3 left

💡 Hint

Common Mistakes

Using GB instead of Gi causing validation errors.

Using incorrect units like G or MB.

Kubernetes expects storage sizes to use binary SI units like Gi for gibibytes. 5Gi is the correct format for 5 gibibytes.

4fill in blank

hard

Fill both blanks to create a PersistentVolumeClaim that requests 10Gi storage with ReadWriteMany access.

Kubernetes

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-pvc
spec:
  accessModes:
    - [1]
  resources:
    requests:
      storage: [2]

Drag options to blanks, or click blank then click option'

AReadWriteMany

BReadWriteOnce

C10Gi

D5Gi

Attempts:

3 left

💡 Hint

Common Mistakes

Using ReadWriteOnce instead of ReadWriteMany for shared volumes.

Requesting 5Gi instead of 10Gi storage.

ReadWriteMany allows multiple nodes to mount the volume with read-write access. The storage request must be 10Gi to specify 10 gibibytes.

5fill in blank

hard

Fill all three blanks to define a Pod that mounts a PersistentVolumeClaim named 'data-pvc' at '/data'.

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: data-pod
spec:
  containers:
  - name: app
    image: busybox
    command: ['sleep', '3600']
    volumeMounts:
    - name: [1]
      mountPath: [2]
  volumes:
  - name: [3]
    persistentVolumeClaim:
      claimName: data-pvc

Drag options to blanks, or click blank then click option'

Adata-volume

B/data

D/var/data

Attempts:

3 left

💡 Hint

Common Mistakes

Using different names for volume in mounts and volumes sections.

Setting mountPath to a wrong directory.

The volume name in volumeMounts and volumes must match. The mount path is set to /data as requested.

Practice

1. Why is persistent storage important in Kubernetes?

easy

A. It speeds up container startup time

B. It manages network traffic between pods

C. It automatically scales the number of pods

D. It keeps data safe even if containers stop or restart

Solution

1. Step 1: Understand container lifecycle

   Containers can stop or restart anytime, losing any data stored inside them.

2. Step 2: Role of persistent storage

   Persistent storage keeps data safe beyond container life, so data is not lost.

3. Final Answer:

   It keeps data safe even if containers stop or restart -> Option D

4. Quick Check:

   Persistent storage = data safety beyond containers [OK]

Hint: Persistent storage saves data beyond container life [OK]

Common Mistakes:

• Thinking persistent storage speeds up containers
• Confusing storage with network management
• Assuming storage auto-scales pods

2. Which of the following is the correct way to request persistent storage in Kubernetes?

easy

A. kubectl get storageclass

B. kubectl create pod --storage

C. kubectl apply -f persistentvolumeclaim.yaml

D. kubectl delete pvc

Solution

1. Step 1: Identify how to request storage

   PersistentVolumeClaim (PVC) is used to request storage in Kubernetes.

2. Step 2: Correct command to apply PVC

   Using kubectl apply -f persistentvolumeclaim.yaml applies the PVC configuration.

3. Final Answer:

   kubectl apply -f persistentvolumeclaim.yaml -> Option C

4. Quick Check:

   Request storage with PVC YAML and apply [OK]

Hint: Use kubectl apply with PVC YAML to request storage [OK]

Common Mistakes:

• Using pod creation command to request storage
• Confusing storageclass listing with requesting storage
• Deleting PVC instead of creating it

3. Given this PersistentVolumeClaim YAML snippet:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

What does ReadWriteOnce mean?

medium

A. The volume can be mounted as read-write by only one pod at a time

B. The volume is automatically deleted when pod stops

C. The volume is read-only for all pods

D. The volume can be mounted as read-write by many pods simultaneously

Solution

1. Step 1: Understand accessModes in PVC

   AccessModes define how many pods can mount the volume and with what permissions.

2. Step 2: Meaning of ReadWriteOnce

   ReadWriteOnce means only one pod can mount the volume as read-write at a time.

3. Final Answer:

   The volume can be mounted as read-write by only one pod at a time -> Option A

4. Quick Check:

   ReadWriteOnce = single pod read-write mount [OK]

Hint: ReadWriteOnce means single pod read-write access [OK]

Common Mistakes:

• Thinking ReadWriteOnce allows multiple pods
• Confusing read-only with ReadWriteOnce
• Assuming volume auto-deletes with pod

4. You created a PersistentVolumeClaim but your pod fails to mount the volume with error "volume not found". What is the most likely cause?

medium

A. The PersistentVolumeClaim name does not match the volume name in the pod spec

B. The pod spec is missing the container image

C. The PersistentVolumeClaim requested storage size is too small

D. The pod is missing resource limits

Solution

1. Step 1: Check volume mount configuration

   The pod must reference the PVC by the exact name to mount the volume.

2. Step 2: Identify cause of "volume not found" error

   If names don't match, Kubernetes cannot find the volume to mount.

3. Final Answer:

   The PersistentVolumeClaim name does not match the volume name in the pod spec -> Option A

4. Quick Check:

   Volume mount fails if PVC name mismatches [OK]

Hint: Match PVC name exactly in pod volume spec [OK]

Common Mistakes:

• Ignoring volume name mismatch
• Blaming container image for volume errors
• Assuming storage size causes mount failure

5. You want two pods to share the same persistent storage volume with read-write access at the same time. Which access mode should you specify in your PersistentVolumeClaim?

hard

A. ReadWriteOnce

B. ReadWriteMany

C. ReadOnlyMany

D. WriteOnce

Solution

1. Step 1: Understand access modes for sharing

   ReadWriteMany allows multiple pods to mount the volume as read-write simultaneously.

2. Step 2: Choose correct access mode for sharing

   Since two pods need read-write access at the same time, ReadWriteMany is required.

3. Final Answer:

   ReadWriteMany -> Option B

4. Quick Check:

   Multiple pods read-write = ReadWriteMany [OK]

Hint: Use ReadWriteMany for shared read-write access [OK]

Common Mistakes:

• Using ReadWriteOnce which allows only one pod
• Confusing ReadOnlyMany with read-write access
• Selecting non-existent WriteOnce mode