CKA Workloads and Scheduling Practice Question
A StatefulSet named 'db' has 3 replicas. You need to update the pod template to change the resource limits. After applying the change, you run 'kubectl rollout status sts db' and it hangs. What is the most likely reason?
⚠ Common exam trap
Test-takers frequently confuse StatefulSet update behavior with Deployment behavior, assuming that maxSurge or maxUnavailable settings control the rollout, when in fact StatefulSets do not support those fields and rely on ordered pod management.
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
✓
The StatefulSet's pod management policy is OrderedReady, and the first pod to update (db-2) is not becoming Ready.
StatefulSets with the default OrderedReady pod management policy update pods sequentially in reverse order (from highest ordinal to lowest). When `kubectl rollout status sts db` hangs, it indicates that the update is stuck waiting for the first pod in the update sequence (db-2) to become Ready. If db-2 fails to become Ready due to the new resource limits (e.g., insufficient cluster resources or misconfigured limits), the rollout cannot proceed to update db-1 and db-0, causing the command to hang indefinitely.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The update strategy is set to OnDelete, and you need to delete pods manually.
Why it's wrong here
If the update strategy were `OnDelete`, `kubectl rollout status` would not report a 'hanging' state waiting for pod readiness. Instead, it would simply show no progress because the controller would be waiting for manual deletion of the old pods before creating new ones, rather than actively attempting and failing to ready a new pod. The default strategy is `RollingUpdate`, which is designed to automatically manage pod replacement.
- ✓
The StatefulSet's pod management policy is OrderedReady, and the first pod to update (db-2) is not becoming Ready.
Why this is correct
StatefulSets with the default `RollingUpdate` strategy update pods in reverse ordinal order, meaning `db-2`, then `db-1`, then `db-0`. The `OrderedReady` pod management policy, which is also the default, mandates that each new pod must become `Ready` before the controller proceeds to update the next pod. If `db-2` fails its readiness probe, the entire rollout will halt indefinitely at that point, causing `kubectl rollout status` to hang.
- ✗
The maxSurge setting is preventing the update from starting.
Why it's wrong here
StatefulSets implement a strict one-by-one rolling update mechanism, replacing old pods with new ones sequentially in reverse ordinal order. Unlike Deployments, StatefulSets do not support or utilize a `maxSurge` parameter in their `RollingUpdate` strategy. Therefore, the absence or misconfiguration of `maxSurge` cannot be the reason for a StatefulSet rollout to hang, as this setting is simply not applicable to StatefulSet updates.
- ✗
The StatefulSet's service name is incorrect, causing DNS resolution failures.
Why it's wrong here
The `serviceName` field in a StatefulSet definition links it to a headless service, providing stable network identities and DNS entries for each pod. While critical for a StatefulSet's operational integrity and inter-pod communication, an incorrect `serviceName` would not typically prevent a new pod from being created or attempting to become `Ready`. The rollout status would likely reflect pod creation and readiness attempts, even if subsequent network communication issues arise due to the misconfigured service.
Go deeper
Related to this question
Learn chapter
Configuring Core Cluster Components
Key term
StatefulSets
A Kubernetes resource that manages stateful applications by providing stable network identities and persistent storage for each pod.
Key term
kubectl Command Reference
kubectl is the command-line tool used to interact with and manage Kubernetes clusters by sending commands to the Kubernetes API.
About these practice questions
This CKA question is part of Courseiva's 302-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.