Overview
Domain 4 covers how Pods get storage that outlives a container. You need to create PersistentVolumes (PVs) by hand for static provisioning, write PersistentVolumeClaims (PVCs) that bind to them, and use StorageClasses so claims are provisioned dynamically by a CSI driver or other provisioner. You must know the access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany, ReadWriteOncePod), the reclaim policies (Retain and Delete), volumeBindingMode, volume expansion, and the ephemeral volume types such as emptyDir, hostPath, configMap and secret.
The tasks are compact: create a PV and claim that bind, mount the claim in a Pod at a given path, resize a claim, or work out why one is Pending. The domain connects to Workloads and Scheduling through Pod and StatefulSet volume definitions, and to Troubleshooting, where an unbound claim is a common reason for a Pending Pod.
How it's tested
Storage tasks are short build-and-bind jobs: create a PV with given capacity, access mode, path and class; create a matching claim; mount it in a Pod; or expand or diagnose a claim. Grading checks PV and PVC status (Bound) and the Pod's mount, so every matching field must line up exactly.
-
Static bind
Create a PV and a PVC from stated values and get them to Bound, which requires matching access mode, storage class and sufficient capacity.
-
Dynamic claim
Create a StorageClass or use an existing one, then write a claim that a provisioner fulfils, noting volumeBindingMode and the default class.
-
Why is it Pending
Read kubectl describe pvc events to decide whether the cause is a mismatch, a missing provisioner, or simply a claim waiting for its first Pod.
A PVC requests 2Gi ReadWriteOnce with storageClassName manual. The only PV offers 1Gi ReadWriteOnce, class manual. The claim stays Pending because a PV must provide at least the requested capacity. The fix is a PV of 2Gi or more, or a smaller request if the task allows; changing the access mode or class would not help, since those already match.
Competencies 3
Official competencies from the Linux Foundation outline, in outline order.
4.1 Implement storage classes and dynamic volume provisioningStorageClasses that create volumes on demand.
- What it means
- A StorageClass names a provisioner (usually a CSI driver), its parameters, a reclaimPolicy, a volumeBindingMode and whether volumes can be expanded; a PVC that names the class causes a matching PV to be created automatically.
- What to understand
- The class marked with the annotation storageclass.kubernetes.io/is-default-class: "true" is used for claims that omit storageClassName, while storageClassName: "" turns dynamic provisioning off for that claim. WaitForFirstConsumer delays provisioning until a Pod uses the claim, so the volume is created where the Pod is scheduled.
- How it shows up
- You create a StorageClass with given provisioner, reclaim policy and binding mode, then a claim that uses it, or you change which class is the default.
- Common confusion
- Expecting a claim with no storageClassName to bind to a classless static PV when a default StorageClass exists; the default class is applied and dynamic provisioning is attempted instead.
4.2 Configure volume types, access modes and reclaim policiesChoosing the volume source, how it can be mounted, and what happens after release.
- What it means
- Volume types range from ephemeral (emptyDir, configMap, secret, projected) to node-bound (hostPath, local) to persistent through a PVC; access modes say how many nodes or Pods may mount a volume, and reclaim policies say what happens to a PV once its claim is deleted.
- What to understand
- ReadWriteOnce limits read-write mounting to one node, so several Pods on that node may share it; ReadWriteOncePod limits it to a single Pod. Retain keeps the PV and its data in Released state; Delete removes the PV and the backing storage. Dynamically provisioned volumes inherit the class's reclaimPolicy, which defaults to Delete.
- How it shows up
- A task asks for a volume that keeps data after the claim is deleted, or for scratch space shared by two containers in one Pod.
- Common confusion
- Believing ReadWriteOnce means one Pod; that is ReadWriteOncePod.
4.3 Manage persistent volumes and persistent volume claimsBinding, mounting, expanding and reclaiming PVs and PVCs.
- What it means
- A PVC binds one-to-one to a PV whose access modes, storageClassName, volumeMode and optional label selector match and whose capacity is at least the request; a Pod then mounts the PVC by name under volumes and volumeMounts.
- What to understand
- PV phases are Available, Bound, Released and Failed. A Released PV under Retain will not rebind until you remove its spec.claimRef or recreate it. A claim can be enlarged, never shrunk, by raising spec.resources.requests.storage when the class has allowVolumeExpansion: true. A PVC in use by a Pod stays Terminating when deleted, because of the pvc-protection finalizer.
- How it shows up
- You mount a claim in a Pod at a given path, expand a claim, or reuse a Retained volume for a new claim.
- Common confusion
- Deleting and recreating a claim to change its size, which can destroy data under a Delete reclaim policy.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
PV to PVC binding rules
A claim binds to a volume only when access modes, storage class and volume mode match and the volume's capacity is at least the request.
- Remember
- Binding is one-to-one, so a 10Gi PV bound to a 1Gi claim is fully consumed.
- Tested as
- Most static storage tasks are graded on reaching Bound.
- Trap
- Assuming a larger PV can be shared by several small claims.
-
Default StorageClass
The default class is the one carrying the is-default-class annotation set to true.
- Remember
- Claims without storageClassName get it; storageClassName "" opts out of dynamic provisioning.
- Tested as
- Tasks ask you to set or change the default class, or to bind a claim to a classless static PV.
- Trap
- Leaving storageClassName out when a static PV has no class and a default class exists.
-
volumeBindingMode
This StorageClass field decides when binding and provisioning happen.
- Remember
- Immediate binds as soon as the claim exists; WaitForFirstConsumer waits for a Pod so the volume suits the Pod's node.
- Tested as
- A claim Pending with a 'waiting for first consumer' event is normal under WaitForFirstConsumer.
- Trap
- Treating that Pending state as an error and changing the class.
-
Access modes
Access modes state how a volume can be mounted across nodes and Pods.
- Remember
- RWO is one node read-write, ROX many nodes read-only, RWX many nodes read-write, RWOP one Pod read-write.
- Tested as
- Matching modes between claim and volume is required for binding.
- Trap
- Requesting RWX from a backend that supports only RWO.
-
Retain vs. Delete
The reclaim policy decides what happens to a PV after its claim is deleted.
- Remember
- Retain leaves the PV Released with data intact; Delete removes the PV and its storage.
- Tested as
- Tasks ask you to preserve data, which means Retain.
- Trap
- Expecting Recycle; it is deprecated.
-
Released PV reuse
A Released PV still records its old claim in spec.claimRef and cannot bind to a new one.
- Remember
- Remove the claimRef with kubectl patch or edit, or recreate the PV, to make it Available again.
- Tested as
- Reuse tasks follow a deleted claim under Retain.
- Trap
- Recreating the claim and waiting for it to bind to the Released PV.
-
Volume expansion
A claim can grow if its StorageClass has allowVolumeExpansion: true.
- Remember
- Edit the claim's spec.resources.requests.storage upwards; shrinking is not allowed.
- Tested as
- Resize tasks give a new size for an existing claim.
- Trap
- Editing the PV capacity instead of the claim.
-
emptyDir
An emptyDir volume is created empty when a Pod starts and deleted when the Pod is removed.
- Remember
- It survives container restarts within the Pod, and medium: Memory backs it with RAM.
- Tested as
- Used for scratch space or sharing files between containers in one Pod.
- Trap
- Expecting the data to persist after the Pod is deleted.
-
hostPath and local volumes
hostPath mounts a path from the node into a Pod; a local PV formalises a node's disk with nodeAffinity.
- Remember
- Both tie data to one node, and local PVs are usually paired with WaitForFirstConsumer.
- Tested as
- Lab tasks often use hostPath PVs because they need no storage backend.
- Trap
- Expecting the data to follow the Pod to another node.
-
Storage object protection
Finalizers stop a claim in use, or a PV bound to a claim, from being removed immediately.
- Remember
- A deleted claim stays Terminating until no Pod uses it.
- Tested as
- Explains apparently stuck deletions in scenarios.
- Trap
- Force-removing finalizers instead of deleting the Pod first.
-
Mounting a claim in a Pod
A Pod references a claim under spec.volumes with persistentVolumeClaim.claimName and mounts it with volumeMounts.
- Remember
- The volume name links the two sections; mountPath sets the directory in the container.
- Tested as
- Almost every storage task ends with a Pod mounting the claim.
- Trap
- Mismatching the volume name between volumes and volumeMounts.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Static vs. dynamic provisioning
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Static provisioning | An administrator creates PVs in advance; claims bind to them | You control capacity, path and class exactly | Leaving storageClassName out of the claim while a default class exists |
| Dynamic provisioning | A StorageClass provisioner creates a PV when a claim needs one | No PV exists until the claim, or under WaitForFirstConsumer its Pod, appears | Looking for a PV before any Pod uses the claim |
ReadWriteOnce vs. ReadOnlyMany vs. ReadWriteMany vs. ReadWriteOncePod
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| ReadWriteOnce (RWO) | Read-write by a single node | Several Pods on that one node can share it | Thinking it limits use to one Pod |
| ReadOnlyMany (ROX) | Read-only by many nodes | No writes from any node | Choosing it for a shared write workload |
| ReadWriteMany (RWX) | Read-write by many nodes | Needs a backend that supports it, such as NFS | Requesting it from block storage that supports only RWO |
| ReadWriteOncePod (RWOP) | Read-write by a single Pod | Stricter than RWO; supported by CSI volumes | Confusing it with RWO |
Retain vs. Delete reclaim policy
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Retain | PV and data are kept when the claim is deleted | PV moves to Released and needs manual cleanup to reuse | Expecting the PV to rebind automatically |
| Delete | PV and backing storage are removed with the claim | Default for dynamically provisioned volumes | Deleting a claim to resize it and losing the data |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Default class hijack
- What candidates pick
- Writing a claim without storageClassName to bind to a classless static PV.
- Why it looks right
- No class was asked for, so leaving the field out seems faithful.
- Why it's wrong
- The default StorageClass is filled in, so the claim looks for a dynamic volume and ignores the static PV.
Clue to watch for kubectl get storageclass showing a class marked (default).
-
Capacity mismatch
- What candidates pick
- Leaving the claim at the requested size against a smaller PV.
- Why it looks right
- Access mode and class match, so it looks complete.
- Why it's wrong
- A PV must be at least as large as the claim's request.
Clue to watch for Different sizes in the PV and PVC specifications in the task.
-
Normal Pending read as failure
- What candidates pick
- Deleting the claim or changing its class when it stays Pending.
- Why it looks right
- Pending looks like an error.
- Why it's wrong
- Under WaitForFirstConsumer the claim binds only when a Pod using it is scheduled.
Clue to watch for An event reading 'waiting for first consumer to be created before binding'.
-
RWO read as single Pod
- What candidates pick
- Choosing ReadWriteOncePod when two Pods on one node must share a volume, or RWO when exactly one Pod is allowed.
- Why it looks right
- The names are nearly identical.
- Why it's wrong
- RWO is per node and RWOP is per Pod, so the wrong one either blocks the second Pod or fails the requirement.
Clue to watch for Whether the task limits access by node or by Pod.
-
Resizing the PV
- What candidates pick
- Editing the PV's capacity to grow storage.
- Why it looks right
- The PV is where capacity is defined.
- Why it's wrong
- Expansion is requested on the claim and needs allowVolumeExpansion on the class.
Clue to watch for A task asking to resize the claim used by a workload.
-
Rebinding a Released PV
- What candidates pick
- Recreating a deleted claim and waiting for it to bind to the Retained volume.
- Why it looks right
- The PV and its data are still there.
- Why it's wrong
- The PV keeps the old claimRef and stays Released, so the new claim cannot bind.
Clue to watch for kubectl get pv showing STATUS Released with the old claim name.
Answer framework
Work through storage tasks by matching fields from the volume side to the Pod side.
- List StorageClasses with kubectl get storageclass and note which is the default, its provisioner, its binding mode and whether it allows expansion.
- Decide whether the task wants static or dynamic provisioning, and set storageClassName explicitly, using an empty string to opt out.
- Match the claim to the volume field by field: access mode, class, volume mode and capacity at least the request.
- Mount the claim in the Pod with matching names under volumes and volumeMounts at the exact mountPath requested.
- Verify with kubectl get pv,pvc for Bound status, then use kubectl exec to write and read a test file at the mount path so you know the volume is really writable.
Practice question
Want more like this? The CKA practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Begin with static provisioning on a lab cluster: create a hostPath PV, a matching claim, and a Pod that mounts it, then change one field at a time to see which mismatches leave the claim Pending. This teaches the binding rules faster than any table.
Next, install or use a dynamic provisioner, such as the local-path provisioner many lab clusters ship with, and create StorageClasses with each binding mode. Watch when the PV appears under Immediate versus WaitForFirstConsumer, and practise switching the default class.
Candidates commonly underestimate reclaim behaviour and expansion. Delete a claim under Retain, observe the Released PV, and make it reusable; then enlarge a claim on a class that allows expansion. These steps are quick once you have done them, and confusing when seen for the first time under exam pressure.
Keep the high-priority facts in front of you: binding fields, access mode meanings, and the default class rule. Afterwards, practise Pending-claim diagnosis as Troubleshooting drills, reading kubectl describe pvc events and fixing the cause within a few minutes.
FAQ
How much is Storage worth on the CKA?
The Linux Foundation weights Storage at 10%, the smallest domain. Expect around two tasks, which are short if you know the binding rules.
Do I need to know specific cloud storage drivers?
No. Tasks use generic StorageClasses, hostPath or local volumes, or a provisioner already installed. Focus on how classes, claims and volumes interact.
Why is my PVC stuck in Pending?
Either no PV matches its access mode, class and capacity, no provisioner serves its class, or the class uses WaitForFirstConsumer and no Pod uses the claim yet. kubectl describe pvc shows which.
What is the difference between ReadWriteOnce and ReadWriteOncePod?
ReadWriteOnce allows read-write mounting by one node, which can host several Pods using the volume. ReadWriteOncePod restricts it to one Pod in the whole cluster.
Can I shrink a PersistentVolumeClaim?
No. Claims can only be expanded, and only when their StorageClass sets allowVolumeExpansion to true.
What happens to data when I delete a PVC?
It depends on the PV's reclaim policy. Retain keeps the PV and data in Released state, while Delete removes both.
How does Storage connect to the other domains?
Pods and StatefulSets from Workloads and Scheduling consume claims, and unbound claims are a common reason for Pending Pods in Troubleshooting.
Test your Domain 4 knowledge
Practise building and binding PVs and claims, choosing access modes and reclaim policies, and diagnosing Pending claims from their events.