Storage classes for dynamic provisioning in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the main purpose of a StorageClass in Kubernetes?

Choose the best description of what a StorageClass does in Kubernetes dynamic provisioning.

A Schedules pods to nodes based on resource availability.

B Defines how to dynamically create persistent storage volumes with specific parameters.

C Manages user access control for Kubernetes clusters.

D Specifies the network policies for pod communication.

💡 Hint

Think about what StorageClass controls related to storage.

A StorageClass tells Kubernetes how to create storage volumes dynamically with certain settings like type and performance.

💻 Command Output

intermediate

Output of kubectl get storageclass command

What output will you see after running kubectl get storageclass if there is one default StorageClass named fast-storage?

Kubernetes

kubectl get storageclass

A

NAME           PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
slow-storage   kubernetes.io/gce-pd       Delete         Immediate             true                  5d

B

NAME           PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
fast-storage   kubernetes.io/aws-ebs      Retain         Immediate             false                 10d

C

NAME           PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
fast-storage   kubernetes.io/aws-ebs      Delete         WaitForFirstConsumer   true                  10d
(default)

D No resources found in default namespace.

💡 Hint

Look for the default StorageClass and its typical fields.

The output lists StorageClasses with their provisioner, reclaim policy, binding mode, expansion allowance, age, and default marker.

❓ Configuration

advanced

Identify the error in this StorageClass YAML

Which option correctly identifies the error in this StorageClass YAML snippet?

Kubernetes

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: yes

A The provisioner 'kubernetes.io/aws-ebs' is invalid and should be 'aws-ebs-provisioner'.

B The volumeBindingMode 'WaitForFirstConsumer' is deprecated and should be 'Immediate'.

C The reclaimPolicy field should be under parameters, not at root level.

D The value 'yes' for allowVolumeExpansion should be a boolean true, not a string.

💡 Hint

Check the data types for boolean fields in YAML.

In YAML, boolean fields like allowVolumeExpansion must be true or false without quotes. 'yes' as a string is invalid.

❓ Troubleshoot

advanced

Why does PVC remain Pending with dynamic provisioning?

A PersistentVolumeClaim (PVC) stays in Pending state even though a StorageClass is specified. What is the most likely cause?

A The StorageClass provisioner is not installed or available in the cluster.

B The PVC size is larger than the node's CPU capacity.

C The PVC does not specify a storageClassName field.

D The pod using the PVC is not scheduled yet.

💡 Hint

Think about what happens when Kubernetes tries to create a volume dynamically.

If the provisioner for the StorageClass is missing, Kubernetes cannot create the volume, so the PVC stays Pending.

🔀 Workflow

expert

Correct order to create and use dynamic storage in Kubernetes

Put these steps in the correct order to dynamically provision storage and use it in a pod.

A 1,2,4,3

B 2,1,4,3

C 1,4,2,3

D 2,4,1,3

💡 Hint

Think about what must exist before requesting storage and before using it in a pod.

First create StorageClass, then PVC referencing it, then Kubernetes provisions PV, then pod uses PVC.

Practice

1. What is the main purpose of a StorageClass in Kubernetes?

easy

A. To define how storage volumes are dynamically provisioned

B. To schedule pods on specific nodes

C. To manage network policies

D. To configure container resource limits

Solution

1. Step 1: Understand StorageClass role

   A StorageClass defines parameters for dynamic volume provisioning in Kubernetes.

2. Step 2: Compare with other options

   Scheduling pods, managing network policies, and resource limits are unrelated to StorageClass.

3. Final Answer:

   To define how storage volumes are dynamically provisioned -> Option A

4. Quick Check:

   StorageClass = dynamic provisioning [OK]

Hint: StorageClass controls storage creation, not pods or network [OK]

Common Mistakes:

• Confusing StorageClass with pod scheduling
• Thinking StorageClass manages network policies
• Assuming StorageClass sets container CPU/memory limits

2. Which of the following is the correct YAML snippet to specify a StorageClass named fast-storage for a PersistentVolumeClaim?

easy

A. StorageClass: fast-storage

B. storageclass: fast-storage

C. storageClassName: fast-storage

D. storage_class_name: fast-storage

Solution

1. Step 1: Recall correct field name

   The correct field in PVC spec is storageClassName with camelCase.

2. Step 2: Check other options

   Options B, C, and D use incorrect casing or underscores, which are invalid in Kubernetes YAML.

3. Final Answer:

   storageClassName: fast-storage -> Option C

4. Quick Check:

   Correct YAML key = storageClassName [OK]

Hint: Use exact camelCase 'storageClassName' in PVC spec [OK]

