CKA Practice Question: Cluster Architecture, Installation and Configuration
Which TWO components run on worker nodes? (Select 2)
⚠ Common exam trap
Many candidates confuse control plane components (etcd, kube-apiserver, kube-scheduler) with node-level agents, especially since kube-proxy is sometimes mistakenly thought to be optional or only for network plugins, but it is a required component on every worker node.
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
✓
kubelet
kubelet (B) is correct because it is the primary node agent that runs on every worker node, registering the node with the API server and managing pod lifecycles via the container runtime. kube-proxy (E) is also correct because it runs on each worker node to maintain network rules (iptables/IPVS) that implement Kubernetes Service load balancing and pod networking. etcd (A) is incorrect because it is the cluster's distributed key-value datastore, typically running on control plane nodes. kube-apiserver (C) is incorrect because it is the control plane's front-end REST API server, not a worker node component. kube-scheduler (D) is incorrect because it is a control plane component that assigns pods to nodes rather than running on the worker nodes themselves.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
etcd
Why it's wrong here
etcd is a distributed key-value store that serves as the cluster's single source of truth for all configuration, desired state, and metadata. It is a control plane component that is never scheduled on worker nodes by design; even when co-located on a node, that node is functioning as a control plane node. The kubelet on a worker node does not read or write etcd directly — all access goes through the API server.
- ✓
kubelet
Why this is correct
The kubelet is the primary node agent that runs on every node and is responsible for ensuring that containers described in PodSpecs are running and healthy. It registers the worker node with the cluster API server and continuously monitors the status of Pods, executing actions such as starting, stopping, or restarting containers as needed. It directly manages the container runtime (like containerd) and enforces resource limits and probes.
- ✗
kube-apiserver
Why it's wrong here
kube-apiserver is the front-end of the Kubernetes control plane, exposing the Kubernetes API and acting as the aggregation point for all cluster management interactions. It validates and processes all REST requests, then persists the resulting state in etcd, yet it itself does not manage containers or run on worker nodes. Worker node components such as kubelet and kube-proxy contact the API server, but the server is intended to run on control plane hosts only.
- ✗
kube-scheduler
Why it's wrong here
kube-scheduler is a control plane component responsible for assigning Pods to specific worker nodes based on resource requirements, policy constraints, affinity rules, and data locality. It is a pure decision-making process that runs on the control plane, not on worker nodes; once it selects a node, the API server writes that binding, and the kubelet on the chosen worker actually launches the Pod. It has no presence on worker nodes.
- ✓
kube-proxy
Why this is correct
kube-proxy is a per-node network proxy that implements the Service abstraction by maintaining iptables, IPVS, or similar rules to route traffic to backend Pods across the cluster. It runs as a DaemonSet on all nodes, including bare-metal and cloud workers, and is essential for east-west traffic load balancing. While the kubelet handles container lifecycle, kube-proxy handles traffic routing at the networking layer, and it does not execute on control plane nodes by default.
Go deeper
Related to this question
Learn chapter
Installing Kubernetes with kubeadm
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
Key term
Container Runtime
A container runtime is software that runs containers by using the host operating system's kernel to isolate processes, manage filesystem layers, and handle networking.
About these practice questions
Courseiva writes every CKA question from scratch — 726 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.