CKA Troubleshooting Practice Question

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