← Back to all articles
CKAKubernetesCertificationStudy Guide

Getting Started with CKA: A Complete Study Guide

8 May 2026·6 min read·By Jacob

The Certified Kubernetes Administrator (CKA) is a performance-based certification from the Linux Foundation and CNCF that tests your ability to manage and troubleshoot Kubernetes clusters in a live environment. Unlike multiple-choice exams, the CKA gives you a real cluster and a set of tasks to complete in two hours. There is no guessing your way through it.

If you've heard it's hard, that's accurate. But it's also very learnable with the right preparation strategy.

Exam Domains

The CKA curriculum covers five domains:

DomainWeight
Troubleshooting30%
Cluster Architecture, Installation & Configuration25%
Services & Networking20%
Workloads & Scheduling15%
Storage10%

Troubleshooting is the largest domain at 30%. If you're under-prepared for diagnosing broken nodes, failing pods, and misconfigured components, that's where the exam will punish you.

Core Concepts to Master

Cluster Setup with kubeadm

The exam expects you to know how to bootstrap a cluster and perform upgrades using kubeadm. The upgrade path in particular appears in nearly every exam and needs to be second nature.

# Initialize a new control plane node
kubeadm init --pod-network-cidr=10.244.0.0/16

# Join a worker node to an existing cluster
kubeadm join <control-plane-host>:6443 --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

# Upgrade control plane
kubeadm upgrade plan
kubeadm upgrade apply v1.30.0

# Upgrade kubelet and kubectl on each node
apt-mark unhold kubelet kubectl
apt-get install -y kubelet=1.30.0-1.1 kubectl=1.30.0-1.1
apt-mark hold kubelet kubectl
systemctl daemon-reload && systemctl restart kubelet

Don't forget to drain nodes before upgrading and uncordon them after:

kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
kubectl uncordon <node-name>

etcd Backup and Restore

Backing up and restoring etcd is a high-value task that requires precision. Get the flags wrong and you'll burn time you don't have.

# Snapshot the etcd database
ETCDCTL_API=3 etcdctl snapshot save /opt/backup/etcd.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

# Verify the snapshot
ETCDCTL_API=3 etcdctl snapshot status /opt/backup/etcd.db

# Restore from snapshot
ETCDCTL_API=3 etcdctl snapshot restore /opt/backup/etcd.db \
  --data-dir=/var/lib/etcd-restored

After restoring, update the etcd static pod manifest at /etc/kubernetes/manifests/etcd.yaml to point to the new data directory.

RBAC and Service Accounts

Role-based access control is a consistent part of the exam. You need to create Roles and ClusterRoles, bind them to users or service accounts, and verify permissions.

# Create a role scoped to a namespace
kubectl create role pod-manager \
  --verb=get,list,create,delete \
  --resource=pods \
  -n staging

# Bind the role to a service account
kubectl create rolebinding pod-manager-binding \
  --role=pod-manager \
  --serviceaccount=staging:deploy-sa \
  -n staging

# Verify what the service account can do
kubectl auth can-i list pods \
  --as=system:serviceaccount:staging:deploy-sa \
  -n staging

Persistent Volumes and Storage

The storage domain covers PersistentVolumes, PersistentVolumeClaims, and StorageClasses. PVs and PVCs need to match on access modes and storage class for binding to work.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-data
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /mnt/data
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Services and Networking

You need to know the differences between ClusterIP, NodePort, and LoadBalancer service types, how to write NetworkPolicies, and how CoreDNS resolves service names.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
  namespace: app
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: frontend
      ports:
        - protocol: TCP
          port: 8080

A NetworkPolicy with an empty podSelector: {} applies to all pods in the namespace. An empty ingress: [] blocks all inbound traffic. Know the difference.

Workloads and Scheduling

Taints, tolerations, and node affinity control where pods land. These appear in exam tasks that require you to schedule a pod on a specific node or prevent scheduling on certain nodes.

# Add a taint to a node
kubectl taint nodes worker-1 env=prod:NoSchedule

# Remove a taint
kubectl taint nodes worker-1 env=prod:NoSchedule-
spec:
  tolerations:
    - key: "env"
      operator: "Equal"
      value: "prod"
      effect: "NoSchedule"
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                  - worker-1

Troubleshooting

Troubleshooting is 30% of the exam. You need to know where to look when things break.

# Check node status
kubectl get nodes
kubectl describe node <node-name>

# Diagnose kubelet issues on a node
systemctl status kubelet
journalctl -u kubelet --since "10 minutes ago"

# Check control plane component health
kubectl get pods -n kube-system
kubectl describe pod kube-apiserver-<node> -n kube-system

# Inspect static pod manifests (control plane runs here)
ls /etc/kubernetes/manifests/

# Pod-level debugging
kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl logs <pod-name> --previous  # if pod keeps crashing
kubectl exec -it <pod-name> -- /bin/sh

Common failure patterns to know: broken kubelet service, misconfigured static pod manifests, CNI not installed after cluster init, wrong container image, missing RBAC permissions, PVC not binding due to mismatched access modes.

Study Tips

The CKA is a hands-on exam. Reading documentation is not sufficient preparation on its own. You need to spend the majority of your study time in a real cluster.

Set up a local environment with kind or kubeadm on VMs and practice breaking and fixing it. Purposely misconfigure the kubelet, break a static pod manifest, then diagnose and repair it. That diagnostic muscle memory only comes from repetition.

Time management matters more than most candidates expect. Practice completing tasks within strict time limits. Get comfortable skipping a hard task, moving on, and returning to it. A 4-point task that costs you 20 minutes is a poor trade if you have 8-point tasks left untouched.

The official Kubernetes documentation is available during the exam at docs.kubernetes.io. Bookmark the pages you use most before exam day: kubeadm upgrade steps, etcdctl syntax, NetworkPolicy examples, and PersistentVolume spec. Being able to find things quickly is part of the test.

Final Thoughts

The CKA is achievable if you've done real Kubernetes administration work, or if you put in the time to simulate it during preparation. Budget 8–12 weeks if you're starting from a solid CKAD foundation, longer if Kubernetes is new to you.

Build things. Break things. Fix them under a timer. That's the preparation that passes the CKA.

Use our CKA practice questions to test your conceptual knowledge and identify gaps before exam day.

Ready to test your knowledge?

CKA Practice Exams

Put what you've learned to the test with practice questions that mirror the real exam.

Start Practising →