CKA Workloads & Scheduling 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.

• ✓

  Use kubectl to identify the node, SSH into the node, check kubelet and container runtime status, review logs, restart kubelet and/or container runtime

  Why this is correct

  This is the correct order because you first identify the problematic node using kubectl, then access it via SSH, diagnose the kubelet and runtime status, examine logs for errors, and finally restart the services if necessary.

• ✗

  SSH into the node, use kubectl to identify the node, check kubelet and container runtime, review logs, restart

  Why it's wrong here

  This sequence is wrong because the first step must be to identify the affected node using kubectl (e.g., kubectl get nodes, kubectl describe node <name>) so you know exactly which host to SSH into. SSHing first is guesswork—you may connect to a healthy node and waste time, or you might not even have the correct hostname/IP without consulting the cluster API. The control plane's node status and events are usually the only reliable way to know which node is actually NotReady.

• ✗

  Use kubectl to identify the node, SSH into the node, review logs, check kubelet and container runtime, restart

  Why it's wrong here

  Checking logs before verifying the current status of kubelet and the container runtime is methodologically flawed because logs represent historical output, whereas systemctl status kubelet or crictl ps show the live state. If the kubelet is not running, stale logs may point to an old error while masking a more recent failure like a crashed service or a misconfigured systemd unit. You must first confirm whether the service is active, enabled, and responsive to the CRI, then read logs to understand why it is in that state.

• ✗

  Use kubectl to identify the node, SSH into the node, restart kubelet and container runtime, check status, review logs

  Why it's wrong here

  Restarting kubelet or the container runtime before checking status and reviewing logs is premature and dangerous because it discards the diagnostic evidence you need to determine the root cause. A restart may temporarily mask the symptom, but if the underlying issue (e.g., corrupt CNI configuration, disk pressure, or a bad kubelet config) remains, the node will quickly return to NotReady. You should collect status details and logs first to understand whether the problem is a crash-loop, a configuration error, or an infrastructure failure, and only then restart as part of a targeted fix.

Go deeper

Related to this question