KCNA Kubernetes Fundamentals Practice Question
A team observes that a Pod is stuck in CrashLoopBackOff. The Pod runs a single container with an entrypoint that exits with non-zero code after a few seconds. The team wants to inspect the container's logs to understand why it is crashing. Which command should they use?
⚠ Common exam trap
CNCF often tests the distinction between `kubectl logs` (which shows container output) and `kubectl describe pod` (which shows events and status), leading candidates to choose describe when they need actual log content.
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> --previous
The `kubectl logs <pod-name> --previous` command retrieves the logs from the previous instance of a crashed container. Since the Pod is in CrashLoopBackOff, the current container has already exited, and the `--previous` flag accesses the logs of the last terminated container, which contains the crash output (e.g., the non-zero exit code and error messages). This is the direct way to see why the entrypoint failed.
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 pods
Why it's wrong here
kubectl get pods only lists Pods and their status, showing CrashLoopBackOff but not the container's stdout or stderr. It is tempting because it is the first command used to confirm Pod state, and it would be correct if the question asked how to check which Pods are running or restarting.
- ✓
kubectl logs <pod-name> --previous
Why this is correct
Because the container exits with a non-zero code, the current instance has already terminated, so its live logs are unavailable. The --previous flag retrieves logs from the prior container instance, exposing the crash output needed to diagnose the CrashLoopBackOff.
- ✗
kubectl describe pod <pod-name>
Why it's wrong here
kubectl describe pod reports events, scheduling and container state, but not the application's stdout or stderr output. It is tempting because it surfaces image pull and probe failures, and it would be correct if the question asked how to inspect a Pod's configuration, events or resource conditions.
- ✗
kubectl exec -it <pod-name> -- sh
Why it's wrong here
The container exits within seconds, so no running process exists for exec to attach to; the command fails with a connection error. It is tempting because exec is the standard tool for interactive troubleshooting inside a live container, and would be correct if the Pod were running and the fault lay in its runtime environment rather than its startup.
Go deeper
Related to this question
About these practice questions
Courseiva writes every KCNA question from scratch — 930 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 KCNA 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 KCNA exam.