CKA — Certified Kubernetes Administrator

The CKA asks one unglamorous question: can you actually run a Kubernetes cluster? Not describe one, not architect one — run it. Build it with kubeadm, upgrade it without dropping workloads, back up etcd, work out why a Pod is stuck in Pending, fix a Service that resolves but never answers. It is performance-based, like the CNPE, and it is the ground the whole platform-engineering discipline stands on. Below: what it is, whether a platform engineer should bother, the official domains and weights straight from the CNCF curriculum, and how to prepare with the lessons already on this site.

What the CKA is, and who it is for

☺ Like you’re 10: It’s a two-hour practical test where you fix and build real clusters on a real computer, not a quiz.

The Certified Kubernetes Administrator is the CNCF and Linux Foundation’s flagship credential for people who operate Kubernetes. It has existed since 2017, it is one of the most widely held cloud native certifications, and it is deliberately narrow: the cluster itself — control plane, nodes, networking, storage, and everything that goes wrong with them — not the applications on top or the developer experience wrapped around them.

Performance-based, not multiple choice

There is no bank of A/B/C/D questions. You are dropped into a browser-based Linux environment with a terminal and several pre-built clusters, and handed tasks: “On cluster ek8s, drain node node-1 and upgrade it to v1.35.” Grading is on the end state of the cluster, not on how you got there — which has two consequences. Speed is a real skill; people fail on the clock far more often than on knowledge. And verification is part of the job: an answer you didn’t confirm with kubectl get is an answer you may not have given.

Who should sit it

It targets cluster administrators, SREs and infrastructure engineers responsible for clusters other people depend on, and it assumes you are comfortable at a Linux shell — systemctl, journalctl, ssh, vim, reading logs — because plenty of tasks put you on a node rather than at an API. It does not assume you have written a controller or run an internal developer platform. Those are the next storey up.

Why a platform engineer might take it — and when to skip it

☺ Like you’re 10: You can’t build a great kitchen on a floor that keeps collapsing. But if someone else already fixed the floor, maybe you don’t need the floor certificate.

Be honest with yourself about which of these you are.

The case for taking it

A platform engineer sells an abstraction, and abstractions leak. A workload in CrashLoopBackOff, a namespace stuck on a finalizer, a PVC Pending forever — the ticket lands on the platform team, and “I only know the Argo CD UI” is not an answer. The CKA builds the muscle underneath: reading control-plane logs, knowing what a Service actually programs, knowing that scheduling and networking failures look identical from outside and are diagnosed completely differently. For many employers it is also a hiring filter rather than a nice-to-have.

When to skip it

Deprioritise it if any of these fit. You already operate clusters daily: it will confirm what you know and teach you little — spend the money on the CNPE or CKS. You run only managed control planes (EKS, GKE, AKS): a full quarter of the exam is installation and lifecycle work your provider owns and you will never do. Your gap is delivery, not operations: if the weak spot is progressive delivery or self-service APIs, this is a detour. And if you are new to cloud native, start with KCNA — the CKA punishes people still learning what a Pod is.

CKA versus CNPE — different altitudes, same style

The two feel the same on the day and test completely different things. Both are hands-on and graded on cluster state; the CNPE starts where the CKA stops.

The official domains and weights (CKA curriculum v1.35)

☺ Like you’re 10: Five topics, and they are not equal. Nearly a third of the whole exam is “something is broken, find it.”

These are the five domains and weights exactly as published in the CNCF’s Certified Kubernetes Administrator (CKA) Exam Curriculum, version 1.35. There are five, they carry no sub-weights, and they sum to exactly 100% — 30 + 25 + 20 + 15 + 10. Note the shape: Troubleshooting alone is 30% — larger than Storage and Workloads combined. If you study nothing else, study breaking things and fixing them.

The competencies below are transcribed from the same document, one bullet per published competency. (The v1.35 PDF prints the 20% domain as “Servicing and Networking”; older study material writes it “Services and Networking” — same domain.)

30% — Troubleshooting

• Troubleshoot clusters and nodes
• Troubleshoot cluster components
• Monitor cluster and application resource usage
• Manage and evaluate container output streams
• Troubleshoot services and networking

25% — Cluster Architecture, Installation and Configuration

• Manage role based access control (RBAC)
• Prepare underlying infrastructure for installing a Kubernetes cluster
• Create and manage Kubernetes clusters using kubeadm
• Manage the lifecycle of Kubernetes clusters
• Implement and configure a highly-available control plane
• Use Helm and Kustomize to install cluster components
• Understand extension interfaces (CNI, CSI, CRI, etc.)
• Understand CRDs, install and configure operators

