Application Deployment →easyMultiple Choice

CKAD Application Deployment Practice Question

In a Deployment, what is the purpose of the 'maxUnavailable' field in the rolling update strategy?

⚠ Common exam trap

Watch out — candidates often confuse 'maxUnavailable' with 'maxSurge', thinking it controls the number of Pods created above the desired count, when in fact 'maxUnavailable' governs the number of Pods that can be unavailable, while 'maxSurge' controls the number of extra Pods created above the desired replicas.

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

✓

The maximum number of pods that can be unavailable during the update.

In a Deployment's rolling update strategy, the 'maxUnavailable' field specifies the maximum number of Pods that can be unavailable during the update process. This ensures that the Deployment maintains a certain level of availability by controlling how many Pods can be taken down at any given time, relative to the desired replica count. It is defined as either an absolute number or a percentage of the desired Pods, and it works alongside 'maxSurge' to manage the update's pace and safety.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The maximum number of pods that can be terminated at once.
Why it's wrong here
While this sounds plausible, maxUnavailable does not cap how many pods can be terminated in a single operation; it limits the number of pods that may be unavailable relative to the desired replica count throughout a rolling update. Unavailability can stem from terminated pods, failed readiness probes, or scheduling delays, so the field is about maintaining a service-level availability floor rather than controlling termination behavior. Even if you terminate many pods rapidly, the controller ensures the unavailable count never exceeds maxUnavailable.
✓
The maximum number of pods that can be unavailable during the update.
Why this is correct
This is the exact definition. During a rolling update, the Deployment controller ensures that at most maxUnavailable pods (default 25% of desired replicas, rounded to an integer) are out of service at any moment. It gives you control over the trade-off between update speed and service availability, allowing you to keep most of your workload serving traffic while the rest are replaced. This setting is evaluated continuously, so even if one pod fails to become ready, the controller pauses further changes to maintain the unavailability limit.
✗
The maximum time allowed for the rollout to complete.
Why it's wrong here
No such time limit exists in maxUnavailable; it is purely a count of pods. The field that governs rollout duration is progressDeadlineSeconds, which sets how long the rollout can progress without making headway before the deployment is marked as failed. In contrast, maxUnavailable controls the number of pods that can be down during the process, not how many minutes or seconds the update may take. Even a deployment with a very low maxUnavailable can run indefinitely as long as it keeps making progress.
✗
The maximum number of pods that can be created above the desired replicas.
Why it's wrong here
This describes maxSurge, not maxUnavailable. While maxUnavailable sets the lower bound (how many pods can be below desired), maxSurge sets the upper bound (how many excess pods can be created above the desired replicas) to accelerate the rollout. For example, with desired replicas of 10, a maxSurge of 3 allows up to 13 total pods, while a maxUnavailable of 2 permits only 8 serving pods at a minimum. Confusing the two is a common mistake, but they govern opposite sides of the replica count.

Go deeper

CKAD Application Deployment Practice Question

Why each option matters

Option-by-option breakdown

Related to this question