Overview
Domain 1 is about the cluster itself. You must be able to grant least-privilege access with Roles and bindings, prepare a Linux node so kubeadm can install Kubernetes, bootstrap and join nodes, upgrade a cluster one minor version at a time, back up and restore etcd, and reason about a highly available control plane. It also covers installing add-ons with Helm and Kustomize, knowing what the Container Runtime Interface (CRI), Container Network Interface (CNI) and Container Storage Interface (CSI) each plug into, and working with Custom Resource Definitions (CRDs) and operators.
Every task here is done at a terminal on a live cluster, often after you SSH to a control plane node. The domain underpins the rest of the exam: Troubleshooting assumes you know where static Pod manifests, kubelet configuration and certificates live, and Services and Networking assumes you know a CNI plugin must be installed before Pods can talk.
How it's tested
Domain 1 tasks are instructions, not questions: create a Role and bind it to a ServiceAccount, upgrade the control plane to a stated patch version, save an etcd snapshot to a given path, install a chart into a namespace. Grading checks the resulting cluster state, so precision about names, namespaces, versions and file paths decides the score.
-
Exact-state build
Create RBAC objects, a Helm release or a Kustomize overlay with specific names and namespaces; the grader inspects those objects, so a typo or wrong namespace fails the task.
-
Ordered node procedure
Upgrade or join a node following kubeadm's sequence: package, kubeadm command, drain, kubelet, restart, uncordon. Skipping or reordering a step leaves the node at the old version or unschedulable.
-
Control plane file surgery
Take or restore an etcd snapshot, or edit a static Pod manifest in /etc/kubernetes/manifests, using certificate paths you find yourself rather than ones given to you.
A task says: back up etcd to /opt/backup/etcd.db. You are not told the certificate paths. The reliable move is to read them from /etc/kubernetes/manifests/etcd.yaml (--trusted-ca-file, --cert-file, --key-file, --listen-client-urls) and pass them to etcdctl snapshot save with --cacert, --cert, --key and --endpoints. Guessing paths or omitting TLS flags produces a connection error and no file.
Competencies 8
Official competencies from the Linux Foundation outline, in outline order.
1.1 Manage role based access control (RBAC)Roles, ClusterRoles, bindings and ServiceAccounts for least privilege.
- What it means
- RBAC grants permissions as verbs (get, list, create, delete) on resources, collected in a Role (one namespace) or ClusterRole (cluster-wide or reusable), and attached to users, groups or ServiceAccounts by a RoleBinding or ClusterRoleBinding.
- What to understand
- Permissions are purely additive; there is no deny rule. A RoleBinding can reference a ClusterRole, which grants that ClusterRole's rules only inside the binding's namespace. Verify with kubectl auth can-i list pods --as=system:serviceaccount:dev:builder -n dev.
- How it shows up
- You are asked to let a ServiceAccount in one namespace list and watch Deployments only there, then prove it works.
- Common confusion
- Using a ClusterRoleBinding when the task says one namespace, which silently grants access to every namespace.
1.2 Prepare underlying infrastructure for installing a Kubernetes clusterNode prerequisites before kubeadm will succeed.
- What it means
- Before kubeadm init or join, each node needs a CRI-compatible container runtime such as containerd, the kubeadm, kubelet and kubectl packages, the overlay and br_netfilter kernel modules, and IP forwarding enabled.
- What to understand
- Know the sysctls (net.ipv4.ip_forward=1 and net.bridge.bridge-nf-call-iptables=1), that swap must be off unless the kubelet is explicitly configured for it, and that the runtime and kubelet must use the same cgroup driver (systemd by default with kubeadm).
- How it shows up
- A node fails kubeadm's preflight checks and you must fix the prerequisite named in the error, then rerun the join.
- Common confusion
- Installing the runtime but leaving containerd on the cgroupfs driver, so the kubelet starts and then Pods restart unpredictably.
1.3 Create and manage Kubernetes clusters using kubeadmBootstrapping control planes and joining nodes with kubeadm.
- What it means
- kubeadm init creates the certificates under /etc/kubernetes/pki, writes static Pod manifests for the API server, controller manager, scheduler and etcd, and prints a join command; kubeadm join adds workers or extra control plane nodes.
- What to understand
- Bootstrap tokens expire after 24 hours by default, so regenerate the full command with kubeadm token create --print-join-command. Pods stay Pending and nodes NotReady until you install a CNI plugin after init.
- How it shows up
- You are given a worker that is not part of the cluster and must join it, which usually means generating a fresh token on the control plane first.
- Common confusion
- Expecting nodes to become Ready straight after kubeadm init, when the missing piece is the Pod network add-on.
1.4 Manage the lifecycle of Kubernetes clustersUpgrades, node maintenance and etcd backup and restore.
- What it means
- Lifecycle work means upgrading with kubeadm one minor version at a time, draining and uncordoning nodes for maintenance, and protecting cluster state with etcd snapshots.
- What to understand
- The upgrade order is: upgrade the kubeadm package, run kubeadm upgrade plan and kubeadm upgrade apply v1.x.y on the first control plane node (kubeadm upgrade node on the others and on workers), drain, upgrade kubelet and kubectl, run systemctl daemon-reload and restart kubelet, then uncordon. For etcd, snapshot with etcdctl snapshot save and restore with etcdutl snapshot restore into a new data directory.
- How it shows up
- A task asks you to upgrade only the control plane node to an exact patch version and leave workers alone, or to restore a snapshot so a deleted Deployment returns.
- Common confusion
- Treating kubeadm upgrade apply as the whole job; the kubelet version shown by kubectl get nodes only changes after the kubelet package is upgraded and restarted.
1.5 Implement and configure a highly-available control planeMultiple API servers behind a load balancer, with etcd quorum.
- What it means
- An HA control plane runs three or more control plane nodes behind a load balancer address set with kubeadm init --control-plane-endpoint, so losing one node does not take down the API.
- What to understand
- Know stacked etcd (one etcd member on each control plane node) versus external etcd (a separate etcd cluster). etcd needs a majority, floor(n/2)+1, so three members tolerate one failure and five tolerate two. Extra control plane nodes join with kubeadm join --control-plane after certificates are shared with --upload-certs.
- How it shows up
- A scenario asks how many etcd members can fail, or which endpoint kubeconfig files should point to in an HA design.
- Common confusion
- Adding a fourth etcd member for resilience; four still tolerates only one failure, the same as three.
1.6 Use Helm and Kustomize to install cluster componentsInstalling add-ons from charts and overlays.
- What it means
- Helm installs a versioned chart as a named release with values; Kustomize builds manifests from a base plus overlays described in kustomization.yaml and is built into kubectl.
- What to understand
- Core commands: helm repo add, helm repo update, helm install NAME CHART -n NS --create-namespace --set key=value, helm upgrade --install, helm list -A and helm template. For Kustomize, kubectl kustomize DIR renders and kubectl apply -k DIR applies.
- How it shows up
- You are told to install a chart at a specific version into a namespace with one value overridden, or to apply an overlay that changes a namespace or image tag.
- Common confusion
- Running kubectl apply -f on a directory that holds a kustomization.yaml; -f ignores the overlay, and only -k builds it.
1.7 Understand extension interfaces (CNI, CSI, CRI, etc.)Where the runtime, network and storage plugins attach.
- What it means
- The kubelet talks to the container runtime through CRI, networking is provided by a CNI plugin, and storage drivers plug in through CSI, so Kubernetes core ships none of these implementations.
- What to understand
- Know the locations: CNI binaries in /opt/cni/bin and configuration in /etc/cni/net.d; the runtime socket such as unix:///run/containerd/containerd.sock is used by both the kubelet and crictl; CSI drivers register as CSIDriver objects and run as Pods. Dockershim was removed in v1.24, so Docker Engine is not a CRI runtime without cri-dockerd.
- How it shows up
- A scenario shows a symptom such as nodes NotReady with a 'cni plugin not initialized' message and asks which interface is missing.
- Common confusion
- Using docker ps to inspect containers on a containerd node; the right tool is crictl.
1.8 Understand CRDs, install and configure operatorsExtending the API with custom resources and controllers.
- What it means
- A CustomResourceDefinition adds a new resource type to the API server; an operator is a controller, usually deployed as a Deployment, that watches those custom resources and reconciles real objects to match them.
- What to understand
- Install the CRD before creating any custom resource of that kind, and remember that a CRD on its own stores objects but does nothing until a controller acts on them. Use kubectl get crd, kubectl api-resources and kubectl explain KIND.spec to discover fields.
- How it shows up
- You install an operator from manifests or a Helm chart, then create a custom resource with given spec values and confirm the operator created the expected objects.
- Common confusion
- Assuming creating the custom resource triggers work by itself; if the operator Pod is not running, nothing reconciles.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Role versus ClusterRole scope
A Role grants permissions inside one namespace, while a ClusterRole holds rules that can apply cluster-wide or be reused in many namespaces.
- Remember
- The binding decides the scope: a RoleBinding to a ClusterRole limits it to the binding's namespace, and only a ClusterRoleBinding grants it everywhere.
- Tested as
- Tasks ask for namespace-limited access to a common rule set, which is a ClusterRole plus RoleBinding.
- Trap
- Creating a ClusterRoleBinding because the referenced object is a ClusterRole.
-
kubectl auth can-i
This command asks the API server whether a subject may perform a verb on a resource, and --as lets you impersonate any user or ServiceAccount.
- Remember
- ServiceAccounts are impersonated as system:serviceaccount:NAMESPACE:NAME, and -n sets the namespace being tested.
- Tested as
- It is the fastest way to verify your own RBAC work before moving to the next task.
- Trap
- Testing as the ServiceAccount name alone, which checks a user that does not exist and always returns no.
-
kubeadm upgrade sequence
kubeadm upgrades the control plane components, while the kubelet on every node is upgraded separately through the package manager.
- Remember
- kubeadm package first, then upgrade apply or upgrade node, then drain, kubelet and kubectl packages, daemon-reload, restart kubelet, and uncordon.
- Tested as
- Upgrade tasks are graded on node versions and schedulability, so every step counts.
- Trap
- Forgetting to uncordon, which leaves a node at the correct version but SchedulingDisabled.
-
One minor version at a time
Kubernetes supports upgrading the control plane only from one minor release to the next, such as 1.34 to 1.35.
- Remember
- Since the move to pkgs.k8s.io, each minor version has its own package repository, so a minor upgrade needs the repository entry changed first.
- Tested as
- A task naming a target version expects you to find the matching package version with apt-cache madison or similar.
- Trap
- Trying to install a newer kubeadm without changing the repository and concluding the version does not exist.
-
etcd snapshot save
etcdctl snapshot save writes a consistent point-in-time copy of the etcd keyspace, which is the whole state of the cluster.
- Remember
- Pass --endpoints, --cacert, --cert and --key, and read the values from the etcd static Pod manifest.
- Tested as
- Backup tasks give only a destination path and expect you to discover the TLS material yourself.
- Trap
- Running etcdctl with no certificate flags against a TLS-only endpoint and getting a deadline-exceeded error.
-
etcd snapshot restore
Restoring writes the snapshot into a new data directory, so etcd must then be told to use that directory.
- Remember
- Run etcdutl snapshot restore FILE --data-dir NEW_DIR, then change the hostPath volume for etcd-data in /etc/kubernetes/manifests/etcd.yaml to NEW_DIR.
- Tested as
- The grader checks that the restored objects are visible through the API afterwards.
- Trap
- Restoring into the live data directory or never editing the manifest, so etcd keeps serving the old state.
-
Static Pods
The kubelet runs any manifest placed in its staticPodPath, by default /etc/kubernetes/manifests, without the API server or scheduler being involved.
- Remember
- kubeadm control plane components are static Pods, so editing their manifest makes the kubelet recreate them automatically.
- Tested as
- Changing an API server flag or etcd data directory is done by editing these files, not with kubectl edit.
- Trap
- Editing the mirror Pod with kubectl, which the kubelet overwrites from the file on disk.
-
etcd quorum
etcd commits a write only when a majority of members agree, which protects consistency during network splits.
- Remember
- Quorum is floor(n/2)+1: three members tolerate one failure, five tolerate two, and even sizes add no tolerance.
- Tested as
- HA design questions ask about safe member counts and failure tolerance.
- Trap
- Choosing two or four control plane nodes and assuming they add resilience.
-
Bootstrap tokens and join
kubeadm join authenticates a new node with a bootstrap token and verifies the cluster by the CA certificate hash.
- Remember
- Tokens last 24 hours by default; kubeadm token create --print-join-command prints a fresh, complete command.
- Tested as
- Join tasks often start after the original token has expired.
- Trap
- Copying an old join command from shell history and debugging the resulting authentication error.
-
Helm release commands
A Helm release is a named, versioned installation of a chart in a namespace, tracked so it can be upgraded or rolled back.
- Remember
- helm install NAME REPO/CHART --version X -n NS --create-namespace --set key=value; helm list -A shows every release.
- Tested as
- Install tasks specify release name, namespace, chart version and a value to override.
- Trap
- Omitting -n, which installs the release into the current context's default namespace.
-
Kustomize overlays
Kustomize patches a base set of manifests with an overlay instead of using templates, and kubectl includes it.
- Remember
- kubectl kustomize DIR shows the rendered output and kubectl apply -k DIR applies it.
- Tested as
- Tasks ask you to apply an overlay or add a namespace, label or image change in kustomization.yaml.
- Trap
- Using kubectl apply -f on the overlay directory, which skips the build step.
-
CRI, CNI and CSI
These are the plugin contracts for container runtimes, Pod networking and storage, so each can be swapped without changing Kubernetes core.
- Remember
- CNI config lives in /etc/cni/net.d, and crictl talks to the CRI socket; CSI drivers appear as CSIDriver objects.
- Tested as
- Questions describe a symptom and ask which interface or component is responsible.
- Trap
- Attributing a missing Pod IP to CSI or a volume mount failure to CNI.
-
CRDs and operators
A CRD defines a new API kind; an operator is the controller that turns custom resources into running objects.
- Remember
- Install CRD, then controller, then the custom resource; check kubectl get crd and the operator Pod's logs when nothing happens.
- Tested as
- Tasks install an operator and create a resource with given spec fields.
- Trap
- Creating the custom resource before its CRD exists, which fails with 'no matches for kind'.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Role vs. ClusterRole vs. RoleBinding vs. ClusterRoleBinding
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Role | A set of rules that exists in one namespace | Can only grant access inside its own namespace | Trying to reference a Role from a ClusterRoleBinding, which is not allowed |
| ClusterRole | A set of rules with no namespace | Can cover cluster-scoped resources such as nodes, or be reused per namespace | Assuming it always grants cluster-wide access |
| RoleBinding | Attaches a Role or ClusterRole to subjects in one namespace | Scope is always the binding's namespace | Forgetting -n, so the binding lands in default |
| ClusterRoleBinding | Attaches a ClusterRole to subjects across all namespaces | Grants access everywhere, including cluster-scoped resources | Using it for a one-namespace requirement and over-granting |
kubeadm upgrade apply vs. kubeadm upgrade node vs. kubelet upgrade
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| kubeadm upgrade apply v1.x.y | Upgrades the control plane on the first control plane node | Run once per cluster, after kubeadm upgrade plan | Running it on every node |
| kubeadm upgrade node | Updates local control plane manifests or kubelet configuration on the remaining nodes | Used on additional control plane nodes and all workers | Skipping it on workers and only upgrading packages |
| kubelet package upgrade and restart | Replaces the node agent binary and restarts it | Only this changes the VERSION column in kubectl get nodes | Upgrading the package without systemctl daemon-reload and restart kubelet |
Stacked etcd vs. external etcd
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Stacked etcd | Each control plane node also runs an etcd member, the kubeadm default | Fewer machines, but losing a node removes both an API server and an etcd member | Forgetting that control plane count then sets etcd quorum |
| External etcd | etcd runs on its own hosts, separate from the API servers | Failures are decoupled, at the cost of more hosts and certificate setup | Assuming kubeadm creates the external etcd cluster for you |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Working on the wrong cluster or host
- What candidates pick
- Starting the task immediately in the terminal left over from the previous task.
- Why it looks right
- The prompt is ready and the commands look familiar, so switching feels like wasted time.
- Why it's wrong
- Each task names a context or host; objects created elsewhere are invisible to the grader and score zero.
Clue to watch for The task header line that gives the kubectl config use-context command or the ssh target.
-
Over-granting with a ClusterRoleBinding
- What candidates pick
- Binding the required ClusterRole with a ClusterRoleBinding.
- Why it looks right
- The referenced object is a ClusterRole, so a ClusterRoleBinding seems to match.
- Why it's wrong
- It grants the rules in every namespace, and graders often check that access is denied elsewhere.
Clue to watch for Wording such as 'only in the namespace dev'.
-
Partial node upgrade
- What candidates pick
- Running kubeadm upgrade apply and declaring the node upgraded.
- Why it looks right
- kubeadm reports success and the control plane Pods restart on the new version.
- Why it's wrong
- kubectl get nodes reports the kubelet version, which is unchanged until the kubelet package is upgraded and restarted.
Clue to watch for A requirement that the node itself, not only the control plane, show the target version.
-
Restore without the manifest edit
- What candidates pick
- Running etcdutl snapshot restore and moving on.
- Why it looks right
- The command succeeds and a new directory appears.
- Why it's wrong
- The etcd static Pod still mounts the old data directory, so the cluster state does not change.
Clue to watch for The task asks for the cluster to reflect the restored state, which needs the hostPath in etcd.yaml updated.
-
Expired join token
- What candidates pick
- Pasting the join command printed during kubeadm init.
- Why it looks right
- It is the command the cluster itself produced.
- Why it's wrong
- Bootstrap tokens expire after 24 hours by default, so the join is rejected.
Clue to watch for The cluster has existed for some time before the task, or the error mentions an invalid token.
-
Helm release in the wrong namespace
- What candidates pick
- Running helm install without -n.
- Why it looks right
- Helm installs successfully and helm list shows the release.
- Why it's wrong
- The release goes into the current context's namespace and the grader looks in the requested one.
Clue to watch for Any task that names a namespace for the release.
-
Expecting HA from an even member count
- What candidates pick
- Choosing four control plane nodes to tolerate two failures.
- Why it looks right
- More nodes sounds like more resilience.
- Why it's wrong
- Four etcd members need three for quorum, so they still tolerate only one failure.
Clue to watch for Questions about failure tolerance or the number of members that may be lost.
Answer framework
Use this sequence on any cluster-building task so state ends up exactly where the grader checks.
- Switch to the context or SSH to the host named in the task header before typing anything else, and confirm with kubectl config current-context or hostname.
- Read the task for exact names, namespaces, versions and file paths, and note any word that limits scope, such as only, exactly or in namespace.
- Discover facts from the cluster rather than guessing: certificate paths from etcd.yaml, versions from apt-cache madison, fields from kubectl explain.
- Execute the documented sequence in order, using --dry-run=client -o yaml for RBAC and resource objects so you can check them before applying.
- Verify the end state the way a grader would, with kubectl auth can-i, kubectl get nodes, helm list -n, or kubectl get on restored objects.
Practice question
Want more like this? The CKA practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with RBAC, because it is quick to practise, appears in many forms and builds the habit of verifying with kubectl auth can-i. Then build a cluster from scratch with kubeadm on two or three virtual machines: prepare the nodes, run init, install a CNI plugin and join a worker. Doing this at least twice teaches you where every file lives, which pays off again in Troubleshooting.
High-priority skills are the upgrade sequence and etcd backup and restore. Write each procedure from memory, then check it against the kubernetes.io task pages you can open during the exam, and practise finding the right page quickly. Learn to read certificate paths from etcd.yaml instead of memorising them, because exam clusters may differ from your lab.
Candidates commonly underestimate Helm, Kustomize, CRDs and the HA material because they look like light reading. They are quick tasks only if the commands are automatic, so drill helm install with --version, -n and --set, and kubectl apply -k, until you no longer need help output.
Afterwards, run timed practice where each task begins with switching context, and finish every task with an explicit verification command.
FAQ
How hard is CKA Domain 1?
It is less about tricky concepts than long procedures done exactly right. Candidates from managed Kubernetes find it hardest because kubeadm, etcd and static Pods are new to them.
How much of the CKA exam is Cluster Architecture, Installation and Configuration?
The Linux Foundation weights it at 25%, second only to Troubleshooting at 30%. Expect several tasks, some of them long.
Do I need to memorise etcdctl and kubeadm commands?
You may use the kubernetes.io documentation during the exam, and it contains both procedures. Know them well enough that you only check flags, because searching from scratch costs too much time.
Is etcdctl snapshot restore still valid?
etcd has deprecated restore through etcdctl in favour of etcdutl snapshot restore, and the kubernetes.io etcd page reflects that. Use whichever tool the exam node provides, and remember the restore only takes effect once the etcd manifest points at the new data directory.
Will I have to build a whole HA cluster?
The competency is to implement and configure a highly available control plane, so expect to understand the kubeadm options and etcd quorum. A full multi-node HA build is long, so practise at least one in a lab.
What is the difference between Helm and Kustomize for the exam?
Helm installs a packaged chart as a release with values, while Kustomize patches plain manifests with overlays applied through kubectl apply -k. Read which tool the task names and use it.
How does this domain connect to Troubleshooting?
The same files you use to install a cluster, such as static Pod manifests, kubelet configuration and certificates, are where you look when a component breaks. Learning them here makes Troubleshooting faster.
Test your Domain 1 knowledge
Practise RBAC, kubeadm upgrades and etcd backup and restore as timed tasks, and check that you finish each one with a verification command.