Courseiva

CKA Practice Question: Cluster Architecture, Installation and Configuration

A pod is failing with 'CrashLoopBackOff'. You run 'kubectl logs mypod' and see no output. What is the first troubleshooting step?

⚠ Common exam trap

Test-takers frequently assume `kubectl logs` shows all available logs, forgetting that a crashed container's output is only accessible via the `--previous` flag, leading them to choose `kubectl describe pod` or exec instead.

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 mypod --previous

The correct first step is to use `kubectl logs mypod --previous` because the pod is in `CrashLoopBackOff`, meaning the current container has crashed and restarted. Since `kubectl logs mypod` shows no output, the current container may have exited before writing logs, or logs were written to stderr. The `--previous` flag retrieves logs from the last terminated container instance, which often contains the crash error message.

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 mypod --previous

    Why this is correct

    The `kubectl logs mypod --previous` command is the correct approach because a `CrashLoopBackOff` state indicates that the container has started, crashed, and Kubernetes is attempting to restart it. The `--previous` flag is crucial as it retrieves the logs from the *last terminated instance* of the container, which contains the actual error messages or stack traces that caused the crash, rather than the potentially empty logs of the currently restarting container.

  • kubectl exec -it mypod -- sh

    Why it's wrong here

    The `kubectl exec -it mypod -- sh` command is ineffective for a pod in `CrashLoopBackOff` because `exec` requires a container to be in a stable `Running` state to establish an interactive shell. Since the container is repeatedly crashing and restarting, it is not running long enough or stably enough to successfully execute a command inside it, making this approach unsuitable for diagnosing the initial crash.

  • kubectl delete pod mypod && kubectl create -f mypod.yaml

    Why it's wrong here

    Executing `kubectl delete pod mypod && kubectl create -f mypod.yaml` will simply terminate the existing pod and launch a new one. While this might resolve transient issues, it does not provide any diagnostic information about *why* the original pod entered `CrashLoopBackOff`. If the underlying problem, such as an application bug or misconfiguration, persists, the newly created pod will likely encounter the exact same crashing behavior without revealing the root cause.

  • kubectl describe pod mypod

    Why it's wrong here

    The `kubectl describe pod mypod` command provides valuable metadata, events, and status information about the pod and its containers from the Kubernetes API perspective. However, while it can show events indicating that a container has crashed or restarted, it does not expose the internal application logs or error messages generated *from within* the container that directly explain the cause of the application's failure, which is essential for debugging a `CrashLoopBackOff`.

About these practice questions

One of 302 original CKA 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 →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

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.