Passing the CKA exam after years of Kubernetes

I’ve been working with Kubernetes for years. Running clusters, debugging pods, writing manifests, fixing production issues at 3 AM. I thought the CKA exam would be a formality , proof of something I already knew.

I was wrong. The CKA is not a knowledge test. It’s a speed test. And it exposes the gaps you didn’t know you had.

This is what I learned.

What the CKA actually is

The Certified Kubernetes Administrator exam is a performance-based test. No multiple choice, no theoretical questions. You get a terminal with access to real Kubernetes clusters and you solve tasks in real time.

Two hours. 66% to pass. You can use the official Kubernetes documentation, Helm docs, and Kubernetes blog during the exam. That’s it.

The exam tests five domains:

Domain	Weight
Cluster Architecture, Installation & Configuration	25%
Workloads & Scheduling	15%
Services & Networking	20%
Storage	10%
Troubleshooting	30%

Troubleshooting is the biggest single domain. If you’re good at reading logs, diagnosing broken components, and fixing them quickly, you’re halfway there.

The exam format that catches people off guard

The exam runs on a browser-based terminal connected to a multi-cluster environment. You’ll have 2-3 clusters with different configurations. Each task tells you which context to use, and if you solve the wrong task on the wrong cluster, you get zero points.

This sounds simple, but under time pressure, people forget to switch contexts. I’ve seen experienced engineers lose points because they solved a network policy task on the wrong cluster.

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

This domain covers the foundational stuff: how Kubernetes works, how to set it up, and how to manage it.

What you need to know:

RBAC. You need to understand Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. Not just the YAML structure, but how they interact. A Role gives permissions within a namespace. A ClusterRole gives cluster-wide permissions. A RoleBinding connects a Role to a user or group. A ClusterRoleBinding does the same for cluster-wide permissions.

Practice this until you can write RBAC manifests without looking at docs. The exam might ask you to grant a user read access to pods in a specific namespace, or to create a service account with specific permissions.

kubeadm cluster setup. You should understand how kubeadm initializes a cluster: kubeadm init, kubeadm join, the control plane components (kube-apiserver, kube-controller-manager, kube-scheduler, etcd), and how they communicate.

High availability. Know what it takes to run a multi-master control plane: stacked vs external etcd, load balancing, certificate management.

Helm and Kustomize. The exam expects you to use these tools. Helm for installing complex applications (like ArgoCD, Prometheus), Kustomize for customizing manifests without templating.

Extension interfaces. CNI (Container Network Interface) for networking, CSI (Container Storage Interface) for storage, CRI (Container Runtime Interface) for container runtimes. You don’t need to implement these, but you need to understand what they do and how they fit together.

CRDs and operators. Custom Resource Definitions extend Kubernetes with new resource types. You should know how to create a CRD, how to install operators, and how to use them.

My experience: I underestimated this domain. I’d been using Kubernetes for years but never set up a cluster from scratch. The kubeadm commands felt foreign because I’d always used managed services (EKS, GKE, OpenShift). If you’re in the same boat, spend time setting up a cluster with kubeadm. It’s worth it.

Domain 2: Workloads & Scheduling (15%)

This domain is about deploying and managing applications on Kubernetes.

What you need to know:

Deployments, ReplicaSets, and Pods. Understand the relationship: Deployment creates ReplicaSet, ReplicaSet creates Pods. Know how to perform rolling updates, rollbacks, and scale deployments.

kubectl rollout status deployment/myapp
kubectl rollout history deployment/myapp
kubectl rollout undo deployment/myapp
kubectl scale deployment myapp --replicas=5

ConfigMaps and Secrets. These configure applications without baking config into container images. ConfigMaps for non-sensitive data, Secrets for sensitive data (though Secrets are just base64-encoded by default, not encrypted).

Horizontal Pod Autoscaler (HPA). Autoscaling based on CPU, memory, or custom metrics. Know the syntax:

kubectl autoscale deployment myapp --min=2 --max=10 --cpu-percent=80

Pod scheduling. Understand node affinity, taints and tolerations, pod disruption budgets, and resource requests/limits. These control where pods run and how much resources they can use.

My experience: This domain felt familiar from daily work. The tricky part was the scheduling concepts , taints and tolerations especially. I’d used them in production but never thought about them from an exam perspective. Practice writing taints and tolerations until they’re second nature.

Domain 3: Services & Networking (20%)

Networking is where Kubernetes gets complex. This domain tests your understanding of how pods communicate, how to expose services, and how to control network traffic.

What you need to know:

Service types. ClusterIP (internal only), NodePort (expose on node ports), LoadBalancer (external load balancer), and ExternalName (DNS alias). Know when to use each.

Ingress and Gateway API. Ingress routes HTTP traffic to services. Gateway API is the newer, more flexible replacement. The exam tests both. Understand Ingress controllers, Ingress resources, TLS termination, and path-based routing.

Network Policies. These control which pods can talk to which other pods. Think of them as firewalls for pods. You need to know how to write NetworkPolicies that allow specific traffic while blocking everything else.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
spec:
  podSelector:
    matchLabels:
      app: frontend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend

CoreDNS. The DNS service that resolves service names to cluster IPs. Understand how DNS works in Kubernetes and how to troubleshoot DNS issues.

