CKA Workloads and Scheduling Practice Question
A Deployment has been updated with a new image, but the rollout is stuck. You run 'kubectl rollout status deployment/my-app' and see 'Waiting for rollout to finish: 2 out of 5 new replicas have been updated...'. The deployment's strategy is RollingUpdate with maxSurge: 25% and maxUnavailable: 25%. What is the most likely cause?
⚠ Common exam trap
It's easy for candidates to confuse a stuck rollout with a missing selector or minReadySeconds issue, but the partial progress (2 out of 5) strongly points to Pod startup failures, not configuration mismatches or timing delays.
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 new pods are unable to start due to resource constraints on nodes.
The rollout status shows that only 2 out of 5 new replicas have been updated, indicating that the new Pods are failing to become Ready. Given the RollingUpdate strategy with maxSurge: 25% and maxUnavailable: 25% on a 5-replica deployment: - maxSurge (25% of 5 = 1.25) rounds up to 2. This means up to 7 pods can exist at once. - maxUnavailable (25% of 5 = 1.25) rounds down to 1. This means at least 4 pods must remain available. If the 2 new pods are created but cannot start (e.g., remaining in Pending due to resource constraints like CPU/Memory), they will never become Ready. The rollout will stall because the controller cannot proceed with further replacements until the new pods are healthy.
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 rollout is complete; the status message is misleading.
Why it's wrong here
The statement that the rollout is complete and the status message is misleading is incorrect. Kubernetes Deployment status messages, particularly those indicating "progressing" or "waiting for rollout to finish," are highly accurate reflections of the controller's current state and its reconciliation loop. If the status indicates the rollout is still in progress or waiting, it means the desired state (all new pods Ready, old pods scaled down) has not yet been achieved, and the controller is actively working towards it or is blocked.
- ✓
The new pods are unable to start due to resource constraints on nodes.
Why this is correct
This is the correct explanation. A Deployment performing a RollingUpdate relies on new pods becoming Ready before it can safely scale down old pods, especially with maxUnavailable preventing too many old pods from being removed. If new pods are unable to schedule onto nodes due to insufficient CPU, memory, or other resource requests exceeding available capacity, they will remain in a Pending state. Consequently, they never reach Ready, preventing the rollout from progressing and leaving the deployment stuck.
- ✗
The deployment has a missing selector label.
Why it's wrong here
A missing or incorrect selector label would prevent the Deployment controller from identifying and managing any pods associated with it. If the selector were missing, the Deployment would fail to create new ReplicaSets or manage their pods effectively, resulting in zero new replicas or an error during creation. The fact that the status implies some "new replicas are updated" indicates the selector is correctly configured and matching the pods created by the new ReplicaSet.
- ✗
The old ReplicaSet is not scaling down because the new ReplicaSet has not met the minReadySeconds.
Why it's wrong here
The minReadySeconds parameter specifies how long a newly created pod must be Ready before it is considered available for the Deployment. However, if new pods are failing to even reach the Ready state in the first place (e.g., stuck in Pending, ContainerCreating, or CrashLoopBackOff), minReadySeconds becomes irrelevant. The rollout is stalled at an earlier stage, where the fundamental condition of pod readiness is not being met, long before minReadySeconds would have any impact on availability calculations or old ReplicaSet scaling.
Go deeper
Related to this question
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.