CKA Concepts: Understand, Apply, Verify
Build the knowledge to explain what Kubernetes is doing, make the requested change, and prove that it works. Read a domain here, use the matching section in Playbook, then attempt an exercise before opening its solution.
This guide follows the five published CKA domains. The weights below and Kubernetes v1.35 exam version were checked on 14 September 2026 against the Linux Foundation CKA overview ↗. Check that page again before your exam; versions change. In Kubernetes documentation, select the version matching your environment.
| Domain | Weight | What you should be able to do |
|---|---|---|
| Cluster Architecture, Installation & Configuration | 25% | Build, maintain, extend, and control access to a cluster. |
| Workloads & Scheduling | 15% | Run reliable applications and control their placement and scale. |
| Services & Networking | 20% | Connect workloads and diagnose traffic paths. |
| Storage | 10% | Provision, attach, and preserve application data. |
| Troubleshooting | 30% | Find the failing layer, repair it, and verify recovery. |
These are original practice materials based on public objectives. The goal is exam-relevant capability: completing a precise task under time pressure and checking its observable outcome.
1. Cluster Architecture, Installation & Configuration · 25%
Know which component owns the next step
A request reaches the API server, which validates it and stores cluster state in etcd. Controllers reconcile desired and observed state. The scheduler assigns unscheduled Pods to suitable nodes. Each node's kubelet asks its container runtime to run those Pods. Service traffic is implemented by kube-proxy or a replacement supplied by the networking implementation.
Remember: the scheduler chooses a node; the kubelet runs the Pod. A Pod with no node assignment and a Pod that crashes after assignment need different investigations. Kubernetes components ↗
Access: identity, permission, scope
A kubeconfig selects a cluster, a user identity, and optionally a namespace through a context. Authentication establishes who you are; RBAC decides which API actions that identity may perform.
A Role grants permissions within a namespace. A ClusterRole can describe namespaced or cluster-scoped permissions. A RoleBinding grants permissions in its own namespace, even when it refers to a ClusterRole. A ClusterRoleBinding grants the referenced ClusterRole across the cluster. ServiceAccounts are identities for workloads.
Remember: a role describes permissions; a binding gives them to a subject. Verify both an allowed action and an action that should remain denied. RBAC ↗ · Kubeconfig ↗
Installation, lifecycle, and availability
Before kubeadm init, prepare the host: supported OS and packages, unique node identity, network reachability and required ports, a compatible CRI runtime, matching cgroup configuration, and the documented swap configuration. Choose non-overlapping Pod and Service networks. Initialize the first control-plane node, configure administrative access, install a compatible Pod network, and join remaining nodes with the generated join instructions. Validate node readiness and cross-node connectivity. Install kubeadm ↗ · Create a cluster ↗
For upgrades, follow the target version's supported sequence and version-skew rules. Upgrade the first control-plane node, additional control-plane nodes, then workers. Drain where required, update kubelet and kubectl, restart kubelet, verify, and uncordon. cordon blocks new scheduling; drain also evicts eligible workloads. PodDisruptionBudgets can prevent a drain. Kubeadm upgrades ↗ · Drain a node ↗
High availability needs redundant control-plane components behind a stable API endpoint and a healthy etcd quorum. Know stacked etcd versus external etcd. Three healthy etcd members can tolerate one member failure; extra API servers do not compensate for lost etcd quorum. HA topologies ↗
Certificates have different owners. Inspect which certificate, identity, or trust chain is failing before renewing anything. Kubeadm certificate renewal is not a general fix for a kubelet authentication problem. Practise backup and recovery on a disposable cluster using its actual etcd topology and tool versions. Certificate management ↗ · Operating etcd ↗
Installation tools and extension points
| Tool or interface | Purpose | Useful distinction |
|---|---|---|
| Helm | Installs a chart as a versioned release using values. | Chart version and container image version are separate. |
| Kustomize | Builds manifests from a base plus overlays and patches. | Inspect rendered output before applying it. |
| CRI | Connects the kubelet to a container runtime. | Runtime failures can prevent containers from starting. |
| CNI | Provides Pod networking through a network implementation. | Installing Kubernetes alone does not install a complete Pod network. |
| CSI | Connects Kubernetes to storage drivers. | A StorageClass needs a working provisioner. |
| CRD and operator | Adds an API type; a controller reconciles instances of that type. | Creating a custom resource does not install its controller. |
References: Helm ↗ · Kustomize ↗ · CRI ↗ · Network plugins ↗ · CSI ↗ · CRDs ↗ · Operators ↗
Practise: grant a ServiceAccount read-only Pod access in one namespace; render a Kustomize overlay; install and roll back a Helm release. Prove it: check effective permissions, resulting resources, and release history. Then rehearse installation, upgrades, and HA on a dedicated kubeadm cluster.
2. Workloads & Scheduling · 15%
Choose a controller and understand recovery
A Deployment manages interchangeable application replicas through ReplicaSets. A StatefulSet provides stable Pod identities and storage associations. A DaemonSet runs a Pod on each eligible node. A Job completes work; a CronJob schedules Jobs.
Controllers replace failed Pods to restore desired state. They cannot fix a bad image, missing configuration, or an application defect. Deployment template changes trigger a rollout; changing a Service does not. Rollback restores an earlier Pod template, not your database or every related resource. Deployments ↗ · Workload controllers ↗
Health, configuration, and scale
Readiness controls whether a Pod is a ready Service endpoint. Liveness can restart an unhealthy container. A startup probe allows initialization to finish before liveness and readiness probes begin. A running Pod can still be unready. Probes ↗
ConfigMaps hold ordinary configuration; Secrets hold sensitive values. Base64 encoding is not encryption. Both can supply environment variables or mounted files. Environment variables do not refresh in a running container when the source changes; projected files update eventually, except subPath mounts. The application must also reload changed files. ConfigMaps ↗ · Secrets ↗
The HPA changes replica count using observed metrics. CPU utilization targets depend on CPU requests, and resource metrics require a metrics provider such as Metrics Server. <unknown> metrics are a dependency to investigate, not evidence that scaling works. Horizontal Pod autoscaling ↗
Admission is different from scheduling
Admission may reject or modify a request before a Pod is stored. ResourceQuota, LimitRange, and Pod Security Admission can affect acceptance. A successfully created Pod may then remain Pending because no node satisfies its scheduling constraints. Admission controllers ↗ · ResourceQuota ↗ · LimitRange ↗
Requests reserve capacity for scheduling; limits constrain runtime use. CPU can be throttled; exceeding a memory limit can cause an OOM kill. nodeSelector and required node affinity restrict placement; preferred affinity expresses a preference. A toleration permits scheduling onto a matching tainted node but does not attract a Pod there or guarantee placement.
Remember: requests fit; affinity selects; tolerations permit. Read events before changing constraints. Resources ↗ · Node affinity ↗ · Taints and tolerations ↗
Practise: roll out an image, recover a failed rollout, repair a Pending Pod, and configure an HPA. Prove it: inspect the Pod template, readiness, placement, replica count, and metrics—not just whether an apply command succeeded.
3. Services & Networking · 20%
Follow the traffic path
Containers in a Pod share a network namespace and can communicate over localhost. Pod-to-Pod traffic depends on the cluster network. A Service supplies a stable destination for a changing set of backends, typically selected by labels and represented in EndpointSlices.
Remember: selector → ready endpoint → listening port. A Service's port is the client-facing port; targetPort directs traffic to the backend. A Pod's containerPort declaration does not make its application listen on that port. Services ↗ · EndpointSlices ↗ · Cluster networking ↗
| Service type | Use it for |
|---|---|
| ClusterIP | A stable address inside the cluster. |
| NodePort | A port exposed on nodes, subject to node networking and reachability. |
| LoadBalancer | An external load balancer supplied by a supported implementation. |
A pending external address can mean no load-balancer implementation is installed. Creating the resource alone does not provide one.
Control allowed connections
NetworkPolicies select Pods and allow particular ingress or egress traffic. Enforcement requires a supporting network implementation. Policies are additive: traffic allowed by any applicable policy is allowed. If both ends are isolated, source egress and destination ingress must both allow the connection.
Within one peer, namespaceSelector plus podSelector means both must match. Separate list entries mean either may match. An empty podSelector selects all Pods in that namespace. DNS may need an explicit egress allowance when egress is restricted. NetworkPolicy ↗
Route external traffic and resolve names
An Ingress describes HTTP(S) host/path routing and requires an Ingress controller. Gateway API separates infrastructure from routing: GatewayClass identifies an implementation, Gateway configures listeners, and HTTPRoute attaches routing rules to them. Check route acceptance, reference resolution, and Gateway readiness before testing traffic. Cross-namespace references may need permission through a ReferenceGrant. Ingress ↗ · Gateway API ↗ · HTTP routing guide ↗
CoreDNS typically provides cluster DNS. Short Service names resolve relative to a Pod's namespace; service.namespace identifies a Service in another namespace. Diagnose DNS separately from application reachability: successful name resolution does not prove that a Service has healthy backends. DNS for Services and Pods ↗ · Debug DNS ↗
Practise: repair a Service, allow one client through policy, configure an HTTPRoute, and trace a DNS failure. Prove it: test from the intended client and also test a client that should remain blocked.
4. Storage · 10%
Separate the request from the storage
A PersistentVolumeClaim (PVC) requests storage in a namespace. A PersistentVolume (PV) represents storage available to the cluster. A StorageClass describes provisioning behavior. Dynamic provisioning creates a volume through a driver; static provisioning starts with an existing PV. Binding must satisfy capacity, class, access mode, and other selection constraints. Persistent volumes ↗ · Dynamic provisioning ↗
ReadWriteOnce means read-write mounting from one node, potentially by multiple Pods on that node. ReadWriteOncePod restricts access to one Pod when supported by the CSI driver. ReadWriteMany supports multiple nodes. Choose a mode the storage backend supports.
A reclaim policy applies after a claim is released: Retain keeps the volume for manual recovery; Delete removes the volume and, for supporting drivers, its backing storage. Do not clear a retained PV's claim reference unless a deliberate data-recovery/reuse procedure calls for it.
Binding and mounting are separate steps
WaitForFirstConsumer delays binding/provisioning until scheduling a consuming Pod can account for storage topology. Pending can be expected before a consumer exists; persistent Pending still needs event inspection. A bound claim can fail later during attach or mount. StorageClasses ↗
emptyDir lives with a Pod, surviving container restarts but not Pod removal. A hostPath exposes a path on one node and is not portable shared storage. Local PVs require node affinity. For persistent application data, verify the actual backing storage and driver. Volumes ↗ · Local volumes ↗
Remember: class provisions; claim binds; Pod mounts. Practise: mount a claim into a Deployment. Prove it: write a marker, replace the managed Pod, and read the marker again from the same claim.
5. Troubleshooting · 30%
Investigate the first failing layer
Use a repeatable loop: observe → narrow → repair → verify. Start with the requested outcome and compare it with current state. Change the smallest thing that explains the evidence.
| Symptom | First useful evidence | Common next layer |
|---|---|---|
| API request fails | Context, exact error, API endpoint reachability | Credentials, trust, RBAC, or API server |
| Node NotReady | Node conditions and events | Kubelet, runtime, disk, or network plugin |
| Pod Pending | Node assignment and scheduling events | Requests, affinity, taints, or storage |
| Container waiting or restarting | Describe output, current and previous logs | Image, command, configuration, probes, or memory |
| Service unreachable | Selector, EndpointSlices, client test | Readiness, ports, policy, DNS, or network dataplane |
| Metrics missing | Metrics API and provider health | Collection pipeline and resource requests |
Pod events explain orchestration failures; container logs explain application behavior. kubectl logs --previous retrieves the previous container instance when available. kubectl top shows recent resource metrics, not historical monitoring. Debug applications ↗ · Resource monitoring ↗
If the API is unavailable, inspect the host directly. Kubeadm control-plane components commonly run as static Pods; kubelet watches their manifest directory. Use runtime tools such as crictl and host logs to inspect components without relying on a healthy API. Keep manifest backups outside the watched directory. Debug clusters ↗ · Static Pods ↗ · crictl ↗
Practise: diagnose before opening a solution, write down your evidence, and repair only the identified cause. Prove it: repeat the original failed operation, confirm health remains stable, and check that you did not remove a required constraint.
Turn understanding into exam practice
Use Playbook for worked tasks and verification commands, then Exercises for independent attempts. After each attempt, answer: What failed? Which evidence identified it? Why did the change work? What proves the task is complete?
Practise looking up one exact field or procedure in the official docs instead of copying an entire unrelated example. Review the exam's allowed resources ↗ before your sitting; a useful study link is not automatically an allowed exam resource.
All 16 CKA exercises have an on-demand browser lab. Start with A healthy app. A broken Service., or choose an exercise in the Exercises tab. Each lab supplies its task files and a disposable three-node kind cluster; use the stated node-access commands for host-level work. Broader installation, upgrade, and HA practice still needs a suitable kubeadm topology beyond these exercises.