Application Deployment →mediumMultiple ChoiceObjective-mapped

CKAD Application Deployment Practice Question

A company wants to ensure zero-downtime deployments for a stateless web application running in Kubernetes. They have a single Deployment with 3 replicas and a Service of type LoadBalancer. Which strategy should they use to achieve this?

⚠ Common exam trap

It's easy for candidates to confuse maxSurge and maxUnavailable, thinking that allowing some unavailability (e.g., maxUnavailable=25%) is acceptable for zero-downtime, but in Kubernetes, zero-downtime strictly requires maxUnavailable=0 to ensure no Pods are terminated before replacements are ready.

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

✓

Use RollingUpdate with maxSurge=25% and maxUnavailable=0

A RollingUpdate strategy with maxSurge=25% and maxUnavailable=0 ensures that during a deployment, the desired number of replicas is always available (no downtime). maxUnavailable=0 means no old Pods are terminated until new ones are ready, and maxSurge=25% allows one extra Pod (25% of 3 replicas = 0.75, rounded up to 1) to be created before terminating old ones, maintaining capacity for zero-downtime updates.

Answer analysis

Option-by-option breakdown

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

✗
Use Recreate strategy
Why it's wrong here
The Recreate strategy terminates all existing pods before any new pods are created, ensuring that at some point there are zero running replicas. During this gap, the service has no healthy endpoints to route traffic to, which directly causes downtime. Because it does not provide any overlap between old and new versions, it is fundamentally incompatible with zero-downtime deployment requirements.
✗
Use RollingUpdate with maxSurge=100% and maxUnavailable=100%
Why it's wrong here
Setting both maxSurge=100% and maxUnavailable=100% permits the deployment to remove all existing pods at once (maxUnavailable=100%) while also allowing up to 100% extra pods (maxSurge=100%). However, this configuration does not force any overlap; the deployment can delete every old pod before any new pod becomes ready. As a result, the application experiences complete unavailability during the transition, making it just as downtime-prone as the Recreate strategy.
✓
Use RollingUpdate with maxSurge=25% and maxUnavailable=0
Why this is correct
With maxUnavailable=0, the rolling update guarantees that no existing pods are terminated until replacement pods have been created and reached the Ready state. The default maxSurge=25% allows the deployment to temporarily provision additional pods beyond the desired replica count, ensuring a buffer of ready pods during the transition. This combination provides zero-downtime because traffic continues to be served by the old pods until new pods are fully ready and can take over seamlessly.
✗
Use RollingUpdate with maxSurge=0 and maxUnavailable=25%
Why it's wrong here
The combination of maxSurge=0 and maxUnavailable=25% does the opposite of a zero-downtime rollout: it prevents any extra pods from being created (maxSurge=0) while explicitly allowing 25% of existing pods to become unavailable. Because new pods cannot be added ahead of time, the deployment may terminate a quarter of the replicas before replacements are ready, reducing the service's capacity and risking downtime. This option trades availability for resource efficiency, which is unacceptable for a zero-downtime requirement.

Go deeper

CKAD Application Deployment Practice Question

Why each option matters

Option-by-option breakdown

Related to this question