CKA Storage Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  When a Pod is deleted, the corresponding PVC is automatically deleted.

  Why it's wrong here

  When a Pod managed by a StatefulSet is deleted, the PersistentVolumeClaim that backs its volume is not deleted as part of Pod lifecycle. PVCs are independent resources with their own lifecycle; the StatefulSet controller only manages Pods and PVCs during scale-down or re-creation, but the default behavior is to retain PVCs to preserve data. This is critical for stateful workloads: even if a Pod is rescheduled or deleted, the same PVC is reattached because its binding to a specific PV remains intact. You must explicitly delete a PVC to remove the underlying storage, unless you have a cleanup policy such as in an operator.

• ✓

  The PVCs are created in the same namespace as the StatefulSet.

  Why this is correct

  PersistentVolumeClaims are namespace-scoped objects, just like StatefulSets, Pods, and Services. When a StatefulSet defines volumeClaimTemplates, the StatefulSet controller creates the resulting PVCs in the same namespace in which the StatefulSet itself is created, ensuring that Pods and their volumes exist in the same Kubernetes namespace. This namespace isolation is a fundamental part of Kubernetes identity and access control: PVs are cluster-scoped, but PVCs cannot cross namespaces, and a Pod can only mount a PVC from its own namespace. Consequently, the PVCs are inevitably co-located with the StatefulSet.

• ✓

  Each PVC gets a unique name derived from the template name and the Pod ordinal.

  Why this is correct

  Each PVC produced by a volumeClaimTemplate follows a deterministic naming scheme: `<volumeClaimTemplate name>-<statefulset name>-<ordinal>`. For a StatefulSet named `postgres` with a template named `data`, the PVCs are named `data-postgres-0`, `data-postgres-1`, and so on. This serves as the stable identifier for each Pod's storage: the ordinal in the name guarantees that when a Pod is recreated, it will bind to the exact same PVC (and consequently the same PV) that was previously used by that ordinal. Without this predictable naming, Kubernetes would not be able to preserve the identity of stateful data across Pod restarts or rescheduling events.

• ✓

  They are used to automatically create PersistentVolumeClaims for each replica.

  Why this is correct

  The `volumeClaimTemplates` field in a StatefulSet spec makes the StatefulSet controller automatically provision a PVC for each replica at creation time. This is distinct from a Deployment or ReplicaSet, which merely has a Pod template and does not create any PersistentVolumeClaims by itself; you would have to define PVCs separately and then reference them in the pod spec. Each resulting PVC is based on the template's `spec` (access modes, resources, storage class, etc.), and is created in the same namespace as the StatefulSet. Because this happens automatically, operators only need to declare the storage template once, and the StatefulSet controller handles the rest, binding each replica to its own unique PVC.

• ✗

  The volumeClaimTemplate must specify a storageClassName.

  Why it's wrong here

  Specifying a `storageClassName` in a volumeClaimTemplate is optional, not mandatory. If it is omitted, the default StorageClass configured in the cluster is used when the PVC is created, provided a default StorageClass exists. If no default is defined, the PVC may remain in a Pending state waiting for a matching provisioner; alternatively, you can explicitly set `storageClassName` to `""` to force the use of no StorageClass (only local static PVs). Therefore, stating that the template must specify a storageClassName is factually incorrect, as the StatefulSet controller does not require it to generate PVCs.

Go deeper

Related to this question