- What Domain 1 Actually Covers
- Cluster Architecture Deep Dive
- Kubeadm Installation & Cluster Bootstrapping
- RBAC: Roles, ClusterRoles, and Bindings
- Kubeconfig Files and Context Switching
- etcd Backup and Restore
- Kubernetes Version Upgrades with Kubeadm
- How to Schedule Your Domain 1 Preparation
- Exam Mechanics That Affect Domain 1 Tasks
- Frequently Asked Questions
- Domain 1 carries 25% of your CKA score - roughly 4-5 tasks out of 15-20 total performance-based questions.
- Kubeadm cluster bootstrapping, etcd backup/restore, and RBAC are the three highest-frequency topic clusters in this domain.
- The CKA exam runs on the latest Kubernetes minor release; verify the exact version on the Linux Foundation FAQ before scheduling.
- Every task is solved at the Linux command line; written answers and multiple-choice do not exist in the CKA format.
What Domain 1 Actually Covers
Domain 1 - Cluster Architecture, Installation & Configuration - represents 25% of the Certified Kubernetes Administrator exam, making it the second-largest domain behind Troubleshooting. If you are mapping raw effort to potential score, this is the second-best place to invest your preparation time after you have studied the CKA Exam Domains 2026: Complete Guide to All 5 Content Areas.
What separates Domain 1 from the other four domains is that it tests your ability to build and maintain the control plane itself - not just deploy workloads onto an existing cluster. Candidates who have only ever used managed Kubernetes services like EKS or GKE often find this domain the steepest learning curve because those platforms hide every topic it covers.
The domain breaks into six concrete skill areas:
- Understanding Kubernetes cluster architecture and the role of every control-plane component
- Bootstrapping a cluster with
kubeadm - Managing RBAC - Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings
- Working with kubeconfig files and switching contexts
- Performing etcd snapshots and restoring from them
- Upgrading a Kubernetes cluster using
kubeadm upgrade
Every one of these is tested as a performance-based task. You will be dropped into a live terminal connected to one or more pre-built clusters and asked to produce a real result - a running cluster, a backed-up etcd, a working RBAC policy - not describe one.
Cluster Architecture Deep Dive
Before you can install or troubleshoot a cluster, you need a precise mental model of what runs where and why. The CKA exam will give you broken or partially configured clusters; understanding component responsibilities is how you diagnose them quickly.
Control Plane Components
Core Control Plane Components
Every CKA candidate must be able to identify what each component does, where it runs, and what happens when it fails.
- kube-apiserver - The single entry point for all cluster operations. Every
kubectlcall hits the API server. It authenticates requests, validates them, and persists state to etcd. - etcd - The distributed key-value store that is the only persistent state in a Kubernetes cluster. If etcd is lost without a backup, the cluster state is gone.
- kube-scheduler - Watches for unscheduled pods and assigns them to nodes based on resource requirements, affinity rules, and taints/tolerations.
- kube-controller-manager - Runs all built-in control loops: ReplicaSet controller, Node controller, Endpoints controller, and others. Each loop reconciles desired state with actual state.
- cloud-controller-manager - Bridges Kubernetes to cloud-provider APIs; not present in bare-metal kubeadm clusters.
Node Components
Worker nodes run three components: kubelet (the node agent that communicates with the API server and ensures containers are running), kube-proxy (manages iptables or IPVS rules to implement Service networking), and the container runtime (containerd is standard in modern kubeadm clusters; Docker shim was removed in Kubernetes 1.24).
In kubeadm-bootstrapped clusters, control-plane components run as static pods defined by manifest files in /etc/kubernetes/manifests/. This is critical exam knowledge - when a control-plane component is misconfigured in a task, you will almost certainly fix it by editing a file in that directory, not by running kubectl apply.
Kubeadm Installation & Cluster Bootstrapping
The CKA tests your ability to use kubeadm to initialize a control plane and join worker nodes. You will not be asked to configure kernel parameters from scratch on a live internet-connected machine, but you will need to run and troubleshoot kubeadm init and kubeadm join commands.
What You Must Be Able to Do
- Run
kubeadm initwith the correct--pod-network-cidrfor your chosen CNI plugin - Copy the admin kubeconfig to
~/.kube/configafter initialization - Install a CNI plugin (Weave, Flannel, Calico) using the manifest URL from the CNI documentation
- Retrieve the join token and run
kubeadm joinon worker nodes - Verify all nodes reach
Readystatus
Key Takeaway
The CNI plugin step is the most commonly missed. After kubeadm init succeeds, nodes stay in NotReady until a CNI is installed. The exam may present you with a cluster in exactly this state and expect you to diagnose and fix it.
Kubeadm Configuration Files
Some exam tasks provide a pre-written kubeadm-config.yaml and ask you to initialize using it. Know how to use kubeadm config print init-defaults to generate a template, and understand what fields like networking.podSubnet, kubernetesVersion, and controlPlaneEndpoint control.
RBAC: Roles, ClusterRoles, and Bindings
Role-Based Access Control is the most conceptually layered topic in Domain 1. It is also the most transferable - RBAC knowledge helps you in CKA Domain 3: Services & Networking when working with ServiceAccounts, and in troubleshooting tasks where a pod cannot access the API server.
The Four RBAC Objects
| Object | Scope | What It Does | Exam Use Case |
|---|---|---|---|
| Role | Namespace | Defines permitted verbs on specific resources within one namespace | Grant a user read-only access to pods in the dev namespace |
| ClusterRole | Cluster-wide | Same as Role but applies across all namespaces or to non-namespaced resources | Grant access to nodes, PersistentVolumes, or namespaces themselves |
| RoleBinding | Namespace | Binds a Role or ClusterRole to a subject within one namespace | Bind a ClusterRole to a ServiceAccount in a specific namespace |
| ClusterRoleBinding | Cluster-wide | Binds a ClusterRole to a subject cluster-wide | Grant a user admin rights across all namespaces |
The fastest way to create these in the exam is kubectl create role, kubectl create clusterrole, kubectl create rolebinding, and kubectl create clusterrolebinding with the --dry-run=client -o yaml flags to generate a YAML you can review before applying. Practicing this workflow until it is automatic is essential - writing RBAC manifests from scratch under time pressure is slow and error-prone.
kubectl auth can-i <verb> <resource> --as <user> -n <namespace> to confirm your policy works. This single command can save you from partial-credit losses on tasks where the policy was syntactically correct but logically wrong.
Kubeconfig Files and Context Switching
The CKA exam spans multiple clusters. Each task header tells you which cluster to use and provides the kubectl config use-context command to switch to it. Failing to switch context before starting a task is one of the most expensive mistakes a candidate can make - you may solve the task perfectly on the wrong cluster.
Kubeconfig Structure You Must Know
A kubeconfig file has three sections: clusters (API server endpoints and CA certificates), users (credentials - certificates, tokens, or exec plugins), and contexts (named combinations of a cluster and a user, optionally with a default namespace).
Exam tasks may ask you to merge two kubeconfig files, set a context's default namespace, or create a new context for a specific user. Know kubectl config set-context, kubectl config view --flatten, and the KUBECONFIG environment variable for merging multiple files.
etcd Backup and Restore
The etcd backup and restore task appears on nearly every CKA attempt and is worth practicing until you can complete it in under five minutes. It requires the etcdctl binary, specific TLS certificate paths, and careful environment setup.
Taking a Snapshot
The core command is:
ETCDCTL_API=3 etcdctl snapshot save /path/to/snapshot.db --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key
The certificate paths are those used by the etcd static pod. You can find them by running cat /etc/kubernetes/manifests/etcd.yaml and reading the volume mounts.
Restoring a Snapshot
Restoration is more involved. You run etcdctl snapshot restore to a new data directory, then update the etcd static pod manifest to point to that new directory. The kubelet detects the manifest change and restarts the etcd pod automatically. After restoration, verify the API server is healthy with kubectl get nodes.
etcd Backup Checklist
Before attempting the backup task in the exam, confirm you have every required element ready.
- Confirm
etcdctlversion withetcdctl versionand setETCDCTL_API=3 - Read the etcd manifest to extract correct cert paths - do not guess or use defaults
- Use
etcdctl snapshot statusafter saving to verify the snapshot is valid - During restore, set
--data-dirto a path that does not conflict with the existing data directory - After updating the manifest, watch
kubectl get pods -n kube-systemuntil etcd restarts cleanly
Kubernetes Version Upgrades with Kubeadm
Upgrading a cluster is a structured multi-step process. The exam typically asks you to upgrade the control plane node and then drain and upgrade a worker node - or sometimes just one of those steps.
Upgrade Sequence
- Update the
kubeadmpackage to the target version on the control plane node - Run
kubeadm upgrade planto verify the upgrade path is valid - Run
kubeadm upgrade apply v1.X.Y - Update
kubeletandkubectlpackages on the control plane node and restart kubelet - For each worker: drain the node, upgrade kubeadm/kubelet/kubectl, run
kubeadm upgrade node, restart kubelet, and uncordon
You must upgrade one minor version at a time - skipping versions is not supported. This is why understanding the relationship between the current exam Kubernetes version (verify the Linux Foundation FAQ for the exact version before you schedule) and the version presented in the task matters.
How to Schedule Your Domain 1 Preparation
Domain 1 rewards hands-on repetition more than any other domain. Reading about kubeadm does not produce the muscle memory needed to execute an etcd restore under 2-hour exam pressure. The following schedule assumes you are studying part-time and already have basic Kubernetes familiarity - if you are starting from scratch, add a week of fundamentals first.
Architecture & Kubeadm Basics
- Map every control-plane and node component without reference material
- Bootstrap a full cluster with kubeadm in a local VM or Killercoda environment at least three times
- Practice installing three different CNI plugins (Flannel, Weave, Calico)
- Locate the static pod manifests directory and edit a control-plane component flag
RBAC, Kubeconfig, and etcd
- Create every RBAC object type using imperative commands, verify with
kubectl auth can-i - Merge two kubeconfig files and set context-level default namespaces
- Perform an etcd backup and full restore from scratch five times - time yourself
- Introduce a deliberate etcd certificate error and practice diagnosing it
Cluster Upgrades and Full Domain Review
- Complete a full control-plane + worker-node upgrade cycle end-to-end
- Practice the upgrade with a deliberate mistake (wrong package version) and debug it
- Run two full timed Domain 1 mock sessions using Killer.sh or equivalent simulators
- Cross-reference CKA practice tests to identify any remaining weak spots
Because Troubleshooting is the largest domain at 30%, allocate at least equal time to CKA Domain 2: Workloads & Scheduling and CKA Domain 4: Storage after completing this three-week block - those domains feed directly into Troubleshooting scenarios.
Exam Mechanics That Affect Domain 1 Tasks
The CKA costs $445 and includes one free retake - two total exam attempts - plus two Killer.sh simulator sessions. Your certification is valid for two years if earned after April 1, 2024, and renewal requires retaking the exam. Understanding the investment helps you approach preparation seriously, but also without excessive anxiety. For a full breakdown of what you get for the fee, see the CKA Certification Cost 2026: Complete Pricing Breakdown.
Partial credit is available per task. This means that on a kubeadm installation task with multiple steps, completing the control-plane initialization but failing to join a worker node still earns you partial marks. Never abandon a task midway - always complete as many steps as you can before moving on.
kubectl config use-context command from each task header and run it before typing a single other command. Verify with kubectl config current-context. Domain 1 tasks frequently involve multi-node clusters that differ from the cluster used in the previous task.
The exam environment is a browser-based Linux terminal. You cannot copy commands from an external cheat sheet - only documentation inside approved URLs is accessible. Before exam day, spend time navigating kubernetes.io specifically to the kubeadm reference, the RBAC documentation, and the etcd backup-and-restore task guide in the Kubernetes docs. Bookmark these pages using the browser's bookmarks feature if the proctoring system allows it in the exam VM.
To understand how Domain 1 difficulty compares to the overall exam experience, the How Hard Is the CKA Exam? Complete Difficulty Guide 2026 provides detailed context on what candidates consistently report as the hardest and most manageable parts of the two-hour session. And when you are ready to build a full multi-domain study plan, the CKA Study Guide 2026: How to Pass on Your First Attempt covers all five domains in sequence with prioritization guidance. You can also reinforce your Domain 1 knowledge by working through the CKA practice test questions that simulate real task scenarios.
Frequently Asked Questions
The CKA has approximately 15-20 performance-based tasks total, and Domain 1 carries 25% of the overall score. In practice, that translates to roughly 4-5 tasks, though the exact count varies by exam instance. The Linux Foundation does not publish a fixed task count per domain.
Not verbatim - the Kubernetes documentation and etcd documentation are accessible inside the exam VM. However, you should know the structure of the commands and which flags are required so you can find and adapt the reference material quickly. Candidates who rely entirely on docs without prior practice routinely run out of time.
The Linux Foundation states the CKA environment aligns with the latest Kubernetes minor release within approximately 4-8 weeks. The FAQ currently lists Kubernetes v1.35, while the product page lists v1.34 - these figures may be out of sync. Always check the official Linux Foundation FAQ page directly before you schedule your exam.
Yes, typically. Managed services abstract away the control plane entirely. You will never interact with etcd, static pod manifests, or kubeadm in a managed environment. Candidates coming exclusively from managed-cluster backgrounds should allocate additional preparation time to all of Domain 1's installation and configuration topics.
Yes. The Kubernetes documentation is an approved resource inside the exam VM. The RBAC reference and API documentation for Role, ClusterRole, RoleBinding, and ClusterRoleBinding are all accessible. That said, using imperative kubectl create role commands with --dry-run=client -o yaml is almost always faster than copying from docs and editing manually.