Why the CKA is different from every other IT certification

Most certification vendors test you by asking what you would do. The CNCF tests you by watching you do it. The exam runs entirely in a browser-based remote desktop connected to a live multi-node Kubernetes environment. Tasks are graded automatically against the actual state of the cluster after you finish — if you configured a NetworkPolicy correctly, the cluster shows it; if you mistyped a selector, you lose those points regardless of your intent.

This format makes rote memorisation almost useless. You can keep the official Kubernetes documentation open in a second browser tab during the exam — and you should plan to. The constraint isn’t access to information; it’s the speed at which you can navigate the docs, write resource manifests, apply them, and verify the result. Candidates who sit the CKA without hands-on lab experience report that 2 hours feels short. Those who have done daily terminal practice for 60–90 days report that it feels comfortable. There is no shortcut between those two outcomes.

The exam is administered through the PSI secure browser. As of 2024, both the initial attempt and one free retake are bundled into the $395 registration price, and the credential carries a three-year expiry before re-certification is required.

The open-docs strategy

The Kubernetes documentation at kubernetes.io is permitted during the exam. Before exam day, bookmark three pages you will need under time pressure: the kubectl cheat sheet, the Tasks section (PersistentVolumes, RBAC, NetworkPolicies), and the API reference for resource manifests. You are not expected to memorise YAML syntax — you are expected to find, adapt, and apply it faster than the clock runs out.

The five exam domains

The CNCF publishes the full curriculum on its website. The five domains and their approximate weights are:

Domain 1 — Cluster Architecture, Installation & Configuration (25%)

This domain tests your ability to bootstrap a cluster from scratch and understand the components that managed platforms like GKE and EKS deliberately hide.

  • kubeadm: Initialise a control plane with kubeadm init, join worker nodes with kubeadm join, and pass the correct flags for pod CIDR and API server advertise address. Know how to upgrade a cluster step-by-step with kubeadm upgrade.
  • Control plane components: kube-apiserver, kube-controller-manager, kube-scheduler, and etcd. Understand each component’s role and where its config lives — static Pod manifests at /etc/kubernetes/manifests/. When a control plane component crashes, look in /var/log/pods/ or run journalctl -u kubelet.
  • etcd backup and restore: Use etcdctl snapshot save and etcdctl snapshot restore with the correct endpoint, CA cert, client cert, and key flags. This task appears on almost every CKA attempt — know the flags and file paths by heart before exam day.
  • RBAC: Create Roles and ClusterRoles, bind them with RoleBindings and ClusterRoleBindings, and verify access with kubectl auth can-i --as <serviceaccount>. The exam will ask you to grant a service account the minimum permissions for a specific action.
  • Node management: Drain, cordon, and uncordon nodes. Manage taints and tolerations to control which pods can schedule on which nodes. Know the difference between NoSchedule, PreferNoSchedule, and NoExecute taint effects.

Domain 2 — Workloads & Scheduling (15%)

Deploying and managing application workloads — the layer developers interact with, tested here at the operator level.

  • Deployments and rollouts: kubectl rollout history, kubectl rollout undo, and setting the maxSurge / maxUnavailable strategy fields. Scale a Deployment imperatively with kubectl scale and declaratively by editing the manifest.
  • ConfigMaps and Secrets: Create both types, consume them as environment variables or volume mounts. Remember that Secret data is base64-encoded but not encrypted at rest by default — enabling encryption at rest requires a separate EncryptionConfiguration.
  • Resource requests and limits: Set CPU and memory requests and limits in Pod specs. The scheduler uses requests to place pods; the kubelet enforces limits. A pod that exceeds its memory limit is OOMKilled; one that exceeds its CPU limit is throttled, not killed.
  • Pod scheduling: nodeSelector for simple placement, nodeAffinity for expressive rules, podAffinity and podAntiAffinity for co-location and spread. Taints on nodes repel pods; tolerations on pods allow placement on tainted nodes.
  • DaemonSets and StatefulSets: A DaemonSet runs exactly one pod per eligible node — ideal for log agents, monitoring daemons, and CNI plugins. A StatefulSet provides stable network identity (predictable pod names) and ordered rollout/termination for stateful workloads like databases.

Domain 3 — Services & Networking (20%)

Kubernetes networking is one of the trickier exam areas because behaviour depends on both the API objects and the CNI plugin installed in the cluster.

  • Service types: ClusterIP (cluster-internal only), NodePort (exposed on each node’s IP at a static port), LoadBalancer (cloud-provisioned external load balancer), and ExternalName (DNS CNAME alias). Know which type the exam scenario calls for.
  • DNS: CoreDNS resolves Services as <service>.<namespace>.svc.cluster.local. This hostname format appears in exam tasks requiring one pod to reach another by name rather than IP.
  • NetworkPolicies: All pods can reach all pods by default. A NetworkPolicy restricts ingress or egress based on pod selectors, namespace selectors, or IP blocks. The exam regularly asks you to create a policy that allows only specific pods to reach a database pod — know how to write both the spec.podSelector and the spec.ingress.from block.
  • Ingress: Routes external HTTP/HTTPS traffic to Services based on hostname and path rules. The Ingress controller (nginx, Traefik, etc.) must be pre-deployed — it implements the rules. Know how to write an Ingress manifest and reference a TLS Secret.
  • CNI awareness: NetworkPolicy enforcement requires a CNI that supports it — Calico and Cilium do; Flannel does not. The exam cluster will have a compatible CNI installed. You won’t install it, but you need to know that a NetworkPolicy without an enforcing CNI is silently ignored.

