CKA Mock Exam · Set 1 — 16 tasks, one clock, 100 points

This is the closest a static page can get to actually sitting the CKA: 16 performance-based tasks, 100 points, weighted 25/15/20/10/30 to match the real CKA domains, against one unbroken 2-hour block on a cluster you build yourself. There's no question bank here and nothing to memorize — every task hands you a broken, missing, or half-finished piece of a real kubeadm lab (a node that never joined, a Pod stuck crash-looping, a PVC that won't bind) and grades only the state you leave it in, exactly like the real exam does. Each task below comes with a done-when check so you can grade yourself honestly, and a full worked solution — real commands, real YAML — folded behind a summary so you're never tempted to peek before you've actually tried. If the mechanics under any of the five domains still feel shaky, work the study plan and this course's Exam Blueprint pages first; this paper measures whether you can execute under a clock, not whether you've read about it.

How this paper is built, and where it fits your prep

☺ Like you're 10: This is a full practice game, not sixteen separate practice drills — the same skills you've built one at a time, now back to back, on a clock that never pauses.

The real CKA doesn't publish which task is worth how many points, but it does publish the five domains' weights, and this paper takes that seriously: 25 points for Cluster Architecture, Installation & Configuration, 15 for Workloads & Scheduling, 20 for Services & Networking, 10 for Storage, and 30 for Troubleshooting — the same 25/15/20/10/30 split the study plan builds its nine weeks around. Below, that turns into 16 tasks (4 + 3 + 3 + 2 + 4), each with its own point value and its own done-when check. For teaching clarity this page groups tasks by domain, with the worked solution sitting right below each one — the real exam has no such courtesy, drawing tasks from several separate clusters in an order that ignores domain boundaries entirely. Once you've sat this paper once and read every solution, get a second, more realistic rep by writing the sixteen task numbers on paper, shuffling them, and re-attempting your own cluster in that random order with the solutions covered.

Before you start — build the lab cluster yourself

☺ Like you're 10: There's no download link for "one broken clubhouse" — you build the clubhouse yourself, from real materials, so the fixes you make are fixes you actually earned.

This page has no vendor-hosted environment behind it — it can't, being a static site. Build a throwaway 4-node kubeadm cluster the night before: one control-plane node and two already-joined workers running Kubernetes v1.35.0 on containerd with Calico as the CNI, plus a fourth machine — prepared with containerd, kubelet and kubeadm already installed, swap off, br_netfilter loaded — that is deliberately not yet joined. (No spare VMs available? A kind cluster with an extra unjoined node is harder to arrange; in that case skip task 1.1 only, and score it separately as "not attempted — no lab for this one" rather than guessing at it.) Install ingress-nginx, the metrics-server add-on, and a local-path-style dynamic provisioner, and confirm all of it is healthy before the timer starts:

# --- the night before ---------------------------------------------------
kubectl get nodes -o wide
# cka-mock-cp   Ready   control-plane   —   v1.35.0
# cka-mock-w1   Ready   <none>          —   v1.35.0
# cka-mock-w2   Ready   <none>          —   v1.35.0
# (cka-mock-w3 is provisioned but NOT joined yet — that's task 1.1)

kubectl get pods -A | grep -vE 'Running|Completed'   # anything unhealthy here is a task you'll skip, not fix
kubectl get storageclass                              # a default, dynamic-provisioning class should already exist
kubectl top nodes                                      # confirms metrics-server is actually working

# --- ninety seconds before the clock starts ------------------------------
kubectl config use-context cka-mock1
kubectl config set-context --current --namespace=default
kubectl config view --minify -o jsonpath='{..namespace}{"\n"}'   # say it out loud

alias k=kubectl
export do="--dry-run=client -o yaml"
export now="--grace-period=0 --force"

Exam conditions for this sitting

☺ Like you're 10: Same rules as the real day — one timer that never pauses, and no peeking at the answer until you've either solved it or spent its full budget.

