CKA CKAD CKS Certification Guide

A senior engineer spent 40 minutes debugging a network policy that wasn't blocking traffic. The root cause? A missing podSelector in a CKA-style cluster setup. That's the difference between knowing Kubernetes and being certified. The CKA, CKAD, and CKS exams are not multiple-choice trivia—they are grueling, hands-on tests where you must solve real problems under time pressure. If you can't debug a broken control plane or write a secure pod security policy in 30 minutes, you will fail. This guide breaks down each certification, the exact skills tested, and the production pitfalls that separate a certified engineer from a dangerous one.

The Trinity: CKA, CKAD, CKS — What Each Tests

The Certified Kubernetes Administrator (CKA) focuses on cluster operations: installing, configuring, and maintaining a Kubernetes cluster. You'll troubleshoot control plane components, manage etcd backups, and handle node failures. The Certified Kubernetes Application Developer (CKAD) tests your ability to design, build, and deploy applications on Kubernetes—think Deployments, Services, ConfigMaps, and Helm charts. The Certified Kubernetes Security Specialist (CKS) is the hardest: it covers cluster hardening, runtime security, network policies, and auditing. All three are performance-based: you SSH into a real cluster and complete tasks in a terminal. No multiple choice. No cheats. Just you and a broken cluster.

#!/bin/bash
# Quick health check for CKA exam prep
kubectl get componentstatuses
kubectl get nodes -o wide
kubectl get pods --all-namespaces | grep -v Running
curl -k https://localhost:6443/healthz

CKA Deep Dive: Cluster Architecture and Installation

The CKA exam expects you to install a cluster from scratch using kubeadm. You must know the control plane components: kube-apiserver, kube-controller-manager, kube-scheduler, and etcd. You'll configure TLS certificates, set up kubeconfig files, and join worker nodes. A common task: upgrade a cluster from one minor version to the next. You must drain nodes, upgrade kubeadm and kubelet, then uncordon. Another task: backup and restore etcd. You'll use etcdctl to snapshot and restore. Production tip: always test your backup restore in a staging environment first—etcd snapshots are version-specific.

#!/bin/bash
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot-$(date +%Y%m%d).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

CKAD Deep Dive: Workloads and Pod Design

CKAD is about application deployment: Deployments, StatefulSets, Jobs, CronJobs, and ConfigMaps. You'll write YAML from scratch, often with strict resource limits and liveness probes. A typical task: create a Deployment with 3 replicas, rolling update strategy, and a readiness probe that checks an HTTP endpoint. You must also handle multi-container pods with sidecar patterns. Production insight: always set resource requests and limits—without them, a single pod can starve the node. Another task: expose a Deployment via a Service of type ClusterIP, then verify connectivity using a temporary pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 10

CKS Deep Dive: Cluster Hardening and Security Policies

CKS is the most demanding. You'll harden the cluster: disable anonymous access, enable RBAC, use Pod Security Standards (baseline/restricted), and configure network policies. A common task: create a NetworkPolicy that allows only specific pods to communicate. Another: use kube-bench to audit the cluster and fix CIS benchmark failures. You'll also handle runtime security: use Falco to detect anomalous behavior, and configure Seccomp profiles. Production insight: many breaches start with a container running as root. Always enforce runAsNonRoot: true and drop all capabilities.

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

Exam Strategy: Time Management and Imperative Commands

All three exams are timed. You must be fast. Use imperative commands to create resources quickly, then edit YAML for complex changes. For example, kubectl run nginx --image=nginx --restart=Never creates a pod instantly. Use --dry-run=client -o yaml to generate YAML for editing. Bookmark the Kubernetes documentation—it's allowed during the exam. But don't rely on it heavily; you'll lose time. Practice with kubectl explain to get field definitions. Production insight: in real life, you'd use GitOps tools like ArgoCD, but the exam tests raw kubectl skills.

# Create a pod imperatively
kubectl run busybox --image=busybox --restart=Never -- sleep 3600

# Generate YAML for a deployment
kubectl create deployment web --image=nginx --replicas=3 --dry-run=client -o yaml > web-deploy.yaml

# Edit and apply
vim web-deploy.yaml
kubectl apply -f web-deploy.yaml

Troubleshooting: The Common Denominator

