CV0-004 Troubleshooting Practice Question
A cloud engineer is troubleshooting a containerized application deployed on a managed Kubernetes service. Pods are repeatedly failing to start with the status 'CrashLoopBackOff'. The engineer has confirmed that the container image exists and the pod specification is valid. Which command should the engineer use to view the most recent logs from the previous instance of the crashing container?
⚠ Common exam trap
The trap here is relying on kubectl describe or events for application logs, when the previous container instance's logs are the key to understanding the crash cause.
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
In a CrashLoopBackOff situation, the container is restarting repeatedly, so the current logs may be empty or incomplete. The --previous flag allows the engineer to access logs from the last terminated instance, which typically contains the error that led to the crash. This is the most direct way to diagnose application-level failures in Kubernetes.
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-name> --previous
Why this is correct
The --previous flag retrieves logs from the previous instance of a container in a pod that has restarted. In a CrashLoopBackOff scenario, the current container may not have produced logs yet, but the previous instance likely contains the error that caused the crash. This command is essential for diagnosing why the container is failing to start.
- ✗
kubectl exec -it <pod-name> -- /bin/sh
Why it's wrong here
kubectl exec is used to run a command inside a running container. In a CrashLoopBackOff state, the container is not running long enough to establish a session, making this command ineffective. It would fail with an error indicating that the container is not running or is restarting, so it cannot be used to inspect logs.
- ✗
kubectl describe pod <pod-name>
Why it's wrong here
While kubectl describe pod provides valuable information such as events, resource limits, and container statuses, it does not show application logs. It may indicate that the container is restarting, but it will not reveal the stack trace or error message that caused the crash. This command is complementary but not the primary tool for retrieving previous logs.
- ✗
kubectl get events --field-selector involvedObject.name=<pod-name>
Why it's wrong here
kubectl get events can show cluster-level events related to the pod, such as scheduling failures or image pull errors, but it does not capture container stdout/stderr logs. For CrashLoopBackOff caused by application errors, events may only show repeated restarts without the underlying cause. This command is useful for cluster-level issues but not for application log analysis.
Go deeper
Related to this question
About these practice questions
This CV0-004 question is part of Courseiva's 834-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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CompTIA exam blueprint
This CV0-004 practice question is part of Courseiva's free CompTIA 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 CV0-004 exam.