One timer, started once. 120 minutes. You don't pause it to fix a typo'd YAML file, wait out an apt-get mirror, or answer the door — the real exam won't refund that time either, so losing eight minutes to your own laptop is data, not an excuse. Nothing open except kubernetes.io/docs and kubernetes.io/blog. That is the entire allowlist the real exam has historically published — not this site, not your notes, not a search engine, not an AI assistant. Close every other tab before you start. No peeking at a worked solution before you've either passed the done-when check or burned the task's full budget — reading the answer first turns a diagnostic into a comprehension exercise, and you'll repeat the same stall on the real day. Skim all sixteen task briefs first — five minutes spent scanning the whole paper is the highest-return five minutes of the sitting, because it tells you which three tasks you can close in under five minutes and which one is going to eat twelve.

Your time budget across the two hours

☺ Like you're 10: Give every part of the clubhouse its own fair slice of the two hours, and save a few extra minutes at the end just for double-checking your work.

120 minutes splits into 5 to skim, 106 of task work, and a 9-minute verification sweep at the end — and the 106 don't divide evenly across domains, because the domains themselves aren't equal. Troubleshooting alone claims almost a third of the clock; Storage, the smallest domain, claims well under a tenth.

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

☺ Like you're 10: This domain is building and keeping the clubhouse itself standing — welcoming a new member, writing down who's allowed to touch what, keeping a spare key, and changing the locks without accidentally locking out everyone who's already inside.

Scenario. Your cka-mock1 cluster: control-plane node cka-mock-cp and workers cka-mock-w1/cka-mock-w2, all on v1.35.0. A fourth machine, cka-mock-w3, is provisioned but not yet part of the cluster. Namespace payments already exists and is empty.

# on cka-mock-cp
kubeadm token create --print-join-command

# on cka-mock-w3, as root
kubeadm join 10.0.0.10:6443 --token 9a08jv.c0izixklcxtmnze7 \
  --discovery-token-ca-cert-hash sha256:1234...cafe

kubectl get nodes -o wide
# cka-mock-w3   Ready   <none>   41s   v1.35.0

apiVersion: v1
kind: ServiceAccount
metadata: { name: billing-bot, namespace: payments }
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: pod-log-reader, namespace: payments }
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: { name: billing-bot-reads-pods, namespace: payments }
subjects:
  - kind: ServiceAccount
    name: billing-bot
    namespace: payments
roleRef: { kind: Role, name: pod-log-reader, apiGroup: rbac.authorization.k8s.io }

kubectl auth can-i get pods -n payments --as=system:serviceaccount:payments:billing-bot        # yes
kubectl auth can-i delete pods -n payments --as=system:serviceaccount:payments:billing-bot     # no
kubectl auth can-i get secrets -n payments --as=system:serviceaccount:payments:billing-bot      # no

# on cka-mock-cp
ETCDCTL_API=3 etcdctl snapshot save /opt/backups/etcd-$(date +%s).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

etcdutl snapshot status /opt/backups/etcd-1755000000.db --write-out=table

etcdutl snapshot restore /opt/backups/etcd-1755000000.db \
  --data-dir=/var/lib/etcd-restored
# then edit /etc/kubernetes/manifests/etcd.yaml — change hostPath from
# /var/lib/etcd to /var/lib/etcd-restored (both the volume and volumeMount)

# the kubelet watches that manifest directory and restarts the static Pod automatically
crictl ps -a --name etcd
kubectl get nodes    # a real answer here proves the API server can talk to the restored etcd

apt-mark unhold kubeadm && apt-get update && apt-get install -y kubeadm=1.35.1-1.1 && apt-mark hold kubeadm
kubeadm upgrade plan
kubeadm upgrade apply v1.35.1

kubectl drain cka-mock-cp --ignore-daemonsets --delete-emptydir-data
apt-mark unhold kubelet kubectl
apt-get install -y kubelet=1.35.1-1.1 kubectl=1.35.1-1.1
apt-mark hold kubelet kubectl
systemctl daemon-reload && systemctl restart kubelet
kubectl uncordon cka-mock-cp

kubectl get nodes
# cka-mock-cp   Ready   control-plane   —   v1.35.1
# cka-mock-w1   Ready   <none>          —   v1.35.0   (fine — kubelet may trail apiserver by up to 3 minors)
# cka-mock-w2   Ready   <none>          —   v1.35.0

Domain 2 — Workloads & Scheduling (15 points)

☺ Like you're 10: This domain is which chores get done, in what order, by which member, and how many extra helpers show up automatically once the chore pile grows too big for the crew on duty.

