CKAD Application Observability and Maintenance Practice Question
A Pod is stuck in CrashLoopBackOff. You run 'kubectl logs mypod' and get no output. What is the most likely cause?
⚠ Common exam trap
CNCF often tests the distinction between a container that never starts (image pull failure) and one that starts but crashes immediately, with the key clue being the Pod status (CrashLoopBackOff vs ImagePullBackOff) and the absence of log output indicating a pre-log crash.
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 application crashes before writing any logs.
When a Pod is in CrashLoopBackOff and `kubectl logs mypod` returns no output, the most likely cause is that the application crashes before it can write any logs to stdout/stderr. The container starts, runs briefly, and exits before the logging framework initializes, so no log data is captured by the container runtime.
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 Pod is not ready yet.
Why it's wrong here
The Pod is not ready yet. This is incorrect because readiness probes only affect Service endpoints and Pod readiness status, not container restarts. A Pod stuck in CrashLoopBackOff has a container that has already exited multiple times, as indicated by the restart count and the CrashLoopBackOff reason itself. A not-ready Pod would remain Running with no restarts, not enter a crash-loop state.
- ✓
The application crashes before writing any logs.
Why this is correct
The application crashes before writing any logs. This is the correct answer because empty output from `kubectl logs` means the process exited before emitting anything to stdout/stderr. Many applications crash during early startup—such as on missing configuration, failed dependency connection, or a panic in initialization—before reaching any logging call. The container repeatedly restarts, and each attempt produces no logs, so the crash loop yields empty log output.
- ✗
The liveness probe is failing.
Why it's wrong here
The liveness probe is failing. This is incorrect in this specific scenario because a failing liveness probe would kill a running container, and the application would typically have logged some output before the probe timeout occurred. Since `kubectl logs` shows no output at all, the container is crashing before the probe even gets a chance to run, or before the application emits logs. Liveness probe failures can cause CrashLoopBackOff, but they usually leave behind logs from the failed attempt.
- ✗
The container never started due to a missing image.
Why it's wrong here
The container never started due to a missing image. This is incorrect because a missing or invalid image would result in ImagePullBackOff, not CrashLoopBackOff. In CrashLoopBackOff, the container has successfully started and then exited with a non-zero exit code, whereas ImagePullBackOff means the container was never created because the image could not be pulled. The `kubectl describe pod` output would show image-pull errors, not repeated container exits.
Go deeper
Related to this question
About these practice questions
One of 160 original CKAD 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 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.