KCNA Container Orchestration Practice Question
You have a Deployment with three replicas. You want to update the container image but ensure that only one pod is updated at a time, and the update proceeds only if the new pod becomes healthy. Which update strategy should you configure?
⚠ Common exam trap
In the KCNA exam, candidates often misinterpret that maxSurge controls the number of pods updated at a time, when in reality it controls the number of extra pods allowed above the desired count, while maxUnavailable controls the number of pods that can be unavailable during the update; candidates may incorrectly choose Option A thinking maxSurge=1 means one pod at a time, but maxSurge=3 allows three new pods to be created simultaneously, violating the 'only one pod updated at a time' constraint.
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 maxSurge=1 and maxUnavailable=0
A RollingUpdate strategy with maxSurge=1 and maxUnavailable=0 ensures that exactly one new pod is created before any old pod is terminated, and the update only proceeds when the new pod passes its readiness probe (i.e., becomes healthy). This guarantees that at all times during the update, the desired number of replicas (3) are available, and only one pod is updated at a time, matching the requirement.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
RollingUpdate with maxSurge=3 and maxUnavailable=1
Why it's wrong here
maxSurge=3 permits three extra pods during the update, so more than one new pod can roll out at once, breaching the one-at-a-time requirement. It is tempting because it accelerates rollouts, but maxSurge=1 with maxUnavailable=0 gives the required single-pod, health-gated progression.
- ✓
RollingUpdate with maxSurge=1 and maxUnavailable=0
Why this is correct
RollingUpdate with maxSurge=1 and maxUnavailable=0 replaces pods incrementally: one new pod is created while all existing replicas stay available, and the rollout advances only once that pod passes its readiness probe. This satisfies the constraints of updating a single pod at a time and gating progress on new-pod health.
- ✗
Canary deployment via Ingress
Why it's wrong here
Canary via Ingress splits traffic by percentage at the ingress layer, not pod-by-pod replacement; it cannot enforce one-at-a-time rollout with readiness gating. It is designed for gradual user-facing traffic shifting to a new version. The Deployment's rollingUpdate strategy with maxUnavailable and maxSurge controls pod replacement.
- ✗
Recreate strategy
Why it's wrong here
Recreate terminates all existing pods before starting new ones, causing downtime and updating every replica simultaneously, which contradicts the one-at-a-time and health-gated requirements. It is tempting for stateful workloads where old and new versions cannot coexist, but RollingUpdate with maxUnavailable=0 and maxSurge=1 fits here.
Go deeper
Related to this question
About these practice questions
One of 930 original KCNA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.