Scenario. Namespace web holds Deployment storefront, three Ready replicas of nginx:1.25. Node cka-mock-w2 already carries the label disktype=ssd and the taint dedicated=gpu:NoSchedule. metrics-server is installed and healthy.

kubectl set image deployment/storefront nginx=nginx:1.27-doesnotexist -n web
kubectl rollout status deployment/storefront -n web --timeout=30s
# error: timed out waiting for the condition

kubectl rollout undo deployment/storefront -n web
kubectl rollout status deployment/storefront -n web
kubectl get pods -n web -l app=storefront -o jsonpath='{.items[*].spec.containers[0].image}'
# nginx:1.25 nginx:1.25 nginx:1.25

apiVersion: v1
kind: Pod
metadata: { name: batch-job }
spec:
  tolerations:
    - key: dedicated
      operator: Equal
      value: gpu
      effect: NoSchedule
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: disktype
                operator: In
                values: ["ssd"]
  containers:
    - name: worker
      image: busybox:1.36
      command: ["sh", "-c", "sleep 3600"]

kubectl apply -f batch-job.yaml
kubectl get pod batch-job -o wide
# batch-job   1/1   Running   cka-mock-w2

kubectl autoscale deployment storefront -n web --cpu-percent=50 --min=2 --max=6

kubectl get hpa storefront -n web
# NAME         REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS
# storefront   Deployment/storefront   14%/50%   2         6         3

Domain 3 — Services & Networking (20 points)

☺ Like you're 10: This domain is the clubhouse's phone system and front door — dialing between rooms, deciding exactly who's allowed to call which room, and letting outside visitors in through one clearly marked entrance.

Scenario. Namespace web: Deployment storefront (label app=storefront, listening on port 80) and Deployment checkout (label app=checkout, container port 8080), both Running. ingress-nginx is already installed cluster-wide.

kubectl expose deployment storefront -n web --name=storefront-svc --port=80 --target-port=80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: storefront-ingress
  namespace: web
spec:
  ingressClassName: nginx
  rules:
    - host: shop.cka-mock.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: storefront-svc
                port: { number: 80 }

curl -H "Host: shop.cka-mock.local" http://<ingress-controller-ip>/
# <title>Welcome to nginx!</title>

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny-all, namespace: web }
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
  # no rules at all = nothing allowed, in either direction

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: storefront-allow-edge, namespace: web }
spec:
  podSelector:
    matchLabels: { app: storefront }
  policyTypes: [Ingress, Egress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: edge }
          podSelector:
            matchLabels: { role: frontend }
      ports:
        - { protocol: TCP, port: 80 }
  egress:
    - to:                                    # DNS — the rule everyone forgets
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: kube-system }
          podSelector:
            matchLabels: { k8s-app: kube-dns }
      ports:
        - { protocol: UDP, port: 53 }
        - { protocol: TCP, port: 53 }

kubectl run allowed --image=busybox:1.36 -n edge -l role=frontend --rm -it --restart=Never \
  -- wget -qO- --timeout=3 storefront-svc.web.svc.cluster.local
# <title>Welcome to nginx!</title>

kubectl run blocked --image=busybox:1.36 -n edge --rm -it --restart=Never \
  -- wget -qO- --timeout=3 storefront-svc.web.svc.cluster.local
# wget: download timed out    (no role=frontend label — correctly blocked)

kubectl get endpoints checkout-svc -n web
# NAME            ENDPOINTS
# checkout-svc    <none>

kubectl get svc checkout-svc -n web -o yaml | grep -A2 selector
#   selector:
#     app: checkout-service        # doesn't match any Pod's real label

kubectl get pods -n web -l app=checkout --show-labels
# checkout-7f4...   1/1   Running   app=checkout          <-- actual label

kubectl patch svc checkout-svc -n web -p '{"spec":{"selector":{"app":"checkout"}}}'
kubectl get endpoints checkout-svc -n web
# checkout-svc   10.244.1.14:8080,10.244.2.9:8080

Domain 4 — Storage (10 points)

☺ Like you're 10: This domain is the storage room downstairs — ordering a fresh box the instant someone actually needs one, instead of always keeping a pile of empty boxes around, and working out why a request for a box sometimes never gets answered.

