CKA Mock Exam · Set 3

Your third full sitting, and the one built to expose a specific weakness: can you actually troubleshoot a cluster you can't fully trust, under a clock, with nothing but the tools the real exam allows? Twelve performance-based tasks in one unbroken 120-minute block, weighted like Set 1 and Set 2 across all five CKA domains — but this time Troubleshooting carries 39 of the 100 points, well above its already-large 30% exam weight, because that's the domain most candidates under-rehearse. Five of the twelve tasks hand you a cluster that is subtly, specifically broken — a certificate stuck mid-rotation, a DNS loop, a control-plane node that won't even let you run kubectl — and grade only the state you leave behind, exactly like the real thing. The other seven tasks are fresh build-from-scratch work across Cluster Architecture, Workloads, Networking and Storage, none of it repeated from Set 1 or Set 2. Every task has an objective done when check and a worked solution folded away until you've actually attempted it. Sit it honestly, total the sheet, and let the domain breakdown — not the raw score — choose what you study next.

Before you start — exam conditions

☺ Like you're 10: A fire drill only teaches you something if you run it for real — one timer, no peeking at the answer key, nobody standing next to you whispering the fix.

Build a throwaway cluster the night before — kubeadm on disposable VMs is closest to the real exam surface (you'll want real control-plane nodes for T5 and C1, which a single-node kind cluster can't fully exercise); a multi-node kind or minikube setup with at least one extra worker will cover everything else. Install a CNI that supports NetworkPolicy (Calico or Cilium — see Calico / Cilium) and ingress-nginx ahead of time; N1 and N2 need both. Start one 120-minute timer and don't pause it — a cluster that eats eight minutes of your time being uncooperative is itself realistic data, not an excuse to stop the clock. Keep only kubernetes.io/docs, kubernetes.io/blog, and whatever's in-cluster (kubectl explain, --help, existing objects) open — no search engine, no AI assistant, no notes from Set 1 or Set 2. Read all twelve tasks first; five minutes spent doing that is the highest-return five minutes of the sitting, because it's the only way to know which of the five troubleshooting tasks is going to eat the most time before you've committed to one.

Your time budget and domain weights

☺ Like you're 10: The clock gets split up ahead of time, the same way the points do — and this time the biggest slice by far goes to fixing things, not building them.

Compare this table with the five domain weights on the study plan: Cluster Architecture, Workloads, Networking and Storage are all slightly below their real exam weight on this specific paper, and Troubleshooting is well above it. That's deliberate for one sitting, not a claim about the real exam's own split — sit Set 1 or Set 2 if you want a paper weighted closer to the published curriculum.

Troubleshooting — T1 to T5 (39 points)

☺ Like you're 10: Every one of these five starts with something already wrong — your job isn't to build, it's to work out why the thing in front of you doesn't do what it's supposed to.

This block leans on the Troubleshooting blueprint page and a troubleshooting methodology — describe before logs, logs before exec, node before app — and on the muscle built in the broken-cluster, stuck-pod, networking-failure and failed-upgrade drills.

T1 · kubectl logs/exec fail against one node — a stuck kubelet-serving CSR (12 pts)

kubectl logs and kubectl exec against any pod scheduled on worker-3 fail with an x509 certificate error, while kubectl get nodes still shows worker-3 as Ready — its heartbeats, which use a different certificate, are unaffected.

Done when: kubectl get csr shows no CSR in Pending state for worker-3, and kubectl logs against a pod on that node succeeds.

kubectl get csr                                       # find the Pending one
kubectl describe csr <name>                            # confirm: requestor system:node:worker-3,
                                                        # signerName kubernetes.io/kubelet-serving
kubectl certificate approve <name>
kubectl get csr <name>                                 # Approved,Issued
kubectl logs -n default <a-pod-on-worker-3> --tail=1   # works now, no kubelet restart needed

T2 · A healthy app in CrashLoopBackOff — the probe is checking the wrong thing (6 pts)

web deployment pods are stuck CrashLoopBackOff. kubectl logs shows the app starting cleanly and serving on port 8000; nothing in the app log looks wrong.

Done when: the pods reach Running and stay there — restart count stops climbing for at least two probe intervals.

kubectl describe pod <pod> | grep -A3 Liveness         # Liveness probe failed: connection refused, port 8080
kubectl edit deploy web                                # livenessProbe.httpGet.port: 8080 → 8000
kubectl rollout status deploy/web

T3 · Pods stuck Pending on a dedicated node pool (6 pts)

Three nodes are labeled and tainted dedicated=batch:NoSchedule for the batch workload pool, correctly, for other tenants' protection. New batch-worker deployment pods that are supposed to run there are stuck Pending.

Done when: all batch-worker replicas are Running and scheduled only on the three tainted nodes — not spread onto any other node in the cluster.

# kubectl describe pod shows: 0/6 nodes are available: 3 node(s) had untolerated taint
# {dedicated: batch}. Fix the Deployment's pod template — do NOT remove the taint.
spec:
  template:
    spec:
      tolerations:
        - key: dedicated
          operator: Equal
          value: batch
          effect: NoSchedule
      nodeSelector:
        dedicated: batch          # tolerating the taint only says "may" — this says "must"

