CKAD Application Observability and Maintenance Practice Question
A container in a pod is crashing repeatedly. You want to see the logs from the previous (crashed) instance of the container. Which command should you use?
⚠ Common exam trap
Many exam-takers confuse `--previous` with `--tail` or `-f`, thinking they need to limit output or follow logs, when the key requirement is accessing logs from a terminated container instance.
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
The `--previous` flag in `kubectl logs` retrieves logs from the previous instance of a container that has crashed and restarted. This allows you to inspect the logs of the terminated container to diagnose the crash, even though the current container instance is running or has restarted.
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 --tail=10 <pod>
Why it's wrong here
kubectl logs --tail=10 <pod> without --previous shows log lines from the current container instance; --tail limits output to the last 10 entries but does not change which container instance is being read. In a CrashLoopBackOff, the current container may be a fresh restart with few or no log lines, so the crash details from the previous instance are never displayed. This command would only be useful if the current container were the one that crashed and hadn't restarted yet, which is not the case in a repeated-crash scenario.
- ✓
kubectl logs <pod> --previous
Why this is correct
kubectl logs <pod> --previous retrieves the logs written by the previous container instance before it terminated — exactly the data needed to diagnose a repeated crash. Kubernetes keeps a copy of the terminated container's logs on the node as long as the pod exists and the restart count is at least one, allowing --previous to replay them. The flag is the standard kubectl method to inspect the last incarnation of a failing container. This is the correct approach.
- ✗
kubectl logs -c <container> <pod>
Why it's wrong here
kubectl logs -c <container> <pod> selects a specific container by name within a multi-container pod, which is essential there but irrelevant here. Without --previous, this command still reads only from the currently running instance of that named container. For a crashing container, the current instance is typically the newest restart, not the one that produced crash output, so the flag alone cannot recover the lost logs. The correct way to use -c with crash logs would be -c <container> --previous.
- ✗
kubectl logs -f <pod>
Why it's wrong here
kubectl logs -f <pod> attaches to the live log stream of the pod's current container, waiting for new lines to be written. Since the container is crashing and restarting, the runtime may have moved to a new instance; -f does not backfill output from earlier terminated instances. It can even block indefinitely if no new output appears, and any previous crash output is already outside the live stream's reach. This flag is for tailing real-time logs, not for historical diagnosis.
Go deeper
Related to this question
About these practice questions
One of 826 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.