CKA Workloads and Scheduling Practice Question
Which THREE of the following are characteristics of a StatefulSet? (Select 3)
⚠ Common exam trap
Candidates often confuse a Headless Service with a regular ClusterIP Service, mistakenly thinking a ClusterIP Service is required for stable network identities, when in fact a Headless Service is mandatory for StatefulSets.
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
✓
Pods are started and terminated in a controlled order (sequentially)
Option A is correct because a StatefulSet creates and deletes pods in a strict ordinal sequence (0, 1, 2, ... for creation and reverse order for termination), which is essential for stateful workloads that need ordered startup/shutdown. Option B is correct because StatefulSets use volumeClaimTemplates to give each replica its own PersistentVolumeClaim, so every pod gets dedicated storage that persists across rescheduling. Option E is correct because each pod in a StatefulSet receives a stable, unique hostname derived from the StatefulSet name plus ordinal index (e.g., web-0, web-1), backed by a governing headless Service. Option C is not a StatefulSet characteristic; pod placement across nodes is handled by the scheduler for all workload types, not specifically by StatefulSets. Option D is inaccurate because stable network identities require a headless Service (clusterIP: None), not a regular ClusterIP Service.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Pods are started and terminated in a controlled order (sequentially)
Why this is correct
With the default podManagementPolicy of OrderedReady, a StatefulSet creates or terminates pod replicas one at a time in strict ordinal order. When scaling up, each pod must become Ready before the next is started; when scaling down or deleting, pods are removed from the highest ordinal back to the lowest, waiting for each deletion to complete. This controlled sequencing lets distributed applications bootstrap or shut down in a predictable, deterministic manner instead of all replicas launching simultaneously.
- ✓
Each pod can have its own persistent volume claim (PVC)
Why this is correct
Because StatefulSets may include a volumeClaimTemplate, Kubernetes automatically provisions a separate PVC for each replica and names it by combining a template mount name with the pod's ordinal name, such as data-web-0. This per-instance PVC is bound to the pod's identity rather than the pod's node, so when a pod is rescheduled the StatefulSet controller reattaches the same persistent volume and the application recovers the same data. This is the mechanism that gives StatefulSet pods durable, dedicated storage, which a Deployment's shared pod template cannot provide per-replica.
- ✗
Pods are automatically distributed across all nodes in the cluster
Why it's wrong here
StatefulSets do not have any built-in scheduling behavior that places one pod per Node; that is the defining behavior of a DaemonSet. The standard scheduler places StatefulSet pods based on resource requests, node affinity/anti-affinity, taints and tolerations, and other constraints, so multiple replicas may land on the same node. To intentionally spread replicas across Nodes or zones, a user must explicitly add topologySpreadConstraints or podAntiAffinity — automatic spreading is not a characteristic of StatefulSets.
- ✗
StatefulSets require a ClusterIP service for stable network identities
Why it's wrong here
Stable network identities for StatefulSet pods are served through a Headless Service, meaning a Service set with clusterIP: None, not a normal ClusterIP Service. A ClusterIP Service creates a single stable virtual IP and load-balances traffic among all selected pods, so it cannot expose each replica's individual hostname. Headless services give each pod its own DNS record such as web-0.default.svc.cluster.local, which is the prerequisite for stateful client connectivity.
- ✓
Each pod has a unique, stable network identity (e.g., web-0, web-1)
Why this is correct
Each StatefulSet pod derives a deterministic hostname from the StatefulSet name and a zero-based ordinal, such as web-0, web-1, and web-2. When a pod is deleted and recreated, it is recreated with the same name and ordinal, so the identity is stable across rescheduling and node failures. Combined with a governing headless service, this gives each instance a permanent DNS address that applications can use to contact a particular replica.
Go deeper
Related to this question
Learn chapter
Storage Basics and Volumes
Key term
Storage Classes
A Storage Class in Kubernetes is a template that defines how persistent storage is provisioned automatically, including the type of storage, performance characteristics, and provisioning policies.
Key term
Volumes
In Kubernetes, a volume is a storage resource that outlives the pod it belongs to, enabling data to persist across container restarts and be shared between containers in the same pod.
About these practice questions
This CKA question is part of Courseiva's 726-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
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.