T4 · CoreDNS crash-looping with a Loop error (8 pts)

CoreDNS pods are restarting repeatedly. kubectl logs -n kube-system -l k8s-app=kube-dns shows a line ending Loop (127.0.0.1:53153 -> :53) detected for zone ".", see https://coredns.io/plugins/loop#troubleshooting.

Done when: CoreDNS pods are Running with a stable restart count, and kubectl run dns-test --image=busybox:1.36 --rm -it --restart=Never -- nslookup kubernetes.default resolves successfully.

kubectl -n kube-system get cm coredns -o yaml           # Corefile: forward . /etc/resolv.conf
cat /etc/resolv.conf                                    # on the node — nameserver points back
                                                          # at the cluster DNS Service's own ClusterIP
kubectl -n kube-system edit cm coredns
#   forward . /etc/resolv.conf   →   forward . 8.8.8.8 1.1.1.1
kubectl -n kube-system rollout restart deploy coredns

T5 · A typo in a static pod manifest locks out kubectl itself (7 pts)

After a routine flag change on the control-plane node, kubectl commands from your workstation all fail with connection refused. You still have SSH access to the control-plane node.

Done when: crictl ps on the control-plane node shows the kube-apiserver container Running and not restarting, and kubectl get nodes from your workstation succeeds again.

# kubectl itself is unusable while the API server is down — work on the node directly
sudo crictl ps -a | grep apiserver                       # container repeatedly exiting
sudo crictl logs <container-id>
# Error: unknown flag: --etcd-server=https://127.0.0.1:2379   (missing the trailing "s")
sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
#   --etcd-server=...   →   --etcd-servers=...
# no "kubectl apply" needed or possible here — the kubelet's static pod manager
# watches this exact file and recreates the pod automatically on save
sudo crictl ps | grep apiserver                           # Running, stable
kubectl get nodes

Cluster Architecture, Installation & Configuration — C1 to C2 (22 points)

☺ Like you're 10: These two are the "keep the whole cluster's memory safe" and "give people only the keys they actually need" tasks — both are on almost every real CKA sitting.

Background: the D1 blueprint page, control-plane internals, and RBAC & admission control.

C1 · Snapshot and restore etcd (13 pts)

Your task: take an etcdctl snapshot of the running cluster's etcd, then restore it into a fresh data directory and repoint the etcd static pod at that directory — proving you can recover the cluster's entire state, not just back it up.

Done when: ETCDCTL_API=3 etcdctl --write-out=table snapshot status /tmp/etcd-backup.db shows a valid revision count, and after the restore, kubectl get all -A against the cluster still returns the same objects it did before the snapshot.

ETCDCTL_API=3 etcdctl snapshot save /tmp/etcd-backup.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
ETCDCTL_API=3 etcdctl --write-out=table snapshot status /tmp/etcd-backup.db

ETCDCTL_API=3 etcdctl snapshot restore /tmp/etcd-backup.db \
  --data-dir=/var/lib/etcd-restored

sudo vi /etc/kubernetes/manifests/etcd.yaml
#   hostPath for the etcd-data volume: /var/lib/etcd  →  /var/lib/etcd-restored
# kubelet's static pod manager restarts etcd automatically once the manifest is saved
sudo crictl ps | grep etcd
kubectl get all -A

C2 · Scope a CI service account with RBAC, not cluster admin (9 pts)

A CI pipeline currently deploys using a ClusterRoleBinding to cluster-admin — far more than it needs. It only ever creates, updates and reads Deployments and Pods, and only inside the build namespace.

Done when: kubectl auth can-i create deployments -n build --as=system:serviceaccount:build:ci-deployer returns yes, and kubectl auth can-i list secrets -A --as=system:serviceaccount:build:ci-deployer returns no.

apiVersion: v1
kind: ServiceAccount
metadata: { name: ci-deployer, namespace: build }
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: deployer, namespace: build }
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: { name: deployer-binding, namespace: build }
subjects:
  - kind: ServiceAccount
    name: ci-deployer
    namespace: build
roleRef: { kind: Role, name: deployer, apiGroup: rbac.authorization.k8s.io }

kubectl delete clusterrolebinding ci-cluster-admin       # remove the over-broad binding
kubectl apply -f rbac.yaml
kubectl auth can-i create deployments -n build --as=system:serviceaccount:build:ci-deployer   # yes
kubectl auth can-i list secrets -A --as=system:serviceaccount:build:ci-deployer                # no

Workloads & Scheduling — W1 to W2 (13 points)

☺ Like you're 10: One teaches the cluster to grow and shrink a service on its own; the other teaches it to spread copies out instead of stacking them all in one place.

Background: the D2 blueprint page, scheduling & resource management, and autoscaling.

W1 · Autoscale a Deployment on CPU (7 pts)

The web Deployment (from T2, now healthy) needs to scale between 2 and 8 replicas, targeting 60% average CPU utilization.

Done when: kubectl get hpa web shows a real TARGETS percentage (not <unknown>) and the configured min/max replicas.

