CKAD Liveness probe Practice Question
Exhibit
Refer to the exhibit. ``` $ kubectl describe pod nginx-pod ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 10m default-scheduler Successfully assigned default/nginx-pod to node-2 Normal Pulled 10m kubelet Container image "nginx:latest" already present on machine Normal Created 10m kubelet Created container nginx Normal Started 10m kubelet Started container nginx Warning Unhealthy 5m kubelet Readiness probe failed: HTTP probe failed with statuscode: 503 Warning Unhealthy 4m kubelet Readiness probe failed: HTTP probe failed with statuscode: 503 Normal Killing 3m kubelet Container nginx is not ready, stopping it Normal Pulled 3m kubelet Container image "nginx:latest" already present on machine Normal Created 3m kubelet Created container nginx Normal Started 3m kubelet Started container nginx Warning Unhealthy 2m kubelet Readiness probe failed: HTTP probe failed with statuscode: 503 ```
Based on the exhibit, why is the container being killed and restarted?
⚠ Common exam trap
A common pitfall is forgetting that readiness probes do not restart containers; only liveness probes do. The restart policy (e.g., Always) acts on liveness failures.
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
✓
The liveness probe is failing, causing the container to be restarted.
In Kubernetes, a failing liveness probe causes the kubelet to restart the container. The exhibit shows the container being killed and restarted, which is consistent with liveness probe failure. Option A is incorrect because a failing readiness probe does not restart the container; it only marks the pod as not ready and removes it from service endpoints. Option C is incorrect: OOM would result in a different error message (OOMKilled). Option D is incorrect: repeated image pulls would cause ImagePullBackOff, not a restart after running.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The readiness probe is failing, causing the pod to be considered not ready and restarted.
Why it's wrong here
The readiness probe controls whether the pod receives traffic from a Service; when it fails, the kubelet marks the pod as NotReady and removes its endpoints, but the container continues running its main process. Restart decisions are made exclusively by the kubelet based on the liveness probe and restartPolicy, so a failed readiness probe alone would not cause a container to be killed or restarted. The exhibit shows restart activity, which is not a characteristic of readiness probe handling.
- ✓
The liveness probe is failing, causing the container to be restarted.
Why this is correct
The liveness probe is the probe that determines whether the application inside the container is healthy; if it fails, the kubelet kills the container and restarts it according to the pod's restartPolicy. The exhibit shows a restart counter increasing while the container's status cycles through Running, then terminated, then Running again, which exactly matches the behavior of a failing liveness probe. A liveness probe failure would cause the kubelet to record the reason as "Liveness probe failed: <message>" in the pod events, leading to the automatic restart observed in the exhibit.
- ✗
The container is running out of memory (OOM).
Why it's wrong here
An out-of-memory termination is recorded with a distinct reason of OOMKilled in the container status, and the exit code is typically 137 (SIGKILL), not a generic failure. While OOM events do trigger a restart when restartPolicy is Always or OnFailure, the exhibit would show the container currently in a CrashLoopBackOff or Waiting state with OOMKilled identified, rather than simply an increasing restart count that accompanies liveness probe failures.
- ✗
The container image is being pulled repeatedly.
Why it's wrong here
Repeated image pulls manifest as ImagePullBackOff or ErrImagePull, which occur during the container creation phase before the container can start. The exhibit depicts a container that was running and then killed (as indicated by an increasing restart count), meaning the image had already been successfully pulled and the image layers were present on the node. Once a container is running, image pulls are no longer involved; therefore, repeated pulling cannot be the reason for the observed termination.
Go deeper
Related to this question
Learn chapter
Kubernetes Core Concepts and Architecture
Key term
Readiness Probes
A Kubernetes mechanism that checks if a container is ready to start accepting traffic and serve requests.
Key term
Liveness Probes
A liveness probe is a Kubernetes health check that tells the system whether a container is running properly and should be kept alive or restarted.
About these practice questions
This CKAD question is part of Courseiva's 160-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD 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 CKAD exam.