Scenario. A dynamic-provisioning StorageClass isn't yet defined for this namespace's use case. Separately, in namespace ops, PersistentVolume archive-pv already exists and PersistentVolumeClaim archive-data has been Pending for ten minutes.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata: { name: fast-ssd }
provisioner: rancher.io/local-path
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
allowVolumeExpansion: true

apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: reports-data }
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: fast-ssd
  resources: { requests: { storage: 5Gi } }

kubectl apply -f storageclass.yaml -f pvc.yaml
kubectl get pvc reports-data
# reports-data   Pending   —   —   fast-ssd     <-- correct: no Pod has claimed it yet

kubectl run reports --image=busybox:1.36 --restart=Never \
  --overrides='{"spec":{"containers":[{"name":"reports","image":"busybox:1.36","command":["sleep","3600"],
  "volumeMounts":[{"name":"data","mountPath":"/data"}]}],"volumes":[{"name":"data",
  "persistentVolumeClaim":{"claimName":"reports-data"}}]}}'
kubectl get pvc reports-data
# reports-data   Bound   pvc-8a1...   5Gi   RWO   fast-ssd

kubectl describe pvc archive-data -n ops | grep -A2 "Events\|StorageClass\|Access Modes"
# StorageClassName: fast-archive
# Access Modes: RWO
kubectl describe pv archive-pv | grep -A2 "StorageClass\|Access Modes\|Capacity"
# StorageClass: manual
# Access Modes: RWO
# Capacity: 10Gi

kubectl patch pv archive-pv -p '{"spec":{"storageClassName":"fast-archive"}}'
kubectl get pvc archive-data -n ops
# archive-data   Bound   archive-pv   10Gi   RWO   fast-archive

Domain 5 — Troubleshooting (30 points)

☺ Like you're 10: This domain is a firefighter's shift — four separate alarms go off in four separate rooms, and a full third of your score depends only on how fast and correctly you find and put out each one.

Scenario. Four independent incidents, each in namespace ops unless noted. Work them in any order — nothing here depends on anything else on this page.

kubectl describe pod inventory-worker -n ops | tail -15
# Warning  Unhealthy  kubelet  Liveness probe failed: Get "http://10.244.1.9:9090/healthz":
#          dial tcp 10.244.1.9:9090: connect: connection refused
# Normal   Killing    kubelet  Container inventory-worker failed liveness probe, will be restarted

kubectl logs inventory-worker -n ops --previous | grep -i listen
# level=info msg="listening" addr=":8080"    <-- the app actually listens on 8080, not 9090

kubectl edit deployment inventory-worker -n ops
#   livenessProbe:
#     httpGet:
#       path: /healthz
#-      port: 9090
#+      port: 8080

kubectl get pod inventory-worker -n ops -w
# inventory-worker   1/1   Running   0   45s   <-- restarts stopped climbing

kubectl describe node cka-mock-w1 | grep -A3 Conditions
# Ready   False   KubeletNotReady   PLEG is not healthy: ...

ssh cka-mock-w1
sudo systemctl status kubelet
# ● kubelet.service - active (running) but flapping
sudo journalctl -u kubelet -n 60 --no-pager -p err
# "container runtime network not ready" / cgroup driver mismatch reported by containerd

cat /etc/containerd/config.toml | grep -A1 SystemdCgroup
# SystemdCgroup = false        <-- kubelet is configured to expect systemd; this is out of step

sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
sudo systemctl restart containerd
sudo systemctl restart kubelet
kubectl get nodes
# cka-mock-w1   Ready   <none>   —   v1.35.0

ssh cka-mock-cp
sudo journalctl -u kubelet -n 60 --no-pager -p err
# "Error: unknown flag: --secure-port=644 3" — kubelet can't run the manifest, no API server to report it anywhere else

sudo crictl ps -a --name kube-apiserver
# CONTAINER   STATE      exited (1) 4 minutes ago

sudo cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep secure-port
# - --secure-port=644 3        <-- a stray space, turning one flag into a malformed value

sudo sed -i 's/--secure-port=644 3/--secure-port=6443/' /etc/kubernetes/manifests/kube-apiserver.yaml
# the kubelet watches this directory and restarts the static Pod on its own — no apply needed
sudo crictl ps -a --name kube-apiserver
# CONTAINER   STATE      Running