20% — Servicing and Networking

• Understand connectivity between Pods
• Define and enforce Network Policies
• Use ClusterIP, NodePort, LoadBalancer service types and endpoints
• Use the Gateway API to manage Ingress traffic
• Know how to use Ingress controllers and Ingress resources
• Understand and use CoreDNS

15% — Workloads and Scheduling

• Understand application deployments and how to perform rolling update and rollbacks
• Use ConfigMaps and Secrets to configure applications
• Configure workload autoscaling
• Understand the primitives used to create robust, self-healing, application deployments
• Configure Pod admission and scheduling (limits, node affinity, etc.)

10% — Storage

• Implement storage classes and dynamic volume provisioning
• Configure volume types, access modes and reclaim policies
• Manage persistent volumes and persistent volume claims

That is 27 published competencies in total: 5 + 8 + 6 + 5 + 3. If you have seen a fourth Storage bullet reading “troubleshoot clusters and nodes” quoted somewhere, it is a copy-and-paste artefact — the curriculum PDF is laid out in two columns, and that line is the first bullet of the Troubleshooting column sitting level with the Storage list. Storage publishes three competencies, not four.

Two additions surprise anyone who last read this curriculum a few years ago: Helm and Kustomize are now named under cluster installation, and the Gateway API sits alongside Ingress. Both show up in real tasks.

What you actually need to be able to do

☺ Like you’re 10: Here’s the real work behind each of those bullet points — the commands your fingers need to know without thinking.

Building and keeping a cluster alive

The 25% domain is kubeadm country: bootstrap a control plane, join a worker, upgrade both across a minor version, and take and restore an etcd snapshot. Upgrades are the classic task and the order matters. The sequence in the Kubernetes documentation — which is the page you will open in the exam — is: upgrade the kubeadm binary first, run kubeadm upgrade plan then kubeadm upgrade apply on the first control-plane node, and for every other node upgrade kubeadm, run kubeadm upgrade node, then drain, upgrade kubelet and kubectl, restart the kubelet and uncordon. Miss the drain and you lose marks; miss the uncordon and you lose them twice.

# --- worker node upgrade, in the order the Kubernetes docs give it ---
apt-mark unhold kubeadm
apt-get update && apt-get install -y kubeadm=1.35.0-1.1
apt-mark hold kubeadm
kubeadm upgrade node                      # 'kubeadm upgrade apply v1.35.0' on the FIRST control-plane node

kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data
apt-mark unhold kubelet kubectl           # kubeadm holds these: skip it and the install below is a no-op
apt-get update && apt-get install -y kubelet=1.35.0-1.1 kubectl=1.35.0-1.1
apt-mark hold kubelet kubectl
systemctl daemon-reload && systemctl restart kubelet
kubectl uncordon node-1

# --- etcd snapshot & restore: know these flags cold ---
# ETCDCTL_API=3 has been the default since etcd v3.4; harmless to set, still written everywhere
etcdctl snapshot save /opt/backup.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

# restore never talks to the API - it writes a fresh data dir offline, so it needs no --endpoints.
# etcd 3.6 moved restore out of etcdctl into etcdutl; check which binary your cluster ships.
etcdutl snapshot restore /opt/backup.db --data-dir /var/lib/etcd-restored
# older etcd: ETCDCTL_API=3 etcdctl snapshot restore /opt/backup.db --data-dir /var/lib/etcd-restored
# then point the etcd static pod's hostPath at the new data dir and let kubelet restart it

RBAC lives here too: Roles versus ClusterRoles, RoleBindings versus ClusterRoleBindings, ServiceAccounts, and the command that saves you — kubectl auth can-i get pods --as=system:serviceaccount:dev:builder -n dev. The same model underpins Security & Policy.

Workloads, scheduling and configuration

Deployments, rolling updates and kubectl rollout undo; ConfigMaps and Secrets as env vars and as volumes; requests and limits; node affinity, taints and tolerations, topology spread; and autoscaling with the HorizontalPodAutoscaler. Nearly all of it is faster imperatively — kubectl create deployment with --dry-run=client -o yaml to get a skeleton you edit. Scheduler and autoscaler mechanics are in Scaling, Scheduling & Performance.

Servicing and networking

Demonstrate how a Pod reaches another Pod, what a Service’s EndpointSlices actually contain, how CoreDNS resolves svc.namespace.svc.cluster.local, and how to expose traffic with an Ingress and with the newer Gateway API. NetworkPolicies are the piece people fluff: default-allow until the first policy selects a Pod, then default-deny for that direction — and egress rules need DNS explicitly allowed or nothing resolves.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow
  namespace: shop
