KCNA Cloud Native Application Delivery Practice Question
A Kubernetes Deployment is configured with 'strategy.type: RollingUpdate'. The team wants to ensure that during an update, no more than 25% of pods are unavailable at any time. Which specification should be added?
⚠ Common exam trap
KCNA often tests the distinction between `maxUnavailable` (how many pods may be down) and `maxSurge` (how many extra pods may exist), so candidates who confuse the two pick Option D.
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
✓
strategy.rollingUpdate.maxUnavailable: 25%
In a RollingUpdate strategy, `maxUnavailable` defines the maximum number of pods that can be unavailable during the update relative to the desired replica count, and `maxSurge` defines how many extra pods can be created above the desired count. Setting `strategy.rollingUpdate.maxUnavailable: 25%` directly enforces the requirement that no more than 25% of pods are down at any point. The default is 25%, but the question asks which specification to *add* to guarantee it explicitly.
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.minReadySeconds: 30
Why it's wrong here
minReadySeconds delays a pod being marked Available after its readiness probe passes; it does not cap how many pods may be taken down during an update. It is the right field when the requirement is to slow rollout progression and verify stability before continuing.
- ✗
spec.replicas: 4
Why it's wrong here
replicas sets the desired pod count, not the disruption budget applied during a rolling update. With four replicas, 25% unavailability equals one pod, but the field itself does not enforce that limit. It is the right specification when scaling the workload's steady-state capacity.
- ✓
strategy.rollingUpdate.maxUnavailable: 25%
Why this is correct
Setting `maxUnavailable: 25%` directly caps how many pods may be taken offline during a rolling update, satisfying the stem's requirement that no more than a quarter be unavailable at once. It works alongside `maxSurge` to control update pacing, and belongs under `strategy.rollingUpdate` in the Deployment spec.
- ✗
strategy.rollingUpdate.maxSurge: 25%
Why it's wrong here
maxSurge governs how many extra pods may be created above the desired replica count during an update, so it controls availability upward, not the 25% unavailability ceiling. It is the correct field when the constraint is limiting additional capacity consumed during rollout.
Go deeper
Related to this question
Learn chapter
Pods and Workload Management
Key term
Kubernetes API Primitives
Kubernetes API Primitives are the basic building blocks that the Kubernetes API uses to represent and manage the state of a cluster, such as Pods, Services, Deployments, and Namespaces.
Key term
ReplicaSet and Replication
A ReplicaSet ensures a specified number of identical pod instances are running at all times in Kubernetes, using replication to maintain availability and stability.
About these practice questions
One of 930 original KCNA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
This KCNA 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 KCNA exam.