My experience: Network policies tripped me up during practice. The YAML syntax is straightforward, but thinking about which pods need to talk to which other pods requires a different mindset than just “allow everything.” I built a mental model: start with deny-all, then add allow rules for each communication path.

Domain 4: Storage (10%)

Storage is the smallest domain but important. Kubernetes manages persistent storage through PersistentVolumes (PVs), PersistentVolumeClaims (PVCs), and StorageClasses.

What you need to know:

PersistentVolumes and PersistentVolumeClaims. PVs are storage resources in the cluster. PVCs are requests for storage. When a PVC matches a PV, they’re bound together. Understand access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) and reclaim policies (Retain, Delete, Recycle).

StorageClasses. Define different types of storage (fast SSD, slow HDD, etc.). When a PVC requests a StorageClass, Kubernetes dynamically provisions a PV using that class.

Volume types. Understand the difference between emptyDir (temporary), hostPath (node filesystem), and networked storage (NFS, cloud provider volumes).

My experience: Storage was my weakest area. I’d always used managed storage from cloud providers and never thought about the underlying mechanics. Practice setting up PVs, PVCs, and StorageClasses on a local cluster. Understanding the relationship between these resources is key.

Domain 5: Troubleshooting (30%)

This is the biggest domain and the one that catches people off guard. Troubleshooting on Kubernetes means reading logs, checking component status, and fixing issues quickly.

What you need to know:

Node troubleshooting. Check node status with kubectl describe node, look at conditions (Ready, MemoryPressure, DiskPressure, PIDPressure), and understand what each condition means.

Control plane troubleshooting. Know the control plane components and their logs:

# Check component status
kubectl get componentstatuses

# Check control plane pods
kubectl get pods -n kube-system

# Check etcd
etcdctl endpoint health --endpoints=https://127.0.0.1:2379

# Check kube-apiserver logs
journalctl -u kube-apiserver -f

Application troubleshooting. Pod events, container logs, resource usage:

kubectl describe pod mypod
kubectl logs mypod
kubectl logs mypod --previous  # logs from crashed container
kubectl top pods
kubectl top nodes

Network troubleshooting. DNS resolution, service endpoints, network policies blocking traffic.

My experience: Troubleshooting was where my real-world experience helped the most. I’d debugged enough production issues to know the common failure modes. But the time pressure was intense. In production, you might take 30 minutes to diagnose a problem. On the exam, you have 5 minutes per task.

How I prepared

Week 1-2: Foundation review. I went through the Kubernetes documentation systematically. Even though I’d been using Kubernetes for years, I found gaps in my knowledge , especially around storage and RBAC.

Week 3-4: Hands-on practice. I set up a local cluster with kind and practiced tasks. I used Killer.sh (included with the exam purchase) for realistic practice scenarios.

Week 5: Mock exams. I timed myself on practice exams. The first time, I finished with 40 minutes to spare but scored only 58%. I was too fast and too careless. The second time, I slowed down, read tasks carefully, and scored 72%. Each mock exam taught me something new about time management.

Week 6: Targeted practice. I focused on my weak areas: storage, network policies, and etcd troubleshooting.

The week before: revision. I reviewed my notes, practiced the imperative kubectl commands, and rested.

Tips that made the difference

Use imperative commands. Instead of writing YAML from scratch, use kubectl create, kubectl expose, kubectl autoscale. It’s faster and less error-prone.

# Instead of writing a Deployment YAML:
kubectl create deployment nginx --image=nginx --replicas=3

# Instead of writing a Service YAML:
kubectl expose deployment nginx --port=80 --type=NodePort

Read the task twice. Before you start, read the entire task. Underline the namespace, resource names, and exact values. A typo in a resource name costs you points.

Skip hard tasks. If a task looks complicated, skip it and come back later. The exam doesn’t penalize for skipping. Focus on high-weight tasks you’re confident about.

Use kubectl explain. If you forget a field name, kubectl explain pod.spec.containers shows you the schema. It’s faster than searching docs.

Keep a cheat sheet. I kept a personal cheatsheet with common commands. You’re allowed one tab with notes during the exam.

What I’d do differently

Start with kubeadm. I spent too long using managed services. Setting up a cluster from scratch teaches you things you can’t learn from EKS or GKE.

Practice more networking tasks. Network policies and Gateway API were my weakest areas. The exam has moved toward Gateway API, so practice both Ingress and Gateway.

Don’t rush. Speed comes from practice, not from hurrying. Read the task, understand what’s being asked, then execute. Rushing leads to mistakes.

Use the documentation. The exam allows Kubernetes docs. Practice finding answers quickly. The search function is your friend.

The pass

I passed with 87%. A solid score that I was genuinely proud of.

The CKA taught me that years of experience doesn’t equal exam readiness. The exam tests breadth, not just depth. You need to know networking, storage, scheduling, troubleshooting, and cluster architecture , not just the parts you use daily.

If you’re considering the CKA, my advice is: start practicing early, focus on weak areas, and don’t underestimate the time pressure. The exam is fair, but it demands preparation.

And remember: the docs are available during the exam. Knowing how to find answers quickly is as important as knowing the answers.