Google ACE Practice Question: You have a Kubernetes Deployment running 5…

You have a Kubernetes Deployment running 5 replicas. You need to update the container image with zero downtime, ensuring that at least 4 replicas are always available during the update, and no more than 6 replicas exist at any time. Which Deployment strategy and settings achieve this?

⚠ Common exam trap

Google Cloud often tests the interaction between `maxSurge` and `maxUnavailable` by presenting values that seem reasonable but violate the given constraints, and the trap here is assuming that a higher surge or higher unavailable count is safe without calculating the resulting minimum available and maximum total 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

✓

RollingUpdate with `maxUnavailable: 1` and `maxSurge: 1`.

A RollingUpdate strategy with `maxUnavailable: 1` and `maxSurge: 1` ensures that during the update, at most one replica is taken down (so at least 4 remain available) and at most one extra replica is created above the desired 5 (so no more than 6 exist at any time). This satisfies both constraints while achieving zero downtime.

Answer analysis

Option-by-option breakdown

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

✗
Recreate strategy with `minReadySeconds: 30`.
Why it's wrong here
The Recreate strategy signal to the ReplicaSet controller to terminate every existing pod first, then create replacement pods. This produces a complete gap with zero available replicas during the transition, which directly contradicts the zero-downtime requirement. The minReadySeconds=30 setting only adds a delay after a pod starts before it is marked Ready; it cannot prevent the full outage caused by the Recreate lifecycle.
✓
RollingUpdate with `maxUnavailable: 1` and `maxSurge: 1`.
Why this is correct
With maxUnavailable=1 the Deployment is allowed to take down at most one pod at a time, so at least 5 - 1 = 4 pods remain available throughout the update. With maxSurge=1 the Deployment may create at most one extra pod above the desired count, capping total simultaneous pods at 5 + 1 = 6. These two parameters exactly satisfy both the minimum-4 available and maximum-6 total constraints while keeping the rollout incremental and service available.
✗
RollingUpdate with `maxUnavailable: 0` and `maxSurge: 2`.
Why it's wrong here
Setting maxUnavailable=0 forces the Deployment to keep all 5 original pods available until new pods are Ready, which satisfies the availability minimum. However, maxSurge=2 permits creating up to 2 extra pods, so the total pod count can temporarily reach 5 + 2 = 7. That exceeds the stated maximum of 6 simultaneous pods, making this option invalid.
✗
RollingUpdate with `maxUnavailable: 2` and `maxSurge: 1`.
Why it's wrong here
This update strategy lets the Deployment scale down by 2 replicas before new pods are ready, so the available count can drop from 5 to 3. That breaks the hard requirement that at least 4 pods be available during the rollout. Although the surge of 1 caps the total at 6, it does not rescue availability, because the deficit of available pods is the binding violation.

Go deeper

Google ACE Practice Question: You have a Kubernetes Deployment running 5…

Why each option matters

Option-by-option breakdown

Related to this question