spec:
  podSelector:
    matchLabels: { app: api }        # selecting a Pod flips it to deny-by-default
  policyTypes: [Ingress, Egress]
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: web }
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: kube-system }
          podSelector:
            matchLabels: { k8s-app: kube-dns }
      ports:
        - { protocol: UDP, port: 53 }   # forget this and every lookup fails
        - { protocol: TCP, port: 53 }   # DNS falls back to TCP for large answers

Everything here is unpacked properly in Networking & Connectivity, and the CNI implementations that enforce policies are covered on the Cilium page.

Storage

The smallest domain and the most mechanical: a StorageClass with a provisioner and a reclaimPolicy, a PersistentVolumeClaim that binds to it, access modes (ReadWriteOnce, ReadWriteMany, ReadWriteOncePod), static PVs, and Delete versus Retain when the claim goes away. Learn to read a Pending PVC’s events — almost always a missing StorageClass, a size or access-mode mismatch, or WaitForFirstConsumer doing exactly what it should. Depth lives in Storage & Stateful Workloads.

Troubleshooting — the 30%

The largest domain has no new API objects to learn; it is a method. Never guess: describe before you log, log before you exec, check the node before you blame the app. A control-plane failure usually means a broken static Pod manifest in /etc/kubernetes/manifests/ — read the kubelet’s journal on the node, because the API server can’t tell you why the API server is down.

# the standard opening sequence
kubectl get pods -A -o wide | grep -Ev 'Running|Completed'
kubectl describe pod <pod> -n <ns> | tail -25      # Events are at the bottom
kubectl logs <pod> -n <ns> -c <container> --previous
kubectl top nodes && kubectl top pods -n <ns>      # needs metrics-server
kubectl get events -n <ns> --sort-by=.lastTimestamp | tail -20

# when the control plane itself is sick — do this ON the node
systemctl status kubelet && journalctl -u kubelet -n 60 --no-pager
crictl ps -a | head                                # static pods aren't in kubectl if apiserver is down
ls /etc/kubernetes/manifests/                      # kube-apiserver.yaml, etcd.yaml, ...

# is the Service actually wired to anything?
kubectl get endpointslices -n <ns> -l kubernetes.io/service-name=<svc>

How to prepare using this site

☺ Like you’re 10: Here’s the map from each exam topic to the exact page here that teaches it, so you can start today.

This site was written for the CNPE, so it runs deeper than the CKA on delivery and platform APIs and lighter on kubeadm. Everything below is genuine CKA material you can study today; the gaps — kubeadm bootstrap and upgrade, etcd snapshots — are best learned on a real cluster and from the Kubernetes docs, which is where the exam sends you anyway.

A workable six-week shape

Weeks 1–2: build a multi-node cluster with kubeadm twice from scratch, then upgrade it. Week 3: workloads, scheduling and storage from the CLI, no copy-paste. Week 4: networking, a NetworkPolicy exercise daily plus one Gateway API task. Week 5: nothing but troubleshooting — break your own cluster every day, as in Benny’s workshop. Week 6: timed papers and speed drills from the speed reference. Highest-return habit of all: alias k=kubectl and export do="--dry-run=client -o yaml" in the exam’s first sixty seconds.

Exam logistics — and why you must check them yourself

☺ Like you’re 10: The shape of the test changes now and then. Read the official page before you pay for anything.

The details below are what the Linux Foundation and CNCF publish and what candidates consistently report. They are here to help you plan, not to be quoted back at anyone — every one of them has changed at some point in the exam’s history.

Where the CKA sits in the ladder, and what to do next

☺ Like you’re 10: It’s the middle rung. There’s an easier one below it and harder ones above, and different ones off to the side.

Treat the CNCF certifications as a floor plan, not a straight line. KCNA and KCSA are the entry-level, knowledge-based rungs below. The CKA and CKAD sit side by side at practitioner level — CKAD is the same style of exam pointed at the application developer’s half of Kubernetes. Above them, CKS requires an active CKA and goes deep on hardening, supply chain and runtime security. Off to one side sit the platform credentials: CNPA as the associate and the CNPE as the senior platform exam this site is built around. Watch the format when you plan: the associate-level exams — KCNA, KCSA and CNPA — are knowledge-based multiple choice, while CKA, CKAD, CKS and the CNPE are performance-based and graded on what you actually did to a live environment. They reward completely different revision.

If platform engineering is where you are headed, the step after CKA is not CKS — it is the CNPE. Start with the CNPE exam guide, then work the blueprint from GitOps forward; your CKA reflexes will carry the troubleshooting under every domain. Full comparisons live on the certifications hub.