CKA Troubleshooting Practice Question
You need to check the status of control plane components. Which TWO commands are appropriate?
⚠ Common exam trap
The CKA exam environment is built using kubeadm. Do not look for systemd services for the apiserver, controller-manager, or scheduler, as they run as static pods. Only the kubelet and the container runtime (e.g., containerd) run as systemd services on the nodes.
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 get pods -n kube-system
To check the status of control plane components in a kubeadm-established cluster, use 'kubectl get pods -n kube-system' to inspect the static pods. 'kubectl get componentstatuses' (deprecated but still a valid status check) reports health of the control plane components. 'systemctl status kube-apiserver' is not appropriate because the API server runs as a static pod, not a systemd service.
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 get pods -n kube-system
Why this is correct
Control plane components run as static pods in the kube-system namespace, so listing pods there reveals their phase, restart counts and readiness. This works on clusters where the componentstatuses API is deprecated or disabled, making it the reliable fallback for verifying scheduler, controller-manager and etcd health.
- ✗
systemctl status kube-apiserver
Why it's wrong here
On kubeadm clusters the control plane runs as static pods managed by the kubelet, so systemctl status kube-apiserver reports no such unit. It is tempting because kubelet itself is a systemd service, but apiserver status is verified via crictl ps or kubectl get pods -n kube-system.
- ✓
kubectl get componentstatuses
Why this is correct
This command queries the legacy componentstatuses API, which reports health for scheduler, controller-manager and etcd directly. It surfaces control plane component condition without needing to inspect individual pods, giving a quick aggregate view of whether each component is healthy or unreachable.
- ✗
top -u kube
Why it's wrong here
top -u kube filters processes by a user named kube, which does not exist for control plane components; it reports live CPU and memory per process. It is tempting as a general Linux monitoring tool, but component status comes from systemctl or crictl, not process accounting.
- ✗
systemctl list-units --type=service
Why it's wrong here
systemctl list-units --type=service enumerates every systemd service on the node, not control plane component health specifically. It is tempting because kubelet runs under systemd, but the precise check is systemctl status on individual units such as kube-apiserver, or crictl ps for static pods.
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.