# from your own workstation
kubectl get nodes
# succeeds again

kubectl logs deployment/web-app -n ops --tail=5
# Error: configmaps "web-app-config" is forbidden: User "system:serviceaccount:ops:web-app"
#        cannot get resource "configmaps" in API group "" in the namespace "ops"

kubectl auth can-i get configmaps -n ops --as=system:serviceaccount:ops:web-app
# no

kubectl get role web-app-role -n ops -o yaml | grep -A4 resources
#   resources: ["pods"]        <-- Role never granted configmaps at all

kubectl patch role web-app-role -n ops --type=json \
  -p='[{"op":"add","path":"/rules/0/resources/-","value":"configmaps"}]'

kubectl auth can-i get configmaps -n ops --as=system:serviceaccount:ops:web-app
# yes

kubectl rollout restart deployment web-app -n ops
kubectl logs deployment/web-app -n ops --tail=5 --follow
# no more Forbidden errors

Score yourself

☺ Like you're 10: Add up your points, compare to the pass line, then look at which questions cost you — that second part is the part that actually helps next time.

Mark after a short break, not immediately — adrenaline makes for generous self-grading. Award full points only when the done-when check genuinely passed on your own cluster, half when the object exists and is broadly right but the check didn't pass clean, and zero for anything unattempted. "I knew how to do that one" earns nothing a passing check doesn't already prove.

Computing your result. The points total 100, so your raw score is your percentage, and the CKA's published pass mark has generally sat at 66% — confirm the current figure before treating it as gospel. That leaves roughly 34 points spendable: you could drop the entirety of Domain 4 and most of a second domain and still clear the bar, which is worth internalizing before panic sets in over any single missed task. Then do the more useful arithmetic and total each domain separately, because two candidates can both score 70 and be in completely different shape — one with a shallow, even gap across all five domains, the other with one domain at zero and the rest close to perfect. The second candidate has a specific, fixable hole; the first has a longer list of small ones.

What each miss means

☺ Like you're 10: There are three different reasons to lose points, and each one needs a different fix — guessing the wrong one wastes a week of studying the wrong thing.

Sort your zeros and halves into three piles before deciding what to re-study, because they call for genuinely different remedies. A task you didn't recognize the shape of at all is a real knowledge gap — go read the linked domain page, then redo that exact task cold in two or three days, not immediately while the answer is still fresh in short-term memory. A task where you knew roughly what to do but burned the clock hunting for a flag or a field name is a speed problem, not a knowledge one, and the fix is the kubectl fluency baseline and repetition, not another read of the blueprint. A task that broke in a way you couldn't diagnose — a command that errored strangely, evidence that didn't point anywhere — is a triage gap, and the fix is a troubleshooting methodology worked deliberately, evidence before guesses. One pattern sits outside all three: count how many tasks you left completely untouched. More than two or three, and the honest diagnosis is pacing, not knowledge — points you never got the chance to contest.

After this sitting

☺ Like you're 10: Only re-practice the parts you actually got wrong, and save the next full sitting for a little closer to the real day.

Resist re-drilling everything — the entire value of a scored, weighted paper is telling you where not to spend your next week. Take your one or two weakest domains, work only those sections of CKA Practice Tasks and the matching capstone part or drill, and leave the domains you already cleared alone. When you're ready for a genuinely cold rep, move to Set 2; keep Set 3 sealed until closer to your real exam date. For the logistics of the actual sitting — registration, the proctoring environment, and what candidates report about the day itself — this course's exam-day page covers it, and the study plan's resource table has second opinions on the same exam from Platform Engineering, SRE, and DevSecOps. Once CKA, CKAD, and CKS are all behind you, the wider Kubestronaut and Golden Kubestronaut ladder — the other nine CNCF certifications plus the LFCS — lives in the sibling Golden Astronaut course.

That's the paper. Build the lab cluster yourself, start one timer, and let the sixteen tasks above take you through two hours that should feel noticeably less comfortable than working through the blueprint pages untimed. Score it honestly, note your weakest domain, and spend your next study block exactly there — then come back for Set 2 when you're ready, or head to Kubernetes Certifications to plan the rest of the ladder.