Study Hub / Certified Kubernetes Administrator (CKA) / Domain 4.0
Certified Kubernetes Administrator (CKA) Domain 4.0: Storage — Explained
Domain 4.0 is the smallest CKA domain and the most conceptual: how Kubernetes gives mortal pods immortal storage. Learn the PV → PVC → StorageClass chain once and every storage question answers itself.
Why pods need help with storage
- Containers are ephemeral — when a container dies, its writable layer dies with it. Restart the pod and your data is gone. Any data that must survive needs a volume.
- Volume types — emptyDir (survives container restarts, dies with the pod — scratch space), hostPath (a node directory — ties the pod to that node, avoid in production), configMap/secret (inject configuration as files), and persistent volumes (real storage, outlives pods).
- The pod spec references volumes — the pod declares "I need this volume mounted at this path." Storage details stay out of the pod where possible.
PVs, PVCs, and StorageClasses: the chain
- PersistentVolume (PV) — a chunk of real storage provisioned by an admin (or dynamically), with capacity and access modes. Cluster-scoped: it exists independently of any pod.
- PersistentVolumeClaim (PVC) — a pod's request for storage: "I need 10Gi, ReadWriteOnce." Namespace-scoped. Kubernetes binds a matching PV to the claim.
- StorageClass — the template for dynamic provisioning: instead of pre-creating PVs, the StorageClass tells Kubernetes how to create one on demand when a PVC appears (which provisioner, which disk type).
- The flow — pod needs storage → PVC requests it → StorageClass provisions (or an existing PV binds) → pod mounts the claim. Developers write PVCs; the platform handles PVs.
- Reclaim policies — what happens to the PV when the PVC is deleted: Retain (keep the data, manual cleanup), Delete (destroy the volume), Recycle (legacy scrub-and-reuse).
Access modes: who can mount how
- ReadWriteOnce (RWO) — mounted read-write by one node. The common case for databases.
- ReadOnlyMany (ROX) — mounted read-only by many nodes. Shared config, static assets.
- ReadWriteMany (RWX) — mounted read-write by many nodes. Needs a filesystem that supports it (NFS, CephFS) — not every storage backend can.
- Matching matters — a PVC requesting RWX only binds to a PV offering RWX. Mode mismatch = claim sits Pending forever.
The must-memorize table: the storage chain
Who creates what, and who uses it.
| Object | Created by | Role |
|---|---|---|
| PersistentVolume (PV) | Admin or dynamic provisioner | The actual storage, cluster-scoped |
| PersistentVolumeClaim (PVC) | Developer (in pod spec) | The request: size + access mode |
| StorageClass | Admin | Template for dynamic PV provisioning |
| Volume mount | Pod spec | Where the claimed storage appears in the container |
Try it: 4 sample questions
Sample questions to check your understanding of this domain. Answers and full reasoning are tucked under each one.
1. A developer's pod needs 10Gi of storage that survives pod restarts and is created automatically when requested. Which objects are involved?
- A. A. A hostPath volume — simplest
- B. B. A PVC requesting 10Gi, fulfilled by dynamic provisioning via a StorageClass
- C. C. An emptyDir volume
- D. D. A ConfigMap
Show answer & reasoning
B. The developer writes a PVC (the request); a StorageClass dynamically provisions the PV — no admin pre-creation, survives pod death. hostPath (A) ties the pod to one node; emptyDir (C) dies with the pod; ConfigMaps (D) hold config, not 10Gi of data.
2. A database pod was deleted and recreated, but its data is gone. The pod used an emptyDir volume. What went wrong?
- A. A. emptyDir survives pod deletion — this is a scheduler bug
- B. B. emptyDir only survives container restarts; pod deletion wipes it — persistent data needs a PV/PVC
- C. C. The database should have used a ConfigMap
- D. D. Nothing — databases shouldn't store data
Show answer & reasoning
B. emptyDir's lifetime is the pod, not the container: it survives container crashes (useful scratch space) but dies with the pod. Durable data needs a PersistentVolumeClaim. This is the #1 storage misconception — always verify the volume type.
3. A shared media library must be mounted read-write by pods on many nodes simultaneously. Which access mode is required?
- A. A. ReadWriteOnce (RWO)
- B. B. ReadOnlyMany (ROX)
- C. C. ReadWriteMany (RWX)
- D. D. Access modes don't matter for shared data
Show answer & reasoning
C. Many nodes × read-write = ReadWriteMany. RWO (A) allows one node; ROX (B) is read-only. And the backend must actually support RWX (NFS/CephFS do; plain block storage doesn't) — a PVC asking for RWX on an RWO-only provisioner pends forever.
4. A PVC is deleted and the admin wants the underlying data preserved for manual review. Which reclaim policy should the PV use?
- A. A. Delete — removes the volume immediately
- B. B. Retain — keeps the PV and its data for manual handling
- C. C. Recycle — scrubs and reuses automatically
- D. D. Reclaim policies only apply to ConfigMaps
Show answer & reasoning
B. Retain keeps the PV and its data after the claim is gone — the admin then inspects, backs up, or manually cleans up. Delete (A) would destroy the very data to be reviewed. Retain is the safe default when data matters more than automation.
This was one domain. The simulator drills all 5.
This free preview covered Storage (Domain 4.0, 10%). Not covered here: Cluster Architecture, Installation & Configuration (Domain 1.0, 25%); Troubleshooting (Domain 5.0, 30%). The two highest-weight domains — cluster builds and live troubleshooting, the most hands-on CKA material — stay in the paid guide and practice bank. The ByteBar Practice Exam Simulator drills every domain with 1,000 exam-style questions — $9.99 one-time unlocks all 28 exams. Prefer to read? The full CKA Study Guide is in the ByteBar shop on Etsy.
Practice Exam Simulator — $9.99 one-time, all 28 exams Full Study Guides on Etsy