CKAD Application Observability and Maintenance Practice Question
A pod named 'db-pod' is running but not responding as expected. You want to check its logs from the previous instantiation (after a crash). Which command should you use?
⚠ Common exam trap
Many exam-takers confuse `kubectl logs` with `kubectl describe` or assume that `kubectl exec` into the running container can access logs from a previous crash, but the `--previous` flag is the only way to retrieve 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 db-pod --previous
The `--previous` flag in `kubectl logs` retrieves logs from the previous instantiation of a container in a pod that has crashed or restarted. This allows you to inspect the logs from the terminated container before the current running instance, which is essential for debugging why the pod is not responding as expected after a 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 exec db-pod -- cat /var/log/app.log
Why it's wrong here
kubectl exec requires a live container to run the command; if the container has already crashed, the exec call fails because there is no running container to attach to. Even when the container is briefly running, this command simply reads the current /var/log/app.log file from the live filesystem, which does not expose the previous (crashed) container's captured stdout/stderr logs that Kubernetes has stored.
- ✗
kubectl logs -f db-pod
Why it's wrong here
The -f flag in kubectl logs streams the current output of the running container, following new log lines in real time. It only attaches to the live container's log stream and never touches the historical, stored logs of a previously terminated container instance, so it cannot reveal the crash output from before the restart.
- ✗
kubectl describe pod db-pod
Why it's wrong here
kubectl describe pod aggregates the pod's specification, current status, and recent events such as failed liveness probes or image pull errors, but it does not read or display the container's actual stdout/stderr log contents. While it can show why a container crashed based on event metadata, it never gives you the error messages written to the application logs.
- ✓
kubectl logs db-pod --previous
Why this is correct
The --previous flag instructs kubectl to fetch the log file from the last container instance that terminated, which is exactly the data you need when the current container was restarted due to a crash. This works even if the current container is now running, as long as a previous instance exists; if the pod has multiple containers, you must add -c <container-name> to target the right one.
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 826-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 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.