CKA Practice Question: Cluster Architecture, Installation and Configuration
Which TWO of the following are control plane components? (Select 2)
⚠ Common exam trap
CNCF often tests the distinction between control plane and node components, and the trap here is that candidates confuse kubelet or kube-proxy as control plane components because they are critical to cluster operation, but they actually run on every node and are not part of the control plane.
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
✓
etcd
etcd (D) is a control plane component because it is the consistent, highly-available key-value store that persists all cluster state and configuration data for Kubernetes. kube-apiserver (E) is also a control plane component: it exposes the Kubernetes API, validates and processes REST requests, and is the central communication hub through which all other components interact. By contrast, kubelet (A) runs on each worker node to manage pods and containers, kube-proxy (B) runs on nodes to implement Service networking rules via iptables/IPVS, and the container runtime (C) runs on nodes to actually pull images and run containers, so none of these three are 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.
- ✗
kubelet
Why it's wrong here
The kubelet is the primary node agent that runs on every worker node (and also on control-plane nodes in most clusters), responsible for registering the node with the API server, watching PodSpecs assigned to that node, and ensuring containers in those Pods are healthy. Its entire lifecycle is tied to node-local container management, not cluster-wide state or control decisions, so it is not a control plane component. Even though it communicates with the API server, its role is execution and reporting at the node level.
- ✗
kube-proxy
Why it's wrong here
kube-proxy is a network proxy that runs on each worker node (usually as a DaemonSet) to implement part of the Kubernetes Service concept by maintaining iptables, IPVS, or userspace rules that route traffic to backend Pods. It does not make scheduling, authorization, or API decisions; it only translates service abstractions into concrete, node-local forwarding rules. Because it operates entirely in the data path on worker nodes, it is a node component, not part of the control plane.
- ✗
container runtime
Why it's wrong here
The container runtime (e.g., containerd, CRI-O) is the software that actually pulls images, starts and stops containers, and manages the low-level container lifecycle on a given node. It runs on all nodes—including worker nodes and control-plane nodes—and is a dependency for kubelet, but it is not involved in cluster control functions like API serving, scheduling, or storing cluster state. Its scope is per-node container execution, so it is not classified as a control plane component.
- ✓
etcd
Why this is correct
etcd is the distributed key-value store that holds the entire cluster's desired state—all API objects, configuration, secrets, and metadata—and it is the single source of truth for Kubernetes. It is fundamentally a control plane component because every control plane operation reads from or writes to etcd, and it requires quorum-based consensus (Raft) to maintain consistent state across replicas. Without etcd, the API server cannot operate, and the cluster has no real state to reconcile.
- ✓
kube-apiserver
Why this is correct
kube-apiserver is the front-end of the Kubernetes control plane and the only component that directly interacts with etcd; it exposes the RESTful Kubernetes API, handles authentication, authorization, admission control, and all read/write operations for cluster state. It is the central hub through which all other control plane components (controller-manager, scheduler) and node agents communicate, making it an indispensable control plane component. Its role is managing requests and maintaining the authoritative state, not running workloads on nodes.
Go deeper
Related to this question
Learn chapter
Services and Networking Fundamentals
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
Key term
Kubernetes Node Roles
Kubernetes Node Roles are labels assigned to machines in a cluster that define whether a node runs application containers (worker) or manages the cluster (control plane).
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.