KCNA - Kubernetes Fundamentals (44% of the exam) - Section 1.7
Explain Pod lifecycle phases, restart behaviour, and how Deployments roll out and roll back changes.
Pending, Running, Succeeded, Failed and Unknown phases; init containers; restart policies; rolling update strategy, maxSurge and maxUnavailable; and how a Deployment revision history enables rollback.
Pod lifecycle phasesinit containersrestartPolicyrolling update strategyDeployment rollback
Practice question for this objective
lock_openFree sampleKubernetes Fundamentalsmedium
A team defines a Pod with one init container and two application containers. They want to understand the ordering guarantee that init containers provide. Which statement correctly describes how init containers behave relative to the application containers?
AInit containers run to completion in order before any application container startscheck_circle Correct
BInit containers and application containers start together, but init containers are given higher CPU priority
CInit containers run continuously alongside the application containers as sidecars
DInit containers start only after the application containers report readiness
Explain that init containers run sequentially to completion before the Pod's application containers start. Init containers exist to perform setup that must finish before the main workload runs; the kubelet starts them one at a time in the order declared, requires each to exit successfully, and only launches the application containers once every init container has completed.
Why A is correct: Init containers execute sequentially and each must finish successfully before the next runs, and only after all init containers complete do the application containers start.
Why B is wrong: Prioritised startup sounds plausible for setup work, but init containers do not start alongside the app containers at all; they run first and to completion, and CPU priority is not the mechanism.
Why C is wrong: This confuses init containers with the sidecar pattern; a classic init container terminates before the app containers begin rather than running for the life of the Pod.
Why D is wrong: Reversing the order is a common mistake, but init containers precede the application containers, so they cannot wait on app-container readiness that has not yet occurred.
Answers that look right on this material and are not. Each one is a distractor from a different question in the KCNA bank for this domain.
Kubernetes stores a full database snapshot of the cluster and restores it during a rollback
errorWhy it is wrong: A cluster-wide snapshot sounds thorough, but a Deployment rollback is scoped to that Deployment's own revision history of ReplicaSets, not a global restore of the whole cluster state.
Scale the Deployment to zero replicas and then back up.
errorWhy it is wrong: Tempting as a restart, but scaling recreates Pods from the same broken template, so the errors reappear once the Pods come back.
Pending, because the Pod has stopped doing useful work and is waiting to be cleaned up by the control plane.
errorWhy it is wrong: Tempting because the Pod is idle, but Pending means the Pod has been accepted yet one or more containers have not started, typically while scheduling or image pulls are still in progress, not after containers have exited.