hardMultiple ChoiceObjective-mapped
CKS Practice Question: A pod running in the cluster is in a…
A pod running in the cluster is in a CrashLoopBackOff state. You run 'kubectl describe pod <pod>' and see the following event: 'Warning BackOff Back-off restarting failed container'. Which command would you run to see the standard error output of the container?
⚠ Common exam trap
CNCF often tests the distinction between `kubectl logs <pod>` and `kubectl logs <pod> --previous`; the trap here is that candidates assume the current container's logs contain the crash information, but in a CrashLoopBackOff, the current container may have already restarted and its logs are empty or show only the restart loop, so the `--previous` flag is required to see the actual error output from the failed run.
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> --previous
`kubectl logs <pod> --previous` retrieves the logs from the previous instance of a crashed or restarting container. When a pod is in CrashLoopBackOff, the current container may have already restarted, so the standard error output from the failed run is only available in the previous container's logs. This command specifically fetches those logs, which typically contain the stderr output that caused the crash.
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 logs <pod> --previous
Why this is correct
In a CrashLoopBackOff state, the current container instance has often just started and immediately exited, meaning its fresh logs are empty or contain only startup noise. The `--previous` flag makes `kubectl logs` fetch the log output from the last terminated container instance, which is exactly where the application's crash error (e.g., panic, fatal exception, or misconfiguration) is recorded. Without this flag, you lose the most relevant diagnostic data for the loop.
- ✗
kubectl exec <pod> -- cat /var/log/syslog
Why it's wrong here
`kubectl exec` requires a running container to attach and execute commands; in CrashLoopBackOff the container is repeatedly exiting, so an exec call will almost certainly fail with an error like `cannot exec into a container in a crashed state`. Additionally, `/var/log/syslog` is not a standard path inside containers — Kubernetes collects logs from the container's stdout/stderr through the runtime (e.g., containerd), not from a host-style syslog file. Even if exec worked, that path would usually not contain the application's crash output.
- ✗
kubectl describe pod <pod>
Why it's wrong here
`kubectl describe pod` provides valuable high-level information — pod status, container state, restart counts, exit codes, and Recent Events such as `BackOff` or `Failed to start container` — but it does not expose the application's own stderr or stdout output. The exit code (e.g., 1 or 137) can hint at a problem, yet the actual error message, stack trace, or panic text that drives the crash is visible only in the container logs. For a definitive root cause, `describe` alone is insufficient.
- ✗
kubectl logs <pod>
Why it's wrong here
Running plain `kubectl logs <pod>` targets the currently running container instance, which in a CrashLoopBackOff is either mid-crash or just restarted; consequently, its captured logs are often empty, truncated, or contain no error at all. The prior, crashed container instance holds the output from the failed run, and that is precisely what `--previous` retrieves. Relying on the default logs command will mislead you into thinking there are no errors when the real diagnostic information is stored in the previous instance.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 114-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 CKS 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 CKS exam.