CV0-004 Deployment Practice Question
A team is using Kubernetes for container orchestration. They want to ensure that a new deployment does not cause downtime by gradually updating pods with a rolling update strategy. Which parameter in a Deployment manifest controls the number of pods that can be unavailable during the update?
⚠ Common exam trap
A common mix-up: candidates confuse `maxSurge` (which controls extra pods created above the desired count) with `maxUnavailable` (which controls pods that can be taken down), leading them to select option C instead of 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
✓
spec.strategy.rollingUpdate.maxUnavailable
The `spec.strategy.rollingUpdate.maxUnavailable` parameter in a Kubernetes Deployment manifest specifies the maximum number of pods that can be unavailable during a rolling update. This ensures that a controlled number of pods are taken down at a time, preventing downtime by maintaining a minimum number of available pods throughout the update process.
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
Why it's wrong here
minReadySeconds specifies how long a new pod must stay ready before being considered available; it does not cap unavailable pods during rollout. It is tempting because it relates to rollout readiness, but maxUnavailable is the parameter governing pod unavailability.
- ✗
spec.replicas
Why it's wrong here
Setting spec.replicas fixes the total desired pod count, not the disruption budget during a rollout; it never limits how many pods may be simultaneously unavailable. It is tempting because replicas genuinely governs scaling and steady-state availability, and would be the right field when sizing a deployment rather than tuning a rolling update.
- ✗
spec.strategy.rollingUpdate.maxSurge
Why it's wrong here
maxSurge governs how many extra pods may be created above the desired replica count during an update, not how many may be unavailable. It is tempting because it is a rollingUpdate parameter, but maxUnavailable is the field controlling unavailable pods.
- ✓
spec.strategy.rollingUpdate.maxUnavailable
Why this is correct
maxUnavailable caps how many pods may be taken offline simultaneously during a rolling update, directly satisfying the no-downtime constraint. Setting it to 0 with maxSurge above 0 keeps full capacity while new pods start, so the deployment never drops below the desired replica count.
Go deeper
Related to this question
About these practice questions
One of 834 original CV0-004 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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CV0-004 practice question is part of Courseiva's free CompTIA 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 CV0-004 exam.