Domain 4 — Storage (10%)

The smallest domain by weight, but one where candidates often drop easy points by getting YAML syntax wrong under time pressure. Practice writing these manifests until they are automatic.

  • PersistentVolumes and PersistentVolumeClaims: A PersistentVolume (PV) is a cluster-level storage resource. A PersistentVolumeClaim (PVC) is a namespace-level request that binds to a PV matching its access mode and capacity. Know how to write both manifests and mount the PVC as a volume inside a Pod spec.
  • Access modes: ReadWriteOnce (single node, read/write), ReadOnlyMany (multiple nodes, read only), ReadWriteMany (multiple nodes, read/write). Not all storage backends support all modes — the exam will specify which to use.
  • StorageClasses: Enable dynamic provisioning. A PVC references a StorageClass name; the provisioner creates the backing storage automatically. The default StorageClass is used when a PVC omits the storageClassName field.
  • Volume types: emptyDir is ephemeral and lives with the pod lifecycle. hostPath mounts a node directory — acceptable in exam tasks, avoid in production. PVC-backed volumes persist independently of pod lifecycle and are the right answer for stateful workloads.

Domain 5 — Troubleshooting (30%)

The heaviest domain — and the one that most clearly separates engineers who have operated Kubernetes in production from those who haven’t. Speed and pattern recognition here determine your final score.

  • Pod failures: Start with kubectl describe pod <name> and read the Events section. Common causes: image pull errors (wrong image name, missing imagePullSecret), resource pressure (OOMKilled, Evicted), liveness probe failures, init container crashes, and missing ConfigMap or Secret references.
  • Node not ready: Check the kubelet service first — systemctl status kubelet and journalctl -u kubelet -n 50. The kubelet config lives at /var/lib/kubelet/config.yaml. A malformed static Pod manifest will crash-loop the affected control plane component.
  • Control plane component failures: Static Pod manifests for kube-apiserver, kube-controller-manager, and kube-scheduler live in /etc/kubernetes/manifests/. Edit the YAML directly — kubelet watches the directory and restarts the container on change. Read logs from /var/log/pods/kube-system_<component>*/.
  • Service connectivity: A pod that can’t reach a service: verify the Service selector matches the pod labels (kubectl get endpoints <svc> should show at least one IP), check no NetworkPolicy is blocking the path, and confirm the target port matches what the container is actually listening on.
  • Application logs: kubectl logs <pod> for the current container, kubectl logs <pod> -c <container> for multi-container pods, and kubectl logs <pod> --previous for logs from the most recent crashed container. These are the first commands for every application-level incident on the exam.
The most common CKA failure pattern: spending too long on one hard task and running out of time for three easy ones. Each task shows its point value in the exam interface. Bank the 7% and 8% tasks first, then return to anything that stumped you. A partially correct 4% task is worth less than two fully correct 7% tasks you skipped.

The prep strategy that actually works

The non-negotiable is hands-on terminal practice every day. A local cluster with kind (Kubernetes-in-Docker) takes under ten minutes to stand up and costs nothing. For the cluster architecture domain, provision two virtual machines and practise kubeadm init and kubeadm join against real VMs — the exam doesn’t use kind, and bootstrapping a control plane in a containerised environment teaches different muscle memory than bootstrapping a real one.

Killer.sh is included free with your exam registration and provides two full simulator sessions running against a harder-than-real-exam environment with the same browser interface. Run your first session early to diagnose weak domains, spend two weeks addressing those gaps with focused lab work, then run your second session as a final readiness check. Most candidates who score 70–80% on their second Killer.sh session pass the real exam on the first attempt.

Why it matters for cert candidates

Kubernetes underpins Google Kubernetes Engine (GKE), Amazon EKS, and Azure AKS — the container orchestration platforms that appear across GCP Professional Cloud DevOps Engineer, AWS Solutions Architect, and Azure AZ-104 exam scenarios. The CKA proves you understand Kubernetes at the infrastructure layer, not just as a consumer of a managed service. Employers hiring for SRE, platform engineering, and cloud DevOps roles increasingly list it alongside cloud-vendor certs. Because it is vendor-neutral, it signals operational depth regardless of which cloud platform you’re deploying on. The CNCF has reported year-over-year growth in CKA registrations as Kubernetes adoption moves from early adopters into mainstream enterprise IT operations. Source: Google Cloud Blog — Kubernetes.

The CNCF certification ladder

The CKA is the middle tier of the CNCF’s three Kubernetes certifications:

For candidates coming from an AWS or GCP background, pairing the CKA with cloud-specific Kubernetes content — EKS node groups and Fargate profiles for AWS, GKE Autopilot and Workload Identity for GCP — gives you both the foundational knowledge and the operational context that real job descriptions require.

Preparing for the CKA or CKAD? We have Kubernetes practice questions covering cluster architecture, RBAC, Services, NetworkPolicies, storage, and troubleshooting — the same domains the exam tests, timed and randomised.

Start Kubernetes Practice Questions →