CKA Troubleshooting Practice Question
A node in the cluster is showing NotReady status. Which steps should you take to diagnose the issue? (Select the BEST initial step.)
⚠ Common exam trap
The trap here is that candidates often jump to checking control-plane components (like kube-apiserver) or pod-level issues, when the kubelet is the direct source of node status and its logs are the first place to look for local node problems.
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 'journalctl -u kubelet' on the node to check kubelet logs
When a node is NotReady, the kubelet is the primary agent responsible for reporting node status. The kubelet communicates node conditions to the control plane via periodic heartbeats. Checking the kubelet logs with 'journalctl -u kubelet' on the node itself is the most direct initial step to identify why the kubelet is failing to report readiness, such as network issues, resource exhaustion, or certificate problems.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Test DNS resolution from a pod on the node
Why it's wrong here
Testing DNS resolution from a pod helps diagnose CoreDNS or network policy issues affecting service discovery, but it does not address node-level health. A node enters the NotReady state when the control plane stops receiving heartbeats from the kubelet, which is independent of pod-level DNS resolution capabilities. Therefore, troubleshooting DNS will not reveal why the node's system daemon is failing.
- ✗
Run 'kubectl describe pod' for pods on that node
Why it's wrong here
Running 'kubectl describe pod' provides detailed lifecycle events and status conditions for individual workloads, but it cannot diagnose system-level failures of the host itself. When a node is NotReady, the underlying issue is typically related to system resources, container runtime failures, or kubelet crashes. Inspecting individual pods only shows the symptoms of the node failure, such as pods being in a Terminating or Unknown state, rather than the root cause.
- ✗
Check the kube-apiserver logs on the master node
Why it's wrong here
The kube-apiserver acts as the central administrative gateway for the cluster, but it does not manage local node-level operations or system daemons directly. While it records the loss of node heartbeats, its logs will not contain the local system errors, resource exhaustion details, or configuration issues occurring on the worker node itself. To find out why a specific node stopped communicating, you must investigate that node's local services rather than the master control plane.
- ✓
Run 'journalctl -u kubelet' on the node to check kubelet logs
Why this is correct
The kubelet is the primary node agent responsible for posting node status and heartbeats back to the control plane via the Node Lifecycle Controller. When a node transitions to NotReady, checking the kubelet's systemd logs using 'journalctl -u kubelet' is the most direct way to diagnose the issue. These logs will reveal critical failures such as container runtime connection errors, out-of-memory (OOM) events, misconfigured certificates, or disk pressure conditions that caused the agent to fail.
Go deeper
Related to this question
About these practice questions
One of 726 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 →
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.