CKA Troubleshooting Practice Question
Which TWO of the following are valid commands to check the status of control plane components?
⚠ Common exam trap
The CKA exam often tests the distinction between commands that check node-level health versus component-level health, trapping candidates who confuse `kubectl get nodes` (node status) with direct control plane component checks.
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
✓
systemctl status kube-apiserver
`systemctl status kube-apiserver` directly queries the systemd service manager for the status of the kube-apiserver process, which is a core control plane component. Option C is correct because `kubectl get pods -n kube-system` lists all pods in the kube-system namespace, which includes control plane components like etcd, kube-scheduler, and kube-controller-manager when they run as static pods or Deployments. Both commands provide direct visibility into the health of control plane components.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
systemctl status kube-apiserver
Why this is correct
On clusters where control plane components are managed by systemd (e.g., packaged Kubernetes distributions or those set up with kubeadm before static pods became the default), `systemctl status kube-apiserver` queries the service manager for the exact process state, reporting whether the service is active, running, or failed. It also surfaces recent journal logs, making it a direct and authoritative check of the kube-apiserver service. However, this command is only valid when the component actually runs as a systemd unit; on clusters using static pods, it would return an error, so it is environment-specific but nonetheless a correct approach for systemd-based clusters.
- ✗
kubectl get nodes
Why it's wrong here
`kubectl get nodes` retrieves node-level information from the Kubernetes API, including conditions like 'Ready', 'MemoryPressure', and 'DiskPressure', as reported by each node's kubelet. A node can be Ready even if a control plane component like the kube-apiserver is down, because node readiness only reflects kubelet's communication with the API server and the node's own lifecycle. Therefore, this command gives no visibility into whether the kube-apiserver, controller-manager, scheduler, or etcd are actually healthy, making it invalid for the stated purpose.
- ✓
kubectl get pods -n kube-system
Why this is correct
In clusters where control plane components are deployed as static pods in the kube-system namespace, `kubectl get pods -n kube-system` directly shows the current phase and restart count of each component pod, such as kube-apiserver, etcd, kube-controller-manager, and kube-scheduler. The output reveals crash loops, pending scheduling, or successful running status, making it a valid and commonly used health check. One caveat is that this command requires a functioning API server to execute, so if the apiserver itself is completely down, `kubectl` may not respond, but as a general check it remains correct.
- ✗
kubectl get events --all-namespaces
Why it's wrong here
Events in Kubernetes are time-stamped records of cluster actions, such as image pulls, scheduling decisions, node lifecycle changes, or resource shortages, and they are aggregated from the API server's event stream. While a control plane component failure might eventually produce an event, events do not provide a direct or comprehensive status summary; a healthy component typically emits no events at all, which could be misinterpreted. Moreover, reading events requires API server access and heavy filtering to infer component health, so it is not a valid command for checking component status directly.
- ✗
kubectl top nodes
Why it's wrong here
`kubectl top nodes` queries the metrics-server to display current CPU and memory usage per node, which is useful for detecting resource saturation but says nothing about the liveness or readiness of control plane processes. A kube-apiserver can be stuck in a deadlock while consuming minimal resources, or a node can be over-utilized while all components are healthy. Because the metric is purely resource-based, it cannot indicate whether a component is running, crash-looping, or unresponsive, so it is invalid for checking component status.
Go deeper
Related to this question
Learn chapter
Configuring Core Cluster Components
Key term
Deployments
A Kubernetes resource that manages a set of identical Pods, ensuring they run the correct number of replicas and can be updated or rolled back without downtime.
Key term
kubectl Command Reference
kubectl is the command-line tool used to interact with and manage Kubernetes clusters by sending commands to the Kubernetes API.
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.