# the trap: metrics-server can't compute a percentage without a requests.cpu baseline
kubectl set resources deploy web --requests=cpu=200m --limits=cpu=500m
kubectl autoscale deploy web --cpu-percent=60 --min=2 --max=8
kubectl get hpa web -w

W2 · Spread replicas evenly across zones (6 pts)

web currently has all its replicas landing on nodes in a single zone — a single zone outage would take the whole service down. Nodes are labeled topology.kubernetes.io/zone across three zones.

Done when: after scaling to 6 replicas, no zone holds more than one extra pod compared to any other zone (kubectl get pods -o wide cross-referenced with node zone labels).

spec:
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels: { app: web }

Services & Networking — N1 to N2 (16 points)

☺ Like you're 10: One task teaches the cluster to say no by default and yes to one specific visitor; the other teaches it to send different visitors to different rooms based on the address they asked for.

Background: the D3 blueprint page and networking & the CNI.

N1 · Default-deny ingress, then allow one caller (8 pts)

The payments namespace currently allows ingress from anywhere. Lock it down so only pods labeled role: frontend, in the same namespace, can reach it on tcp/8443 — everything else should be refused.

Done when: a request from a pod labeled role: frontend to a payments pod on 8443 succeeds, and the same request from an unlabeled pod times out.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny-ingress, namespace: payments }
spec:
  podSelector: {}
  policyTypes: [Ingress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: allow-frontend, namespace: payments }
spec:
  podSelector: {}
  policyTypes: [Ingress]
  ingress:
    - from: [{ podSelector: { matchLabels: { role: frontend } } }]
      ports: [{ protocol: TCP, port: 8443 }]

N2 · Route two paths on one host through Ingress (8 pts)

Two Services, api-svc and web-svc, both listening on port 80, need to be reachable behind one Ingress on host shop.internal — /api to api-svc, / to web-svc.

Done when: curl -H "Host: shop.internal" http://<ingress-controller-ip>/api/health and curl -H "Host: shop.internal" http://<ingress-controller-ip>/ reach the correct Service respectively.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  annotations: { nginx.ingress.kubernetes.io/rewrite-target: /$2 }
spec:
  ingressClassName: nginx
  rules:
    - host: shop.internal
      http:
        paths:
          - path: /api(/|$)(.*)
            pathType: ImplementationSpecific
            backend: { service: { name: api-svc, port: { number: 80 } } }
          - path: /
            pathType: Prefix
            backend: { service: { name: web-svc, port: { number: 80 } } }

Storage — S1 (10 points)

☺ Like you're 10: A PVC sitting at "Pending" isn't always broken — sometimes it's doing exactly what you told it to do, and this task is about knowing the difference.

Background: the D4 blueprint page and storage & the CSI.

S1 · A PVC that's correctly Pending, until it isn't (10 pts)

Create a StorageClass named fast-local using a provisioner with volumeBindingMode: WaitForFirstConsumer, then a PVC requesting 1Gi against it. Explain — and prove — why kubectl get pvc shows Pending immediately after creation, then get it bound.

Done when: the PVC shows Pending right after creation with no Pod referencing it, and shows Bound once a Pod that mounts it exists.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata: { name: fast-local }
provisioner: rancher.io/local-path        # or your cluster's own dynamic provisioner
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: data-claim }
spec:
  storageClassName: fast-local
  accessModes: [ReadWriteOnce]
  resources: { requests: { storage: 1Gi } }

kubectl apply -f sc-and-pvc.yaml
kubectl get pvc data-claim                # STATUS Pending — correct, nothing consumes it yet
kubectl run reader --image=busybox --restart=Never --overrides='
{"spec":{"containers":[{"name":"reader","image":"busybox","command":["sleep","3600"],
"volumeMounts":[{"name":"d","mountPath":"/data"}]}],
"volumes":[{"name":"d","persistentVolumeClaim":{"claimName":"data-claim"}}]}}'
kubectl get pvc data-claim                # STATUS Bound, now that a Pod references it

Score yourself

☺ Like you're 10: Add up the points, but look harder at whether your misses are clustered in Troubleshooting — that's the domain this whole paper was built to test.

Mark only after attempting all twelve. Full credit only when the done-when check actually passes on your cluster — partial YAML that never got applied, or a fix you believe worked but never verified, scores nothing, exactly as the real exam grades it.

The real CKA's published pass mark is 66% — this paper uses the same number as a study reference. Below that here, don't just re-read the explanations above; that teaches you these twelve exact answers, not the underlying skill. Go re-run the matching drill instead: T1/T5 point back to fix a broken cluster, T2/T3 to debug a stuck pod, T4/N1/N2 to diagnose a networking failure, C1 to troubleshoot a failed upgrade, C2 to harden an RBAC configuration, and S1 to recover from a storage incident.

That's Set 3. If your misses clustered in Troubleshooting, that's this paper doing its job — loop back to weeks 7–8 of the study plan and the drills linked above before your next sitting rather than re-reading this page's answer key on its own. For a paper weighted closer to the plain exam blueprint, sit Set 1 or Set 2; for shorter, single-topic reps instead of a full timed paper, see CKA Practice Tasks.