CKA Troubleshooting Practice Question
You have a pod named 'web-pod' that is in a CrashLoopBackOff state. To examine the logs from the previous instance of the container, which command should you use?
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 web-pod --previous
The correct command is kubectl logs web-pod --previous (Option A). This retrieves the logs from the previous instance of the container, which is essential when a pod is in CrashLoopBackOff because the container has restarted and the current logs may be empty or not show the error from the previous run. Option B uses kubectl exec to read a log file, but it does not access previous logs and requires the container to be running. Option C shows pod details but not logs. Option D shows current logs only, which may not capture the crash reason.
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 web-pod --previous
Why this is correct
kubectl logs web-pod --previous fetches the log stream from the last terminated container instance, which is exactly where the application's crash output is preserved. The --previous flag reads the container's previous log file that survives restarts, allowing you to see the exception, error, or stack trace that triggered the CrashLoopBackOff rather than an empty or fresh current log.
- ✗
kubectl exec web-pod -- cat /var/log/app.log
Why it's wrong here
kubectl exec web-pod -- cat /var/log/app.log tries to run a command inside the currently running container, but in a CrashLoopBackOff state the container is often not running long enough to exec into, and the file path may not even exist in the container image. It also does not access the previous container's filesystem, because each container restart replaces the writable layer, so any previous log file written to the container's filesystem is gone unless mounted to a persistent volume.
- ✗
kubectl describe pod web-pod
Why it's wrong here
kubectl describe pod web-pod aggregates pod metadata, status conditions, and recent events, but it does not surface the stdout/stderr streams that the container emitted before it crashed. Instead of showing the actual error message written by the application, it only shows high-level reasons like ExitCode or CrashLoopBackOff, which are insufficient to diagnose a root cause in the app's output.
- ✗
kubectl logs web-pod
Why it's wrong here
kubectl logs web-pod retrieves logs from the currently running container instance, but in a CrashLoopBackOff the container has already restarted, and the current instance may be in a waiting state before it produces any output. The faulty logs that contain the panic or fatal error causing the crash live in the previous container instance, so this command often returns nothing or only partial, non-diagnostic data.
Go deeper
Related to this question
Learn chapter
Storage Basics and Volumes
Key term
Log Analysis
Log analysis is the process of reviewing and interpreting system-generated records to understand what happened in an application or infrastructure.
Key term
kubectl Command Reference
kubectl is the command-line tool used to interact with and manage Kubernetes clusters by sending commands to the Kubernetes API.
About these practice questions
This CKA question is part of Courseiva's 302-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 CKA 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 CKA exam.