CKAD Application Observability and Maintenance Practice Question
You need to debug a Pod that is in CrashLoopBackOff. Which command should you run first?
⚠ Common exam trap
CNCF often tests the misconception that `kubectl describe pod` provides enough debugging information, but it only shows the exit code and a brief termination message, not the full application logs that reveal the actual error.
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
✓
kubectl logs <pod-name>
When a Pod is in CrashLoopBackOff, the immediate priority is to see why the container is failing. `kubectl logs <pod-name>` retrieves the container's stdout/stderr output, which typically contains the error message (e.g., missing config, runtime exception, or startup failure). This is the fastest way to get the root cause without modifying the Pod state.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
kubectl get events --sort-by=.lastTimestamp
Why it's wrong here
Cluster events track orchestration-level transitions such as BackOff or Killing, but they rarely capture the process's own stderr/stdout, which is where the fatal exception or panic is actually written. Sorting by .lastTimestamp only orders those lifecycle events chronologically and does not expose the application-level error that caused the container to exit. Thus, events can confirm the crash loop, but they do not provide the direct cause.
- ✓
kubectl logs <pod-name>
Why this is correct
kubectl logs <pod-name> streams the container's stdout and stderr, which is exactly where a crashing application typically writes the error or stack trace before exiting. Because CrashLoopBackOff means the process starts, fails, and restarts, the logs usually contain the root cause, such as a missing dependency or a failed readiness check. If the container has already restarted, you must add --previous to retrieve the crashed instance's output, making this the first, most direct diagnostic step.
- ✗
kubectl exec -it <pod-name> -- sh
Why it's wrong here
kubectl exec requires a running container with a shell or binary available, but a pod in CrashLoopBackOff has a container that is continuously terminating and restarting, so there is no stable live process to attach to. Even during the brief running window, exec often fails or immediately exits if the application shuts down, and the shell may not exist in a distroless image. This command is therefore ineffective for debugging the crash itself and cannot replace log inspection.
- ✗
kubectl describe pod <pod-name>
Why it's wrong here
kubectl describe pod provides the pod's status, restart count, and recent events, which confirm the CrashLoopBackOff condition and the BackOff reason, but it does not fetch the container logs or application error output. The Last State field may show an exit code, yet the actual error message, like a panic or a fatal config issue, remains visible only in kubectl logs. So describe is useful for cluster-level context, not for the first, root-cause command.
Go deeper
Related to this question
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.