All three exams heavily feature troubleshooting. For CKA: a node is NotReady, a control plane component is down, or etcd is corrupted. For CKAD: a pod is CrashLoopBackOff, a Service isn't routing traffic, or a ConfigMap isn't mounted. For CKS: a PodSecurityPolicy is blocking pods, or a NetworkPolicy is too restrictive. The key is to follow a systematic approach: check events, describe resources, inspect logs, and verify connectivity. Use kubectl describe, kubectl logs, and kubectl exec. Production insight: always check kubectl get events --sort-by='.lastTimestamp' first—it often points directly to the issue.

# Pod in CrashLoopBackOff
kubectl describe pod my-pod
kubectl logs my-pod --previous
kubectl exec my-pod -- cat /var/log/app.log

# Check node conditions
kubectl describe node worker1 | grep -A5 Conditions

# Check network connectivity
kubectl run test-pod --image=busybox --rm -it -- wget -O- http://service-name:80

Security in Depth: CKS-Specific Topics

CKS goes beyond basic RBAC. You'll configure Pod Security Admission (PSA) to enforce standards at the namespace level. You'll use kubectl auth can-i to verify permissions. You'll also set up audit logging: configure the API server to log all requests to a file, then analyze with kubectl logs. Another topic: container runtime security with gVisor or Kata Containers. You'll also handle secrets encryption at rest using KMS. Production insight: many clusters have audit logging disabled. Enable it—it's your only forensic evidence after a breach.

apiVersion: v1
kind: Namespace
metadata:
  name: secure-ns
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Mock Exam: Putting It All Together

Let's simulate a multi-part task that spans all three certifications. Scenario: You have a cluster with a broken control plane (CKA), a misconfigured application (CKAD), and a security vulnerability (CKS). Step 1: Fix the control plane—the kube-scheduler is not running. Check the static pod manifest, restart it. Step 2: The application Deployment has a wrong image tag, causing CrashLoopBackOff. Update the image. Step 3: The cluster allows privileged containers. Create a PodSecurityPolicy that restricts to baseline. This exercise forces you to switch contexts quickly, just like the real exams.

# Step 1: Fix scheduler
kubectl get pods -n kube-system | grep scheduler
# If missing, check static pod manifest
ls /etc/kubernetes/manifests/
# Edit the manifest to fix any issues

# Step 2: Fix application
kubectl set image deployment/my-app my-container=nginx:1.25
kubectl rollout status deployment/my-app

# Step 3: Enforce security
kubectl label ns default pod-security.kubernetes.io/enforce=baseline

Resources and Study Plan

Official CNCF curriculum is the starting point. Use Killer.sh for realistic practice exams—they simulate the actual terminal environment. For CKA, focus on kubeadm, etcd, and networking. For CKAD, practice writing YAML under time constraints. For CKS, use kube-bench and Falco in a lab. Study plan: 2 weeks per certification, 2 hours daily. Week 1: theory and tutorials. Week 2: mock exams. Production insight: the best preparation is running a real cluster at home with Raspberry Pis or using kind. Break it intentionally, then fix it.

# Install kind for local cluster
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.20.0/kind-linux-amd64
chmod +x ./kind
./kind create cluster --name cka-lab

# Verify
kubectl cluster-info --context kind-cka-lab

Common Pitfalls and How to Avoid Them

Pitfall 1: Not reading the question carefully. The exam often has multiple parts—if you miss one, you lose points. Pitfall 2: Overusing kubectl apply -f without checking YAML syntax. Use --validate flag. Pitfall 3: Forgetting to set context or namespace. Use kubectl config set-context and kubectl config set-context --namespace. Pitfall 4: Not saving your work. The exam environment may time out. Production insight: in a real cluster, a missing --validate flag once caused a typo in a YAML file that deleted all pods in a namespace. Always validate.

# Validate YAML before applying
kubectl apply -f deployment.yaml --validate=true --dry-run=client

# Set context and namespace
kubectl config set-context my-context --namespace=production --cluster=prod --user=admin
kubectl config use-context my-context

# Save work periodically
kubectl get all --all-namespaces -o yaml > cluster-state-backup.yaml

After Certification: Maintaining Skills

Certifications expire after 3 years. But more importantly, Kubernetes evolves fast. Stay current by contributing to open source, running a home lab, or following the CNCF landscape. Production insight: the best engineers are those who break things in staging and learn from failures. Join the Kubernetes Slack community, attend KubeCon, and read the changelogs. Remember: a certification is a starting point, not a destination.

# Check current version and upgrade path
kubectl version --short
# Check available versions
apt-cache policy kubeadm
# Upgrade kubeadm
apt-get update && apt-get install -y kubeadm=1.29.0-00
kubeadm upgrade plan