CKA Workloads and Scheduling Practice Question
You have a Deployment with 4 replicas. During a rolling update, you want to ensure that only 2 pods are unavailable at any given time. Which field should you set in the Deployment spec?
⚠ Common exam trap
Candidates often confuse `maxUnavailable` with `maxSurge`; candidates often pick `maxSurge` thinking it controls unavailability, but it actually controls how many extra Pods can be created above the replica count during an 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 specifies the maximum number of Pods that can be unavailable during a rolling update. Setting it to 2 ensures that at most 2 replicas are unavailable at any given time, which aligns with the requirement of having 4 replicas and allowing only 2 unavailable pods.
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.maxUnavailable
Why this is correct
This is the correct field path for defining rolling update behavior in a Kubernetes Deployment. By setting spec.strategy.rollingUpdate.maxUnavailable to 2, you guarantee that at least 2 pods (out of the 4 desired replicas) remain active and available to serve traffic at any given point during the rolling update process.
- ✗
spec.updateStrategy.rollingUpdate.maxUnavailable
Why it's wrong here
While this path looks plausible, spec.updateStrategy is the schema configuration used exclusively by StatefulSets and DaemonSets to manage their rolling updates. For a Deployment resource, Kubernetes expects the configuration under spec.strategy instead. Attempting to apply this field to a Deployment will result in a validation error or be ignored by the API server.
- ✗
spec.replicas.maxUnavailable
Why it's wrong here
In the Kubernetes Deployment schema, spec.replicas is a simple integer field that specifies the desired number of concurrent pods. It is not an object and cannot accept nested fields like maxUnavailable. Trying to configure this path will cause the kubectl client-side validation or the API server schema validation to fail immediately.
- ✗
spec.strategy.rollingUpdate.maxSurge
Why it's wrong here
The maxSurge parameter defines the maximum number of additional pods that can be created above the desired replica count during an update. While it is a valid field under spec.strategy.rollingUpdate, it controls capacity expansion rather than limiting the number of offline or unavailable pods. Using it here would not directly enforce the requirement to keep at least two pods running.
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.