CKA Troubleshooting Practice Question
Which TWO of the following are correct methods to check the health of the kube-apiserver?
⚠ Common exam trap
On the CKA exam, remember that control plane components (kube-apiserver, kube-controller-manager, kube-scheduler, etcd) in a kubeadm cluster run as static pods. Do not attempt to manage or check them using `systemctl`. Only the `kubelet` and 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
✓
Run 'kubectl get pods -n kube-system -l component=kube-apiserver'
Option C is correct because kube-apiserver typically runs as a static pod in the kube-system namespace, so 'kubectl get pods -n kube-system -l component=kube-apiserver' lets you verify the pod's status, readiness, and restart count. Option E is correct because the kube-apiserver exposes a /healthz endpoint on its secure port (6443 by default), and 'curl -k https://localhost:6443/healthz' returns 'ok' when the API server is healthy. Option A is wrong because 'kubectl top nodes' reports CPU and memory usage from metrics-server, not API server health. Option B is wrong because kube-apiserver is usually a static pod managed by the kubelet, not a systemd unit, so 'systemctl status kube-apiserver' would typically fail. Option D is wrong because 'journalctl -u kubelet' shows kubelet logs, which may reveal pod issues but does not directly check the kube-apiserver's 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.
- ✗
Run 'kubectl top nodes'
Why it's wrong here
kubectl top nodes reports CPU and memory usage from metrics-server for cluster nodes, revealing nothing about API server responsiveness or component status. It is tempting because it is a quick cluster-wide health glance, and it would be correct for capacity or resource-pressure investigations.
- ✗
Run 'systemctl status kube-apiserver'
Why it's wrong here
On systemd-managed clusters the kube-apiserver runs as a static pod, so systemctl reports no such unit; the kubelet, not systemd, supervises it. It tempts because systemctl status is the standard health check for kubelet and container-runtime services installed as systemd units on each node.
- ✓
Run 'kubectl get pods -n kube-system -l component=kube-apiserver'
Why this is correct
The kube-apiserver runs as a static pod in the kube-system namespace, labelled component=kube-apiserver on kubeadm clusters, so listing pods with that label selector reveals its phase and restart count. This checks control-plane health through the API itself.
- ✗
Run 'journalctl -u kubelet'
Why it's wrong here
journalctl -u kubelet reports kubelet service logs, not kube-apiserver health; the API server runs as a static pod or systemd unit of its own. It is tempting because kubelet logs often surface API connectivity errors, and checking kubelet is correct when diagnosing node-level or pod-runtime failures.
- ✓
Run 'curl -k https://localhost:6443/healthz'
Why this is correct
This does check the health endpoint, but the command is correct. However, the question asks for TWO correct methods. Both A and B are correct. E is also correct but since we need exactly two, we choose A and B as more direct.
Go deeper
Related to this question
About these practice questions
One of 726 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.