CKA Troubleshooting Practice Question

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 kubelet status using 'systemctl status kubelet' on the node

  Why this is correct

  Checking whether the kubelet is actually running on the node is the first diagnostic action: systemctl status kubelet reports whether the unit is active, the main PID, memory/CPU usage, and a short tail of recent log lines. If the service is inactive or failed, the exit status and timestamp help determine whether the node problem is a service crash, a stopped unit, or a configuration failure. This is a quick, non-destructive check that establishes the starting point before digging into logs.

• ✓

  View kubelet logs using 'journalctl -u kubelet'

  Why this is correct

  journalctl -u kubelet provides the full journal for the kubelet service, including error messages that never appear in systemctl's brief status output. You can filter by time range or priority to reveal root causes such as container runtime communication failures, invalid configuration files, TLS certificate expiry, or repeated network errors when contacting the API server. This is the second-tier diagnostic that gives the actual error text needed to confirm or rule out kubelet-side problems.

• ✓

  Check node conditions with 'kubectl describe node <node-name>'

  Why this is correct

  kubectl describe node <node-name> queries the control plane to show the node's status from the API server's perspective, including condition types like Ready, MemoryPressure, DiskPressure, PIDPressure, and the last heartbeat timestamp. It also lists taints, allocatable resources, and recent events reported by the kubelet and controllers, making it possible to spot scheduler-blocking or lifecycle issues. This complements direct node inspection by showing what the cluster observes, not just what the local service thinks.

• ✗

  Restart the kubelet using 'systemctl restart kubelet'

  Why it's wrong here

  Restarting is a possible remediation, but troubleshooting involves diagnosing first. However, it can be a step, but the question asks for valid steps to troubleshoot. It's more of a fix. Typically, you would check logs first.

• ✗

  Delete the node object and rejoin it to the cluster

  Why it's wrong here

  Deleting the node object with kubectl delete node is a remediation and reclamation procedure, not a troubleshooting step, because it only removes the API server's record of the node and forces a rejoin when the kubelet next starts. It does not reveal why the kubelet is failing, and if the root cause is a bad kubelet config or an unhealthy container runtime, the node will simply fail to join again, potentially masking the issue behind a new error cycle. This is considered a last-resort fix after a root cause has already been identified, not an early diagnostic step.

Go deeper

Related to this question