CV0-004 Operations and Support Practice Question
A cloud engineer manages a Kubernetes cluster on Google Kubernetes Engine. A production Deployment repeatedly enters CrashLoopBackOff after a configuration change, and the engineer needs to inspect why the container is terminating without modifying the running workload. Which action should the engineer take?
⚠ Common exam trap
The trap here is assuming the current container's logs will show the crash, when a restarted container often has no output yet and the prior instance's logs are required.
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
✓
Run kubectl logs on the failing pod with the --previous flag to retrieve logs from the prior container instance
Retrieving logs from the previous container instance surfaces the actual termination error without altering the Deployment or node configuration. Because CrashLoopBackOff restarts containers, the current instance may not have logged anything yet, so the --previous flag is essential. Disruptive actions like deleting, scaling, or replacing nodes neither reveal the cause nor respect the constraint of not modifying the running workload.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable GKE node auto-repair to replace the node hosting the failing pod
Why it's wrong here
Node auto-repair addresses unhealthy nodes, not application-level container crashes. The pod would simply be rescheduled and likely crash again on the replacement node. This action does not retrieve the diagnostic information needed and modifies cluster behavior rather than inspecting the terminating container's output.
- ✓
Run kubectl logs on the failing pod with the --previous flag to retrieve logs from the prior container instance
Why this is correct
When a container crashes and restarts, the current container may not yet have produced logs. The --previous flag retrieves logs from the terminated instance, which is exactly where the crash reason appears. This is a non-disruptive read-only action that satisfies the requirement to inspect without modifying the running workload, making it the correct diagnostic step.
- ✗
Delete the Deployment and recreate it with a higher restart backoff limit
Why it's wrong here
Deleting the Deployment destroys the current state and does not reveal why the container terminated. Raising the backoff limit only changes retry behavior and masks the underlying fault. This approach also violates the requirement to avoid modifying the running workload, since it tears down and rebuilds the Deployment rather than investigating the crash.
- ✗
Scale the Deployment to zero replicas and then back to the original count
Why it's wrong here
Scaling to zero removes all pods and then recreating them does not expose the crash cause; the new pods will likely crash the same way. This is a disruptive change to a production workload and contradicts the instruction not to modify it. It also loses the prior container logs that would have shown the termination reason.
Go deeper
Related to this question
About these practice questions
One of 834 original CV0-004 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 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.