CKA Practice Question: Cluster Architecture, Installation and Configuration
You have a multi-node Kubernetes cluster. After upgrading the kubelet on a worker node, the node remains in 'NotReady' state. Which TWO actions should you take to troubleshoot? (Choose TWO.)
⚠ Common exam trap
The trap here is that candidates often jump to checking the kube-apiserver logs (Option D) or rebooting (Option E) instead of focusing on the node's local kubelet service, which is the direct source of the NotReady state.
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
✓
Check the node conditions using 'kubectl describe node <node-name>'
'kubectl describe node <node-name>' shows node conditions, including the 'Ready' status and any underlying issues like 'NetworkUnavailable', 'MemoryPressure', or 'KubeletNotReady'. This command provides a high-level view of why the node is NotReady, such as a kubelet version mismatch or resource exhaustion. It is the standard first step in diagnosing node health.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Check the node conditions using 'kubectl describe node <node-name>'
Why this is correct
Running `kubectl describe node <node-name>` surfaces the node's status object, including the `Conditions` section with entries like `Ready`, `MemoryPressure`, and `PIDPressure`. Each condition carries a `LastHeartbeatTime` and a `Reason`/`Message` that explains why the node might be `NotReady` after an upgrade. This is the fastest control-plane-level check because it reflects the kubelet's last successful status update and any taints, capacity, or allocatable changes that could affect scheduling.
- ✗
Check the pod logs on the node
Why it's wrong here
Pod logs are scoped to containers and application behavior, not to the kubelet or the node's runtime state. Node readiness is driven by the kubelet's periodic `NodeStatus` updates and its ability to manage pods; `kubectl logs` won't reveal systemd service failures, kubelet configuration errors, or CNI problems. Reviewing pod logs here is a distraction when the question is whether the node itself is ready.
- ✓
Check the kubelet service status on the node using 'systemctl status kubelet'
Why this is correct
Checking `systemctl status kubelet` on the node directly shows whether the kubelet process is active, failed, or restarting, along with the last few log lines from journald. After an upgrade, the kubelet may fail to start due to a bad systemd unit, missing dependencies, or an incompatible config file, so this command is essential for distinguishing a kubelet crash from a network- or control-plane-side issue. It is correct and should be paired with `journalctl -u kubelet -f` to see the actual error.
- ✗
Check the kube-apiserver logs on the control plane
Why it's wrong here
The kube-apiserver logs on the control plane record API requests and authorization decisions; they are not the source of a worker node's readiness conditions. Node readiness is produced by the kubelet on the node and persisted in the `Node` object, so its conditions are visible via `kubectl describe node`, not by inspecting apiserver logs. Only if you suspect the apiserver is rejecting the kubelet's `NodeStatus` update would these logs be indirect evidence, and that is a secondary check.
- ✗
Reboot the node
Why it's wrong here
Rebooting the node is a disruptive last resort, not an initial troubleshooting step, because it destroys ephemeral state and can hide the root cause of a `NotReady` condition. The kubelet's previous systemd unit, logs, and runtime metrics are lost, making it harder to diagnose whether an upgrade introduced a version skew, a config file error, or a CNI daemon failure. You should first gather node conditions and service status to preserve evidence.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
Key term
Kubernetes Node Roles
Kubernetes Node Roles are labels assigned to machines in a cluster that define whether a node runs application containers (worker) or manages the cluster (control plane).
About these practice questions
This CKA question is part of Courseiva's 302-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.