Common Mistakes:

• Using wrong casing like 'storageclass' or 'StorageClass'
• Replacing camelCase with underscores
• Misspelling the field name

3. Given this StorageClass YAML snippet:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain

What will happen when a PersistentVolumeClaim requests storage from this class?

medium

A. The volume will not be dynamically provisioned; manual provisioning is required

B. The volume will be deleted automatically when released

C. The volume will be dynamically provisioned immediately

D. The volume will be provisioned but bound immediately without waiting

Solution

1. Step 1: Analyze provisioner field

   The provisioner is kubernetes.io/no-provisioner, meaning no dynamic provisioning.

2. Step 2: Understand reclaimPolicy and binding mode

   ReclaimPolicy is Retain (volume kept after release), and volumeBindingMode waits for pod scheduling.

3. Final Answer:

   The volume will not be dynamically provisioned; manual provisioning is required -> Option A

4. Quick Check:

   No provisioner = manual provisioning [OK]

Hint: No provisioner means no dynamic provisioning [OK]

Common Mistakes:

• Assuming dynamic provisioning happens with no-provisioner
• Confusing reclaimPolicy with provisioning behavior
• Ignoring volumeBindingMode effect

4. You created a StorageClass with volumeBindingMode: Immediate but your pods fail to schedule because volumes are not available in the node's zone. What is the likely cause and fix?

medium

A. Cause: StorageClass name mismatch; Fix: Correct PVC storageClassName

B. Cause: Reclaim policy is Retain; Fix: Change to Delete

C. Cause: Provisioner is missing; Fix: Add a provisioner

D. Cause: Immediate binding ignores pod location; Fix: Change to WaitForFirstConsumer

Solution

1. Step 1: Understand volumeBindingMode impact

   Immediate binding provisions and binds volume before pod scheduling, ignoring node zone.

2. Step 2: Identify fix

   Changing to WaitForFirstConsumer delays binding until pod scheduling, ensuring volume is in correct zone.

3. Final Answer:

   Cause: Immediate binding ignores pod location; Fix: Change to WaitForFirstConsumer -> Option D

4. Quick Check:

   Immediate binding ignores pod zone [OK]

Hint: Use WaitForFirstConsumer to bind volume after pod scheduling [OK]

Common Mistakes:

• Changing reclaimPolicy instead of binding mode
• Adding provisioner when already present
• Fixing storageClassName without checking binding mode

5. You want to create a StorageClass that dynamically provisions SSD-backed volumes with fast performance, deletes volumes when released, and delays binding until pod scheduling. Which YAML snippet correctly implements this?

hard

A. apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
type: standard
reclaimPolicy: Retain
volumeBindingMode: Immediate

B. apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

C. apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-ssd
provisioner: kubernetes.io/no-provisioner
parameters:
type: io1
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

D. apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
type: io1
reclaimPolicy: Delete
volumeBindingMode: Immediate

Solution

1. Step 1: Identify correct provisioner and parameters

   For AWS SSD, provisioner is kubernetes.io/aws-ebs and type gp2 is general SSD.

2. Step 2: Check reclaimPolicy and binding mode

   ReclaimPolicy should be Delete to remove volumes after release; binding mode WaitForFirstConsumer delays binding until pod scheduling.

3. Step 3: Validate options

   apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ssd provisioner: kubernetes.io/aws-ebs parameters: type: standard reclaimPolicy: Retain volumeBindingMode: Immediate uses wrong type and policies; apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ssd provisioner: kubernetes.io/no-provisioner parameters: type: io1 reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer uses no provisioner; apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ssd provisioner: kubernetes.io/aws-ebs parameters: type: io1 reclaimPolicy: Delete volumeBindingMode: Immediate uses Immediate binding which is not desired; apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ssd provisioner: kubernetes.io/aws-ebs parameters: type: gp2 reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer matches all requirements.

4. Final Answer:

   YAML with provisioner kubernetes.io/aws-ebs, type gp2, reclaimPolicy Delete, and WaitForFirstConsumer -> Option B

5. Quick Check:

   Correct provisioner + Delete + WaitForFirstConsumer = apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ssd provisioner: kubernetes.io/aws-ebs parameters: type: gp2 reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer [OK]

Hint: Match provisioner, parameters, reclaimPolicy, and bindingMode exactly [OK]

Common Mistakes:

• Using no-provisioner disables dynamic provisioning
• Choosing wrong volume type parameter
• Setting reclaimPolicy to Retain instead of Delete
• Using Immediate binding when delayed binding is needed