Storage — CKA practice questions

A StatefulSet with volumeClaimTemplates is scaled from 3 replicas down to 1. What happens to the claims created for the removed pods, by default?

1. They are deleted along with their pods so that storage is reclaimed automatically
2. They are retained, and scaling back up reattaches the same volumes to the same ordinals
3. They are marked Released and their reclaim policy is switched to Retain by the controller
4. They are merged into the surviving replica's claim to consolidate the freed capacity

Answer: B — They are retained, and scaling back up reattaches the same volumes to the same ordinals

B) Correct — the StatefulSet controller deliberately leaves per-ordinal claims in place, so data is preserved and a later scale-up rebinds each pod to its original volume. A) describes what the optional persistentVolumeClaimRetentionPolicy can be configured to do, but it is not the default. C) confuses PVC lifecycle with the PV phase and misstates who sets reclaim policy. D) invents capacity consolidation that no controller performs.

How do a PersistentVolume and a PersistentVolumeClaim differ?

1. They are simply two names for a single object, one used by admins and one by end users
2. The PersistentVolume is the request a pod makes for storage of a given size and mode
3. The PersistentVolumeClaim is the actual disk, provisioned before any pod requests it
4. The PersistentVolume is the storage resource; the claim is a namespaced request for it
5. Both are pods: one runs the storage driver and the other mounts the resulting device

Answer: D — The PersistentVolume is the storage resource; the claim is a namespaced request for it

D is the answer: the PV is cluster-scoped supply, created by an administrator or by a StorageClass provisioner, and the PVC is namespaced demand that binds to a PV matching its size, access modes and class. The pod then mounts the claim. B and C simply invert the two roles, which is the usual mistake. A ignores that they bind to each other, and E confuses the API objects with the CSI driver pods that implement them.

Which statement about generic ephemeral volumes is MOST accurate?

1. They are provisioned through a storage class and deleted with the pod that declared them
2. They are identical to emptyDir but are always backed by the node's memory rather than disk
3. They survive pod deletion so that a replacement pod can reattach to the same data
4. They require a pre-created PersistentVolumeClaim referenced from the pod specification

Answer: A — They are provisioned through a storage class and deleted with the pod that declared them

A) Correct — a generic ephemeral volume gets a claim template inline in the pod, so it benefits from dynamic provisioning and CSI features while sharing the pod's lifecycle. B) confuses it with emptyDir's memory medium option and ignores the provisioning path. C) reverses the defining property, which is that the volume is removed with the pod. D) describes the ordinary persistentVolumeClaim volume source, the alternative this feature exists to avoid.

A PVC is Pending. PV exists with matching size and StorageClass. Most common reason?

1. The PV's reclaimPolicy conflicts with the PVC's requested policy
2. etcd is out of space, so the binding controller cannot write
3. accessModes differ, such as a RWO volume against a RWX claim
4. No pod references the claim yet, so binding has not been tried

Answer: C — accessModes differ, such as a RWO volume against a RWX claim

C is right: binding requires storageClassName, capacity and accessModes all to be compatible, and a ReadWriteOnce volume against a ReadWriteMany claim is the classic mismatch. A invents a policy negotiation that does not exist. B would break far more than one claim. D is wrong because binding happens independently of any pod.

Mounting a ConfigMap as a volume vs as env vars: when the ConfigMap is updated, behavior?

1. Both projected files and injected env vars refresh in place
2. Neither refreshes; the pod must be restarted to see changes
3. Mounted files refresh after the kubelet sync; env vars do not
4. Env vars refresh in place; mounted files stay at their old value

Answer: C — Mounted files refresh after the kubelet sync; env vars do not

C is right: the kubelet re-projects volume contents after its sync period, while env values are resolved once at container start. A and B each generalise one half of the behaviour to both. D reverses the two, which is the trap the item is built around; note subPath mounts also do not refresh.

Which Kubernetes feature provides storage that survives pod restarts and rescheduling?

1. emptyDir, a scratch volume created with the pod and deleted when the pod is removed
2. PersistentVolume plus PersistentVolumeClaim, provisioned dynamically by a StorageClass
3. hostPath, which mounts a path on one node and does not follow a rescheduled pod
4. The container's writable layer, which is discarded whenever the container restarts
5. An emptyDir with medium Memory, which keeps files in RAM and clears with the pod

