Courseiva
Storage →mediumMultiple Select

CKA Storage Practice Question

Which TWO of the following are required for dynamic provisioning of PersistentVolumes using a StorageClass?

⚠ Common exam trap

A common misconception is that a default StorageClass is mandatory for dynamic provisioning, but the actual requirement is that the PVC must reference a StorageClass (either explicitly or via the default), and the StorageClass must have a provisioner defined.

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

✓

A PersistentVolumeClaim that references the StorageClass

Option C is correct because dynamic provisioning is triggered by a PersistentVolumeClaim that specifies the StorageClass via its storageClassName field (or relies on the default), which tells Kubernetes to create a matching PersistentVolume on demand. Option E is correct because a StorageClass must define a provisioner (for example, kubernetes.io/aws-ebs or a CSI driver name), since the provisioner is the component that actually creates the backing volume; without it, no dynamic provisioning can occur. Option A is wrong because allowVolumeExpansion only enables resizing of already-provisioned volumes and is not required for provisioning. Option B is wrong because volumeBindingMode: WaitForFirstConsumer only delays binding until a Pod is scheduled; the default Immediate mode also supports dynamic provisioning. Option D is wrong because a default StorageClass is only needed when a PVC omits storageClassName; a PVC that explicitly references a StorageClass provisions dynamically without any default being defined.

Answer analysis

Option-by-option breakdown

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

  • ✗

    A StorageClass with allowVolumeExpansion: true

    Why it's wrong here

    A StorageClass with allowVolumeExpansion: true is not required for dynamic provisioning. This field only enables a PersistentVolumeClaim to request a larger size after its initial creation, and it is relevant only when the storage provider supports online expansion. It has no effect on whether a PV is dynamically created in the first place, because provisioning is driven by the StorageClass's provisioner and the PVC that references it.

  • ✗

    A StorageClass with volumeBindingMode: WaitForFirstConsumer

    Why it's wrong here

    A StorageClass with volumeBindingMode: WaitForFirstConsumer is an optional setting that controls when the PV is created and bound. The default volumeBindingMode is Immediate, which dynamically provisions the PV as soon as the PVC is created. WaitForFirstConsumer delays provisioning until a pod that uses the PVC is scheduled, which can be useful for topology-aware storage, but it does not determine whether dynamic provisioning occurs at all.

  • ✓

    A PersistentVolumeClaim that references the StorageClass

    Why this is correct

    A PersistentVolumeClaim that references the StorageClass is indeed required for dynamic provisioning. The PVC must set its storageClassName field to the name of a StorageClass that has a provisioner; this reference tells the Kubernetes controller which provisioner should create a PV matching the PVC's requested size and access modes. Without this reference, the PVC either remains pending or binds to a pre-existing statically provisioned PV, but it cannot trigger creation of a new PV.

  • ✗

    A default StorageClass must be defined

    Why it's wrong here

    A default StorageClass is not required for dynamic provisioning. A default class is simply a convenience: it applies to PVCs that do not specify a storageClassName, saving users from explicitly naming a class. If no default class is defined, a PVC can still dynamically trigger provisioning by explicitly setting storageClassName to a StorageClass that has a provisioner. Therefore, omitting a default class does not prevent dynamic provisioning.

  • ✓

    A StorageClass with a provisioner defined

    Why this is correct

    A StorageClass with a provisioner defined is required for dynamic provisioning. The provisioner is the component (for example, kubernetes.io/aws-ebs, csi.example.com, or a custom CSI driver) that actually creates the persistent volume on the underlying storage system. Without a valid provisioner in the StorageClass, the Kubernetes controller cannot create a PV in response to a PVC, leaving the PVC in a pending state with a provisioning failure event.

Quick reference

AWS S3 Storage Class Comparison

Storage ClassMin DurationRetrievalUse Case
S3 StandardNoneImmediateFrequently accessed data
S3 Standard-IA30 daysImmediateInfrequent access, rapid retrieval
S3 One Zone-IA30 daysImmediateNon-critical infrequent data
S3 Intelligent-TieringNoneImmediate–hoursUnknown or changing access patterns
S3 Glacier Instant90 daysMillisecondsArchive with instant retrieval
S3 Glacier Flexible90 daysMinutes–hoursArchive, flexible retrieval
S3 Glacier Deep Archive180 daysHoursLong-term compliance archive

About these practice questions

Courseiva writes every CKA question from scratch — 726 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.