CKA Troubleshooting Practice Question
You run 'kubectl logs pod-name' and get no output. Which TWO steps should you take to troubleshoot further?
⚠ Common exam trap
CKA often tests whether candidates know the difference between current and previous container logs — the trap is running 'kubectl logs' repeatedly on a restarted container and missing that '--previous' is needed to see the crash output.
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 describe pod pod-name' to check container state and events
Option C is correct because 'kubectl describe pod pod-name' surfaces the pod's container states (Waiting, Running, Terminated), restart counts, and the recent event stream, which reveals whether the container is crash-looping, stuck in ImagePullBackOff, or never started — all reasons 'kubectl logs' would return nothing. Option D is correct because 'kubectl logs --previous pod-name' retrieves the logs from the prior container instance, which is essential when the current container has restarted and its fresh instance has not yet produced output. Option A is not the right step because cluster-wide events are noisy and not scoped to the specific pod, making it far less targeted than 'kubectl describe pod'. Option B is incorrect because 'kubectl top pod' only reports CPU/memory metrics and does not explain why logs are empty. Option E is incorrect because it assumes an in-container log file path that may not exist and bypasses the standard container log stream that kubectl already exposes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Run 'kubectl get events --all-namespaces'
Why it's wrong here
`kubectl get events --all-namespaces` retrieves cluster-scoped events, such as scheduling failures, image pulls, or node pressure, but it does not fetch the container's stdout/stderr stream. If `kubectl logs` yields no output, events can show why a pod was never scheduled or was evicted, yet they cannot reveal application output that was produced after startup. Events are also ephemeral and may rotate out before you inspect them, making them a supplementary diagnostic rather than a direct replacement for log retrieval.
- ✗
Run 'kubectl top pod pod-name' to check resource usage
Why it's wrong here
`kubectl top pod pod-name` reports live CPU and memory utilization from the metrics-server, which is useful for identifying resource saturation or throttling, but it never exposes the container log stream. A pod with zero log output might be OOMKilled or stuck in a pending state, and while resource pressure might be a contributing cause, `top` will not show the actual stdout/stderr lines or whether the process wrote anything before failing. Additionally, `top` requires metrics-server to be deployed; in a minimal environment it may fail entirely, so it is not a reliable log-diagnosis step.
- ✓
Run 'kubectl describe pod pod-name' to check container state and events
Why this is correct
`kubectl describe pod pod-name` is a correct first step because it shows container states (Waiting, Running, Terminated) with detailed reason and message fields—for example, `CrashLoopBackOff`, `ImagePullBackOff`, or `OOMKilled`. It also lists recent events specific to that pod, such as failed volume mounts or failed liveness probes, which directly explain why a container may have never produced logs or why its log stream was cut short. When `kubectl logs` returns nothing, this command reveals whether the container even started, and if it did, what caused it to terminate or restart, making it an essential troubleshooting action.
- ✓
Run 'kubectl logs --previous pod-name'
Why this is correct
`kubectl logs --previous pod-name` is correct because when a container has restarted, the current log stream may be empty while the terminated instance's logs still exist in the runtime's rotational storage. The `--previous` flag retrieves the stdout/stderr output of the last container instance, which often contains the exact error that caused the restart or crash. This is especially effective in a CrashLoopBackOff scenario: the current container may have started only moments ago and written nothing, while the previous instance logged the panic, exception, or fatal error. It is a targeted way to recover historical log data that the default `kubectl logs` would omit.
- ✗
Run 'kubectl exec pod-name -- cat /var/log/container.log'
Why it's wrong here
`kubectl exec pod-name -- cat /var/log/container.log` executes a command inside the container, but it does not access the container runtime's managed log stream. Unless the application explicitly writes its own log file to `/var/log/container.log`, that path usually does not exist, and `cat` will return an error such as `No such file or directory` instead of log content. Moreover, `exec` requires a currently running container with a shell or suitable binary, which is often impossible for a container that has crashed or is in a pending state. This approach conflates application-level file logs with the runtime's captured stdout/stderr, and it is not the standard way to retrieve container logs.
Go deeper
Related to this question
Key term
Pod Failure Troubleshooting
Pod failure troubleshooting is the process of identifying and resolving issues that cause Kubernetes pods to crash, restart, or become unavailable.
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.
About these practice questions
Courseiva writes every CKA question from scratch — 726 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
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.