Answer: B — PersistentVolume plus PersistentVolumeClaim, provisioned dynamically by a StorageClass

B is the answer: the PV is the storage resource, the PVC is the namespaced request, and a StorageClass can provision the PV on demand through a CSI driver. Reclaim policy Retain or Delete governs what happens when the claim goes away. A and E are pod-scoped scratch space. C tempts because the data outlives the pod on that one node, but it does not follow the pod elsewhere. D is lost on every restart.

Which access mode means a volume can be mounted read-write by exactly one POD (not just one node)?

1. ReadWriteOnce (RWO)
2. ReadWriteMany (RWX)
3. ReadWriteOncePod (RWOP)
4. ReadOnlyMany (ROX)

Answer: C — ReadWriteOncePod (RWOP)

RWO = one node. RWOP = one pod (stronger, prevents two pods on the same node from mounting). ROX/RWX allow multiple. Subtle direction-of-scope trick.

Which statement BEST describes what an access mode of ReadWriteOnce actually constrains?

1. The volume may be mounted read-write by pods on a single node at a time
2. The volume may be mounted by exactly one pod, on one node, at any given moment
3. The volume may be written by one pod while any number of others read it concurrently
4. The volume may be mounted read-write by one pod per node across the whole cluster

Answer: A — The volume may be mounted read-write by pods on a single node at a time

A) Correct — RWO is a node-level constraint, so multiple pods on that same node can share it read-write. B) is the widely held misconception, and it describes ReadWriteOncePod, the mode added precisely to provide that stricter single-pod guarantee. C) blends RWO with ReadOnlyMany semantics that no single mode provides. D) inverts the scope, allowing one pod on every node, which is closer to a many-node mode.

A PVC bound to a dynamically provisioned volume is deleted, and the StorageClass reclaim policy is Delete. What is the outcome?

1. The PV becomes Available and can be reused by the next matching claim in the namespace
2. The PV moves to Released and waits for an administrator to clear its stale claim reference
3. The PV and the underlying storage asset are both removed, and the data is not recoverable
4. The PV is retained but flagged Failed, since dynamic volumes cannot be deleted safely

Answer: C — The PV and the underlying storage asset are both removed, and the data is not recoverable

C) Correct — Delete is the default for most dynamic provisioners and tears down the backend asset along with the PV object, which is why production classes are often switched to Retain. A) describes the Recycle-style reuse that was removed from Kubernetes. B) describes Retain, the alternative policy. D) invents a safety block that does not exist and misuses the Failed phase, which signals a reclaim error.

Dynamically provisioned PV uses which field on the PVC to pick a StorageClass?

1. volumeName, which names the specific PV the claim should bind
2. storageClassName, which names the class the provisioner uses
3. provisioner, copied from the class the administrator created
4. Only annotations; the spec fields play no part in the choice

Answer: B — storageClassName, which names the class the provisioner uses

B is right: storageClassName on the claim selects the class, and the matching provisioner then creates the PV; setting it to an empty string disables dynamic provisioning. A binds statically to an existing PV. C is a field of the StorageClass, not the claim. D describes the deprecated beta annotation, superseded by the spec field.

What is the difference between volumeBindingMode Immediate and WaitForFirstConsumer?

Immediate provisions and binds the volume as soon as the PVC is created, which can place it in a zone where the pod cannot be scheduled. WaitForFirstConsumer delays provisioning until a pod using the claim is scheduled, so the volume is created with the pod's node and zone constraints in mind.

Volume types?

emptyDir, hostPath, nfs, cloud volumes (awsEBS, azureDisk, gcePD), persistentVolumeClaim, configMap, secret.

What are the PersistentVolume phases and what does each mean?

Available: free and not yet bound • Bound: matched to a PVC • Released: the claim is deleted but the volume has not been reclaimed • Failed: automatic reclamation failed. A PVC itself is Pending until bound, then Bound.

What do the reclaim policies Delete and Retain do when a PVC is deleted?

Delete removes the PersistentVolume and the underlying storage asset. Retain keeps both; the PV goes to Released and an administrator must clean and recycle or manually recreate it before the storage can be reused.