CKA Workloads and Scheduling Practice Question
A Deployment named 'web-app' has 5 replicas. You want to perform a rolling update with a maximum of 3 pods unavailable during the update and a maximum of 2 extra pods above the desired count. Which YAML snippet correctly sets the rolling update strategy?
⚠ Common exam trap
Many candidates confuse the roles of `maxUnavailable` and `maxSurge`, or misread the question's constraints (e.g., thinking 'maximum of 3 pods unavailable' maps to `maxUnavailable: 2` because they subtract from desired count incorrectly).
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
✓
spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 3 maxSurge: 2
The rolling update strategy specifies `maxUnavailable: 3` and `maxSurge: 2`. With 5 desired replicas, this allows up to 3 pods to be unavailable during the update (so at least 2 pods remain running) and up to 2 extra pods above the desired count (so a maximum of 7 pods total). This matches the requirement exactly.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 2 maxSurge: 3
Why it's wrong here
This configuration reverses the intended surge and unavailable allowances. With five replicas, permitting two unavailable pods while surging by three creates a window where up to eight pods could exist but only three needed to be available, which is overly cautious on availability and unnecessarily generous with extra capacity. The correct update should allow three pods to go down simultaneously while limiting the burst to only two additional pods, so this swapped pairing misconfigures the rollout's tolerance boundaries. Additionally, the higher surge could exceed resource quotas or cluster capacity, making the update riskier in constrained environments.
- ✗
spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 2 maxSurge: 2
Why it's wrong here
Setting maxUnavailable to 2 when it should be 3 makes the deployment wait for more pods to become Ready before taking down the old ReplicaSet, because only two old Pods may be terminated at a time. This restriction slows the rolling update unnecessarily without any added availability benefit, since the intended configuration already guarantees at least two available replicas. The maxSurge value of 2 is correct, but the under-provisioned maxUnavailable throttles the pace of the update, so the rollout completes more gradually than the desired fast pace.
- ✗
spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 3 maxSurge: 3
Why it's wrong here
While maxUnavailable of 3 correctly allows three old pods to be removed at once, the maxSurge of 3 incorrectly permits three extra pods to be created above the desired five, yielding a possible total of eight pods. That extra surge is larger than needed and can overconsume CPU, memory, and other cluster resources, potentially causing the new ReplicaSet's pods to be unschedulable or to contend with existing workloads. Limiting the surge to 2 keeps the peak pod count at seven, matching the intended balance between speed and resource headroom, so this option's surge value is too permissive.
- ✓
spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 3 maxSurge: 2
Why this is correct
This is the correct configuration because it precisely balances update velocity and safety for a five-replica Deployment. By allowing up to three unavailable pods (maxUnavailable: 3), the Deployment can terminate old ReplicaSet pods aggressively, while capping the total pod count at seven with a surge of two, which keeps the cluster from being overloaded during the rollout. The update thus guarantees at least two pods remain available throughout, which is the intended minimum availability, and it completes in fewer cycles than more conservative settings would allow.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKA question from scratch — 302 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.