KCNA Cloud Native Application Delivery Practice Question
A team is deploying a microservice application on Kubernetes. They want to ensure that during rolling updates, the new version of the service receives traffic only after the readiness probe succeeds. However, they observe that the old pods are terminated before the new pods are ready, causing a brief downtime. Which configuration change should they make to the Deployment to prevent this?
⚠ Common exam trap
KCNA often tests the interaction between maxSurge/maxUnavailable and readiness probes; candidates who focus only on the probe (C) or who pick maxUnavailable=1 (B) miss that the rollout strategy parameters control whether old pods are terminated before new ones 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
✓
Set spec.strategy.rollingUpdate.maxSurge=1 and maxUnavailable=0
Setting maxSurge=1 and maxUnavailable=0 ensures that during a rolling update, Kubernetes creates a new pod (surge) before terminating any old pod, and never allows the available pod count to drop below the desired replica count. Combined with a readiness probe, the new pod only receives traffic after it passes readiness, so the old pod is not removed until the new one is ready — eliminating the 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.
- ✗
Set spec.strategy.rollingUpdate.minReadySeconds to 0
Why it's wrong here
Setting minReadySeconds to 0 declares a pod available the instant its readiness probe passes, so the rollout proceeds immediately and old pods are removed while new ones are still warming up. Raising this value holds the update until new pods stay ready.
- ✗
Set spec.strategy.rollingUpdate.maxSurge=0 and maxUnavailable=1
Why it's wrong here
maxSurge=0 with maxUnavailable=1 permits the controller to delete an old pod before any new pod is ready, guaranteeing the capacity dip. Allowing surge above zero lets new pods become ready before old ones are terminated.
- ✗
Add a liveness probe to the container spec
Why it's wrong here
A liveness probe restarts a container when it becomes unresponsive; it does not gate traffic or delay pod termination. The downtime stems from the Deployment's rollout strategy, so the fix belongs in maxUnavailable and minReadySeconds, not in probe configuration.
- ✓
Set spec.strategy.rollingUpdate.maxSurge=1 and maxUnavailable=0
Why this is correct
Setting maxUnavailable to 0 guarantees no old pod is removed until a replacement passes its readiness probe, while maxSurge=1 permits one extra pod above the desired replica count so the new version can start alongside the old. This directly satisfies the stem's requirement that traffic shifts only after readiness succeeds, eliminating the brief downtime.
Go deeper
Related to this question
About these practice questions
Courseiva writes every KCNA question from scratch — 930 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on KCNA
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An application deployment in Kubernetes uses a Deployment object. During a rolling update, the new ReplicaSet fails to become healthy. What is the default behavior of the Deployment controller?
medium- A.It continues the rollout, ignoring the health check failures
- B.It automatically rolls back to the previous revision
- C.It scales down the old ReplicaSet to zero
- ✓ D.It pauses the rollout and keeps the old ReplicaSet running
Why D: By default, the Kubernetes Deployment controller pauses a rolling update when new pods in the updated ReplicaSet fail their readiness probes and cannot become healthy. It does not automatically roll back — the old ReplicaSet is retained at its current replica count so the application stays available while the rollout is stalled. This behavior is governed by the deployment's progressDeadlineSeconds, after which the rollout is marked as failed but still not auto-reverted.
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
This KCNA 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 KCNA exam.