CKA Node NotReady diagnosis Practice Question
A Node is in NotReady state. Which action should be taken first to diagnose the issue?
⚠ Common exam trap
The trap here is that candidates often jump to checking kubelet logs or restarting the kubelet, forgetting that `kubectl describe node` provides immediate visibility into node conditions and events from the control plane, which is the standard first step in the Kubernetes troubleshooting workflow.
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 describe node <node>
When a node is in NotReady state, the first diagnostic step is to gather information about the node's current status, conditions, and recent events using `kubectl describe node <node>`. This command reveals the node's conditions (e.g., Ready, DiskPressure, MemoryPressure), the last heartbeat timestamp, and any relevant events that may indicate the root cause, such as network issues or kubelet failures. It provides a high-level overview without requiring direct node access, making it the most efficient initial action.
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 describe node <node>
Why this is correct
kubectl describe node <node> is the correct first diagnostic because it displays the Node object's Status.Conditions (Ready, MemoryPressure, DiskPressure, PIDPressure, NetworkUnavailable) and a rolling list of recent Events that record taints, kubelet restarts, and CNI failures. This single command aggregates the node's current condition, capacity, allocatable resources, and the kubelet's reported heartbeats from the control plane, letting you immediately see which signal flipped the node to NotReady without requiring SSH access to the node.
- ✗
Check kubelet logs on the node
Why it's wrong here
Checking kubelet logs on the node is a useful secondary step, but it's not the definitive first choice because it requires network access to the node and parsing unstructured journald or log files across many components (sandbox, runtime, CNI). Kubelet logs can reveal the exact error—for example, a failed CRI call or a failed Exec probe—but they give you no direct view of the Node object's condition history or events that describe node-level state changes. As a first step, describe node provides the authoritative condition and heartbeat data from the apiserver, guiding whether you even need to inspect local logs.
- ✗
Restart kubelet
Why it's wrong here
Restarting the kubelet is a reactive remediation action, not a diagnostic step, and blindly restarting it can mask the root cause—for example, a persistent disk pressure condition or a broken container runtime will simply recur after restart. It also doesn't help if the node is NotReady because the control plane has not heard a heartbeat, since a restart of kubelet may actually interrupt the Kubernetes-managed heartbeat loop and delay recovery. You should always ascertain the underlying cause with describe node and relevant logs before taking any disruptive action, especially in a production cluster.
- ✗
Check API server logs
Why it's wrong here
Checking API server logs is an incorrect choice because the kube-apiserver does not compute or store node-level conditions; it merely persists the Node object status that the kubelet reports via PATCH updates. The node-lifecycle controller on the kube-controller-manager (not the API server) is responsible for marking a node NotReady after node-monitor-grace-period with no heartbeats, and that decision appears in the Node's status, not in API server audit logs. API server logs would show requests from the kubelet (like heartbeat calls), but they don't include the node's local runtime or resource pressure information that would explain why the node became NotReady.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The CKA exam frequently reuses these exact scenarios with slightly different constraints.
✓kubectl describe node <node>Correct answer▾
Why this is correct
kubectl describe node <node> is the correct first diagnostic because it displays the Node object's Status.Conditions (Ready, MemoryPressure, DiskPressure, PIDPressure, NetworkUnavailable) and a rolling list of recent Events that record taints, kubelet restarts, and CNI failures. This single command aggregates the node's current condition, capacity, allocatable resources, and the kubelet's reported heartbeats from the control plane, letting you immediately see which signal flipped the node to NotReady without requiring SSH access to the node.
✗Check kubelet logs on the nodeWrong answer — click to see why▾
Why this is wrong here
Useful but not the first step; describe node gives overview.
✗Restart kubeletWrong answer — click to see why▾
Why this is wrong here
Recovery action, not diagnosis.
✗Check API server logsWrong answer — click to see why▾
Why this is wrong here
Unlikely to show node conditions.
Analysis generated from the official CKAblueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
About these practice questions
This CKA question is part of Courseiva's 726-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.