easyMultiple ChoiceObjective-mapped
Google ACE Practice Question: A GKE pod's container is frequently crashing and…
A GKE pod's container is frequently crashing and restarting. You need to view the logs from the previous container instance (before the last crash) to diagnose the crash cause. Which command retrieves these logs?
⚠ Common exam trap
Test-takers frequently confuse `kubectl logs` with `kubectl describe` or `kubectl get events`, thinking those commands provide log output, when in fact only `kubectl logs` retrieves container logs and the `--previous` flag is the specific mechanism to access logs from a crashed 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_NAME --previous`
The `--previous` flag in `kubectl logs` retrieves logs from the previous instance of a container in a pod, which is exactly what you need when the current container has crashed and restarted. This allows you to see the logs that led to the crash, even though the container is now running a new instance.
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`
Why it's wrong here
Running `kubectl logs POD_NAME` without the `--previous` flag retrieves logs only from the current, running container instance. After a crash and restart, that current instance likely has no logs or only output generated after the restart, so the logs from the terminated instance -- the ones containing the root cause -- are not shown. This commonly leads to the misconception that the container produced no logs at all. To diagnose a crash, you must explicitly request the previous instance's logs with `kubectl logs POD_NAME --previous`.
- ✓
`kubectl logs POD_NAME --previous`
Why this is correct
The `--previous` flag instructs kubectl to fetch the log output from the last terminated container instance in the pod. This is exactly what's needed because when a container enters a crash loop, the current instance may be freshly restarted and have no logs, while the previous instance contains the error messages, stack traces, or panic output that caused the termination. It works for both single- and multi-container pods, though for multi-container pods you must also use `-c <container-name>` to identify the correct container.
- ✗
`kubectl describe pod POD_NAME`
Why it's wrong here
While `kubectl describe pod POD_NAME` provides a detailed summary of the pod's status, container states (waiting, terminated, running), restart counts, and recent events like BackOff or OOMKilled, it does not expose the actual stdout/stderr lines that the container wrote before dying. It can tell you that the container terminated with exit code 137 (OOMKilled) or 1, and show the last state, but it does not include the application's crash log content. This makes it useful for identifying the failure mechanism but insufficient for diagnosing the root cause.
- ✗
`kubectl get events --field-selector reason=OOMKilled`
Why it's wrong here
`kubectl get events --field-selector reason=OOMKilled` filters cluster events to only those with the OOMKilled reason, which can confirm that the kernel OOM killer terminated the container due to memory exhaustion. However, events are ephemeral metadata records (time, type, reason, object, message) and do not contain the container's log output -- they indicate that an OOM event occurred, but not what the application was doing or what error it logged. Additionally, if the crash had a different cause (e.g., a panicked process or failed health check), this filter returns nothing, making it a narrow and inadequate diagnostic for crash analysis.
Go deeper
Related to this question
Learn chapter
Artifact Registry and Container Management
Key term
GKE
GKE is Google's managed Kubernetes service that automates deploying, scaling, and managing containerized applications in the cloud.
Key term
Container instance
A container instance is a running software package created from a container image that includes its own code, runtime, and dependencies, isolated from the host system.
About these practice questions
Courseiva writes every ACE question from scratch — 769 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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 ACE practice question is part of Courseiva's free Google Cloud 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 ACE exam.