Application Deployment →mediumMultiple ChoiceObjective-mapped

CKAD Application Deployment Practice Question

You have a Deployment 'app' with the following strategy configuration: 'type: RollingUpdate', 'rollingUpdate: {maxSurge: 0, maxUnavailable: 1}'. You update the container image. What is the behavior during the update?

⚠ Common exam trap

The trap is that candidates often confuse the Kubernetes rolling update parameters: `maxSurge: 0` means no extra pods can be created above the desired count, and `maxUnavailable: 1` means at most one pod can be unavailable at a time. This results in a sequential termination-then-creation process, not parallel or batch updates.

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

✓

One old pod is terminated, then a new pod is created, repeating until all pods are updated.

With `maxSurge: 0` and `maxUnavailable: 1`, the RollingUpdate strategy ensures that during the update, no extra pods beyond the desired replica count are created (surge is zero), and at most one pod can be unavailable at any time. The Deployment controller first terminates an old pod (making one unavailable), then creates a new pod to replace it, repeating this process until all pods are updated. This guarantees a controlled, sequential rollout with minimal disruption.

Answer analysis

Option-by-option breakdown

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

✗
A new pod is created first, then the oldest pod is terminated.
Why it's wrong here
A new pod created before terminating an old one briefly increases the total replica count above the desired number, which is only possible when maxSurge is greater than zero. In this deployment, maxSurge is set to 0, meaning the controller cannot exceed the desired replica count at any point. Therefore, the update cannot create a replacement until the old pod is terminated, making this ordering invalid.
✗
Two old pods are terminated at a time, while new pods are created.
Why it's wrong here
Terminating two old pods concurrently would require two unavailable pods at the same moment, which violates the maxUnavailable=1 limit as only one pod at a time may be taken down. The rolling update controller strictly enforces the specified unavailable threshold, and would not initiate two terminations simultaneously. This option also incorrectly implies that scaling down and up happen in parallel, but the controller serializes pod replacements.
✓
One old pod is terminated, then a new pod is created, repeating until all pods are updated.
Why this is correct
With maxSurge=0, the desired replica count cannot be exceeded, and with maxUnavailable=1, at most one pod may be down during the update. This configuration forces a strictly sequential pattern: the controller first terminates an old pod, which counts as one unavailable pod, then creates a new pod to restore the replica count to the desired number. It then repeats this cycle for each remaining old replica, so one old pod is terminated, a new pod is created, and this continues until all pods are rolled over. This approach maintains availability without any temporary scaling up.
✗
All old pods are terminated simultaneously, then new pods are created.
Why it's wrong here
Terminating all old pods at once before creating replacements is the Recreate deployment strategy, not a rolling update, and it causes a complete service outage during the transition. Even if the deployment strategy were RollingUpdate, this action would make all replicas unavailable simultaneously, far exceeding the maxUnavailable=1 constraint, which permits only a single pod to be down at any time. Therefore, the controller cannot perform an all-at-once termination under these settings.

Go deeper

CKAD Application Deployment Practice Question

Why each option matters

Option-by-option breakdown

Related to this question