CKA Troubleshooting Practice Question
A pod is failing to start with the error 'CrashLoopBackOff'. You check the logs with 'kubectl logs pod' and see nothing. What is the most likely reason?
⚠ Common exam trap
Candidates often assume 'kubectl logs' always shows something, even for a crashing pod, but if the container fails before any output is written to stdout/stderr, the logs will be empty, leading to the correct conclusion that the crash occurred during early startup.
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
✓
The container crashed before generating any log output
The 'CrashLoopBackOff' error indicates the container in the pod starts, crashes, and is repeatedly restarted by the kubelet. If 'kubectl logs pod' returns nothing, it means the container exited before writing any output to stdout/stderr, which is the default logging target for Kubernetes. Option B is correct because the container likely failed during initialization or startup, before any application code produced log entries.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The pod's log path is misconfigured
Why it's wrong here
Kubernetes does not allow users to configure custom log paths within the Pod specification for kubectl logs retrieval. Instead, the container runtime automatically redirects the container's standard output (stdout) and standard error (stderr) streams to host-managed log files. Therefore, a misconfigured log path is not a valid state or reason for missing logs.
- ✓
The container crashed before generating any log output
Why this is correct
If an application terminates immediately upon execution—such as due to a missing shared library, a syntax error in an entrypoint script, or a rapid kernel panic—it may exit before writing any bytes to stdout or stderr. In this scenario, the container runtime creates an empty log file, resulting in no output when running kubectl logs.
- ✗
The kubelet has logging disabled
Why it's wrong here
The kubelet daemon does not possess a configuration parameter to disable the collection of container standard streams. It relies on the container runtime (like containerd or CRI-O) to write stdout and stderr to the node's filesystem, which are then exposed via the Kubernetes API. Thus, empty logs cannot be attributed to a disabled logging feature in the kubelet.
- ✗
The pod is using a sidecar container for logging
Why it's wrong here
Implementing a sidecar container for log forwarding does not suppress or disable the default logging behavior of the primary application container. Even when a sidecar is present, administrators can still query the primary container's logs directly by specifying its name with the -c flag in the kubectl logs command.
Go deeper
Related to this question
Learn chapter
Installing Kubernetes with kubeadm
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
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.
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 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.