CKAD Application Observability and Maintenance Practice Question
A developer reports that a pod named 'api-pod' is restarted repeatedly. You run 'kubectl get events --field-selector involvedObject.name=api-pod' and see multiple events with reason 'BackOff' and message 'Back-off restarting failed container'. Which probe failure is MOST likely causing this?
⚠ Common exam trap
Watch out — candidates often confuse readiness probe failures (which only affect traffic) with liveness probe failures (which cause restarts), leading them to pick Option B when the BackOff event clearly indicates container restarts.
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
✓
Liveness probe failure
The 'BackOff' event with 'Back-off restarting failed container' indicates the kubelet is repeatedly restarting the container because it exited with a non-zero exit code. This behavior is directly caused by a liveness probe failure: when the liveness probe fails, kubelet kills the container and restarts it, leading to a crash loop and the BackOff state. Readiness and startup probes do not trigger restarts—they only control traffic routing or delay other probes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Resource quota exceeded
Why it's wrong here
Resource quotas are admission controls evaluated by the API server at creation time. If a namespace's quota for CPU, memory, or object count is exceeded, pod creation is rejected with a 403 Forbidden error; the API server never affects already-running containers. Restarting a container is a kubelet action triggered by liveness probe failure, container exit code, or a kill signal — not by quota enforcement. A quota violation cannot cause a running pod to restart; it only prevents new pod/container creation.
- ✗
Readiness probe failure
Why it's wrong here
Readiness probes control traffic routing, not lifecycle. When a readiness probe fails, the kubelet marks the pod as NotReady and removes its endpoint from Services, but leaves the container processes running untouched. No restart is initiated because the pod may recover and resume serving. In contrast, container restarts are exclusively initiated by liveness probe failures or the container exiting on its own. Thus a readiness probe failure would manifest as loss of service, not a pod restart.
- ✗
Startup probe failure
Why it's wrong here
Startup probes are checked only during the initial startup phase; once the probe succeeds, it is disabled and never runs again. A startup probe failure does kill and restart the container, but this occurs before the container is considered started, while liveness probes are intentionally paused. If a pod has been running and then restarts, the startup probe is no longer active, so it cannot be the cause; the restart event message for a startup failure would be 'Startup probe failed' rather than 'Liveness probe failed.' Therefore, a startup probe failure cannot explain the developer's report.
- ✓
Liveness probe failure
Why this is correct
Liveness probes are the kubelet's health check for container liveness; if a liveness probe fails, the kubelet kills the container and restarts it according to the pod's restartPolicy (default is Always). This is the standard self-healing mechanism designed to recover from deadlocks, unbounded memory leaks, or hung processes. When a developer sees a pod restart, the most common cause is an unhealthy container being restarted by a failed liveness probe. The event for this would be 'Liveness probe failed' with a subsequent container recreate.
Go deeper
Related to this question
Learn chapter
DNS for Service Discovery and External Name Resolution
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.
Key term
Startup Probes
A Kubernetes mechanism that checks whether an application inside a container has started successfully, and delays other health checks until it is ready.
About these practice questions
Courseiva writes every CKAD question from scratch — 826 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 →
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.