CV0-004 Deployment Practice Question
A company wants to deploy a containerized application to a Kubernetes cluster using a rolling update strategy. They have defined a Kubernetes Deployment manifest. Which field controls the number of pods that can be unavailable during the update?
⚠ Common exam trap
In CompTIA Cloud+ exams, candidates often confuse `maxSurge` and `maxUnavailable`. While `maxSurge` controls the number of extra Pods created above the target, `maxUnavailable` specifically governs how many Pods can be taken down during a rolling update.
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` field in a Kubernetes Deployment manifest explicitly controls the maximum number of Pods that can be unavailable during a rolling update. This field can be set as an absolute number or a percentage of the desired Pod count, ensuring that the update proceeds without dropping below a specified availability threshold.
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.rollingUpdate.maxSurge
Why it's wrong here
maxSurge caps how many pods may exist above the desired replica count during a rolling update, governing extra capacity rather than unavailable pods. It is tempting because it sits beside maxUnavailable in the same rollingUpdate block, but it answers the opposite question: how many pods may be added, not removed.
- ✗
spec.template.spec.containers[].readinessProbe
Why it's wrong here
A readinessProbe gates traffic to a pod by testing whether its container is ready, so it delays Service endpoints rather than limiting pod availability during the rollout. It is tempting because probes do influence rollout progress, but they belong in scenarios requiring health gating, not controlling unavailable pod counts.
- ✓
spec.strategy.rollingUpdate.maxUnavailable
Why this is correct
The `maxUnavailable` field, nested under `spec.strategy.rollingUpdate`, directly caps how many pods may be simultaneously unavailable while a rolling update proceeds. This satisfies the stem's requirement to control unavailability during the rollout, whereas `maxSurge` governs extra pods created above the desired replica count instead.
- ✗
spec.replicas
Why it's wrong here
spec.replicas sets the steady-state pod count the Deployment maintains, not how many may be unavailable mid-update. It is tempting because it governs pod numbers generally, but it applies to desired capacity; the unavailable-pod limit sits under spec.strategy.rollingUpdate as maxUnavailable.
Go deeper
Related to this question
About these practice questions
This CV0-004 question is part of Courseiva's 834-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 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.