CKA Mock Exam · Set 2

This is the second of this course's full-length CKA practice papers, and every scenario on it is new — none of the 17 tasks below repeats a task from Set 1, so sitting this one is a genuine second measurement, not a replay of something you already half-remember. Same rules as the real thing: a 120-minute block on a live cluster, tasks weighted exactly like the official curriculum's five domains (30/25/20/15/10%), and every task graded the way the real exam grades it — on the state you leave the cluster in, checked by an objective done when command you can run yourself. Worked solutions sit folded under each task so you can sit the paper honestly and mark it afterward. Total the 100 points, compare against the 66% pass mark, and let your domain breakdown — not the raw number — tell you what to study next.

Before you start — sitting conditions

☺ Like you're 10: This only works as practice if you play it by the real rules — one clock, no notes, no help, and you don't get to peek at the answer before you've committed to one.

Build a throwaway multi-node lab first — kubeadm on disposable VMs is closest to the real environment, or a multi-node kind cluster if VMs aren't available; a handful of tasks below assume you can reach a node's shell directly (SSH or docker exec into a kind node), so a single-node cluster with no separate worker won't let you sit every task honestly. Start one timer for the full 120 minutes and don't pause it — not for a stuck terminal, not for a coffee. Keep only kubernetes.io/docs open, since that's the allowlisted documentation you're permitted during the real exam — no notes, no this course, no AI assistant. Read all 17 tasks first; five minutes spent scanning the whole paper is what lets you bank the two-minute tasks before you burn twelve on one stubborn manifest.

Your 120-minute budget

☺ Like you're 10: Give each section a slice of the clock sized to how much of your grade it's worth — and if a task blows way past its slice, flag it and move on, you can always come back.

Seventeen tasks in 120 minutes isn't an even split — it's sized to the same weights the real curriculum uses, so a slow task in Troubleshooting costs you more attention than a slow task in Storage, and the budget below reflects that on purpose.

There's no folded worked solution to sneak a look at mid-paper the way this write-up presents them — each task's solution sits directly beneath its done-when check, so the only discipline required is not opening it before you've committed to your own attempt.

🦉 Cluster Architecture, Installation & Configuration — T1–T4 (25 points)

☺ Like you're 10: This section is about building and maintaining the cluster itself — adding a machine to it, upgrading it, backing it up, and deciding who's allowed to touch what.

Background reading, after the sitting, not during it: the D1 blueprint page, the kubeadm tool guide, and control-plane internals.

T1 · Join a worker node and dedicate it to ingress (7 points · 8 min)

Platform has provisioned a fresh VM, worker-04, that must join the existing kubeadm cluster and then be reserved exclusively for ingress-controller workloads — nothing else should ever land there.

Your task:

1. On the control-plane node, generate a fresh bootstrap token good for one hour and print the full kubeadm join command it produces.
2. Run that join command on worker-04.
3. Once the node is Ready, label it role=ingress and taint it dedicated=ingress:NoSchedule so nothing else schedules there by accident.

Done when: kubectl get node worker-04 shows Ready, carries the role=ingress label, and kubectl describe node worker-04 lists the dedicated=ingress:NoSchedule taint. (7 points)

# on the control-plane node
kubeadm token create --ttl 1h --print-join-command

# on worker-04, using the exact output from the command above
sudo kubeadm join 10.0.4.10:6443 --token abcdef.0123456789abcdef \
  --discovery-token-ca-cert-hash sha256:9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a1

kubectl label node worker-04 role=ingress
kubectl taint node worker-04 dedicated=ingress:NoSchedule
kubectl get node worker-04 -o wide
kubectl describe node worker-04 | grep -A2 Taints

T2 · Upgrade a control-plane node with kubeadm (6 points · 7 min)

The cluster's single control-plane node, cp-01, is running v1.30.4 and needs to move to v1.30.6 before a security fix lands.

Your task:

1. Drain cp-01 safely, ignoring DaemonSets and allowing local emptyDir data to be deleted.
2. Upgrade the kubeadm package to 1.30.6, run kubeadm upgrade plan, then apply the upgrade.
3. Upgrade the kubelet and kubectl packages to match, restart kubelet, and uncordon the node.

Done when: kubectl get nodes shows cp-01 at v1.30.6 with status Ready (not SchedulingDisabled). (6 points)

kubectl drain cp-01 --ignore-daemonsets --delete-emptydir-data

apt-mark unhold kubeadm
apt-get update && apt-get install -y kubeadm=1.30.6-1.1
apt-mark hold kubeadm

kubeadm upgrade plan
kubeadm upgrade apply v1.30.6

apt-mark unhold kubelet kubectl
apt-get install -y kubelet=1.30.6-1.1 kubectl=1.30.6-1.1
apt-mark hold kubelet kubectl

systemctl daemon-reload
systemctl restart kubelet

kubectl uncordon cp-01
kubectl get nodes

T3 · Take and verify an etcd snapshot (6 points · 7 min)

Before a risky config change, the team wants a fresh, verified etcd snapshot on disk — not a snapshot nobody has actually confirmed is readable.

Your task:

1. Using the correct etcd peer certificates and the local etcd endpoint, save a snapshot to /var/backups/etcd-snapshot.db.
2. Verify the snapshot's integrity with etcdutl, without touching the live cluster.
3. Confirm the reported revision and hash are present with no errors.

Done when: the snapshot file exists at that path and etcdutl snapshot status /var/backups/etcd-snapshot.db --write-out=table prints a table with a hash and nonzero revision, with no error. (6 points)

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

T4 · Scope a ServiceAccount with least-privilege RBAC (6 points · 7 min)

A CI pipeline needs a ServiceAccount, ci-bot, in namespace ci that can watch Pods and create Events — and nothing more. It must not be able to delete anything.

Your task:

1. Create the namespace ci and a ServiceAccount ci-bot inside it.
2. Create a Role (not a ClusterRole) granting get/list/watch on Pods and create on Events, in that namespace only.
3. Bind it to ci-bot with a RoleBinding, and prove both what it can and can't do.

Done when: kubectl auth can-i list pods --as=system:serviceaccount:ci:ci-bot -n ci prints yes, and kubectl auth can-i delete pods --as=system:serviceaccount:ci:ci-bot -n ci prints no. (6 points)

kubectl create ns ci
kubectl create sa ci-bot -n ci

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-watcher
  namespace: ci
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ci-bot-pod-watcher
  namespace: ci
subjects:
  - kind: ServiceAccount
    name: ci-bot
    namespace: ci
roleRef:
  kind: Role
  name: pod-watcher
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f pod-watcher-rbac.yaml
kubectl auth can-i list pods --as=system:serviceaccount:ci:ci-bot -n ci
kubectl auth can-i delete pods --as=system:serviceaccount:ci:ci-bot -n ci

🦫 Workloads & Scheduling — T5–T7 (15 points)

☺ Like you're 10: This section is about how your actual applications run — rolling out a new version safely, undoing a bad one, putting the right work on the right machine, and running scheduled jobs without them tripping over each other.

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

T5 · Roll out, break, and roll back to a specific revision (5 points · 6 min)

The catalog Deployment needs a zero-downtime rollout strategy, then a deliberately broken update, then a rollback to a specific known-good revision — not just "one step back."

Your task:

1. Create Deployment catalog, image nginx:1.25, 4 replicas, with maxSurge: 1 and maxUnavailable: 0, and record the change cause.
2. Update the image to nginx:1.26 (revision 2), then to a nonexistent tag nginx:broken-tag-9999 (revision 3), recording a change cause each time.
3. Roll back directly to revision 2, not to the immediately previous revision.

Done when: kubectl rollout status deploy/catalog reports success and kubectl get deploy catalog -o jsonpath='{.spec.template.spec.containers[0].image}' prints nginx:1.26. (5 points)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: catalog
spec:
  replicas: 4
  selector:
    matchLabels: { app: catalog }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels: { app: catalog }
    spec:
      containers:
        - name: nginx
          image: nginx:1.25

kubectl apply -f catalog.yaml
kubectl annotate deploy catalog kubernetes.io/change-cause="initial release"

kubectl set image deploy/catalog nginx=nginx:1.26
kubectl annotate deploy catalog kubernetes.io/change-cause="routine bump" --overwrite
kubectl rollout status deploy/catalog

kubectl set image deploy/catalog nginx=nginx:broken-tag-9999
kubectl annotate deploy catalog kubernetes.io/change-cause="bad release" --overwrite

kubectl rollout history deploy/catalog
kubectl rollout undo deploy/catalog --to-revision=2
kubectl rollout status deploy/catalog
kubectl get deploy catalog -o jsonpath='{.spec.template.spec.containers[0].image}'

T6 · Dedicate a node to a workload with affinity and a taint (5 points · 6 min)

A memory-hungry batch Pod, cruncher, must run only on highmem-01 — a node tainted and labeled specifically for this class of work — and must request 2 CPU / 2Gi with a 4Gi memory limit.

Your task:

1. Label highmem-01 with hardware=highmem and taint it workload=highmem:NoSchedule.
2. Write Pod cruncher with a matching toleration, a requiredDuringSchedulingIgnoredDuringExecution node affinity for hardware=highmem, and the resource requests/limits above.
3. Confirm it lands specifically on highmem-01, not just any untainted node.

Done when: kubectl get pod cruncher -o wide shows NODE=highmem-01 and Running. (5 points)

kubectl label node highmem-01 hardware=highmem
kubectl taint node highmem-01 workload=highmem:NoSchedule

apiVersion: v1
kind: Pod
metadata:
  name: cruncher
spec:
  tolerations:
    - key: workload
      operator: Equal
      value: highmem
      effect: NoSchedule
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: hardware
                operator: In
                values: ["highmem"]
  containers:
    - name: cruncher
      image: busybox:1.36
      command: ["sleep", "3600"]
      resources:
        requests: { cpu: "2", memory: 2Gi }
        limits: { cpu: "2", memory: 4Gi }

kubectl apply -f cruncher.yaml
kubectl get pod cruncher -o wide

T7 · Prevent overlapping CronJob runs (5 points · 6 min)

A reconciliation job sometimes overlaps with the previous run still finishing, causing double writes. The team wants overlapping runs skipped outright, a hard cap on run time, and limited retries.

Your task:

1. Create CronJob reconcile, schedule * * * * *, with concurrencyPolicy: Forbid.
2. Its job template should sleep 90 seconds (to guarantee overlap with the next minute's tick), with backoffLimit: 2 and activeDeadlineSeconds: 120.
3. Watch two consecutive ticks and confirm the second is skipped while the first is still running.

Done when: across two consecutive scheduled ticks, kubectl get pods -l job-name --watch shows no more than one reconcile pod running at once, and kubectl describe cronjob reconcile shows an event noting a skipped run. (5 points)

apiVersion: batch/v1
kind: CronJob
metadata:
  name: reconcile
spec:
  schedule: "* * * * *"
  concurrencyPolicy: Forbid
  startingDeadlineSeconds: 30
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 120
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: reconcile
              image: busybox:1.36
              command: ["sh", "-c", "sleep 90 && echo done"]

kubectl apply -f reconcile-cronjob.yaml
kubectl get pods -w   # second tick produces no new pod while the first is still sleeping
kubectl describe cronjob reconcile   # Events: skipped run because of ConcurrencyPolicy Forbid

🐦 Services & Networking — T8–T10 (20 points)

☺ Like you're 10: This section is about how traffic actually finds its way to your pods — locking most of it out by default, opening one exact door, and routing outside requests to the right service by name.

Background: the D3 blueprint page, networking & the CNI, and the ingress-nginx tool guide.

T8 · Default-deny a namespace, then open one exact hole (7 points · 8 min)

Namespace billing needs to default-deny all ingress and egress, then allow exactly two things: inbound traffic from pods labeled app=api-gateway on port 8443, and outbound traffic to the billing-db pods on port 5432 plus DNS to kube-system.

Your task:

1. Write a default-deny-all NetworkPolicy for billing covering both directions.
2. Write a policy allowing ingress from app=api-gateway on TCP 8443 only.
3. Write a policy allowing egress to app=billing-db on TCP 5432, and to kube-system on UDP/TCP 53 for DNS.

Done when: a test pod labeled app=api-gateway can curl a billing pod on 8443, an unlabeled test pod in the same namespace times out on the same request, and DNS resolution still works from inside billing. (7 points)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: billing
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-gateway
  namespace: billing
spec:
  podSelector: {}
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: api-gateway }
      ports:
        - protocol: TCP
          port: 8443
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-db-and-dns
  namespace: billing
spec:
  podSelector: {}
  policyTypes: ["Egress"]
  egress:
    - to:
        - podSelector:
            matchLabels: { app: billing-db }
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: kube-system }
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

kubectl apply -f netpols.yaml
kubectl run allowed --image=curlimages/curl -n billing -l app=api-gateway --command -- sleep 3600
kubectl run denied  --image=curlimages/curl -n billing --command -- sleep 3600
kubectl exec -n billing allowed -- curl -sm3 -k https://billing-svc:8443
kubectl exec -n billing denied  -- curl -sm3 -k https://billing-svc:8443   # should time out

T9 · Split internal and external access to the same workload (7 points · 8 min)

The reports API needs ordinary cluster-internal access on its own stable DNS name, plus one specific, pinned NodePort — 30080 — for a legacy on-prem probe that can't reach an Ingress.

Your task:

1. Create Deployment reports (2 replicas) listening on 8080.
2. Create ClusterIP Service reports-internal, port 80 → targetPort 8080.
3. Create a second Service, reports-external, type NodePort, same selector, with nodePort: 30080 pinned explicitly.

Done when: kubectl exec test -- curl -s reports-internal.default.svc.cluster.local succeeds from inside the cluster, and curl -s http://<any-node-ip>:30080/ succeeds from a node's own shell. (7 points)

kubectl create deployment reports --image=hashicorp/http-echo --replicas=2 -- -text="reports-ok"

apiVersion: v1
kind: Service
metadata:
  name: reports-internal
spec:
  selector: { app: reports }
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: reports-external
spec:
  type: NodePort
  selector: { app: reports }
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

kubectl apply -f reports-services.yaml
kubectl run test --image=curlimages/curl --command -- sleep 3600
kubectl exec test -- curl -s reports-internal.default.svc.cluster.local

NODE_IP=$(kubectl get node worker-01 -o jsonpath='{.status.addresses[?(@.type=="InternalIP")].address}')
curl -s http://$NODE_IP:30080/

T10 · Route two hostnames through one Ingress (6 points · 7 min)

A single ingress-nginx controller is already installed cluster-wide. It needs to front two backends: shop.example.internal at /, and admin.example.internal at /console, with anything unmatched falling through to the default 404.

Your task:

1. Write Ingress storefront with ingressClassName: nginx, routing shop.example.internal → shop-svc:80 and admin.example.internal/console → admin-console-svc:8080.
2. Use curl --resolve to test both hostnames against the controller's IP without editing DNS.
3. Confirm an unmatched hostname returns the default backend's 404.

Done when: both curl --resolve requests above return their respective backend's response, and a third, unmatched hostname returns 404. (6 points)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: storefront
spec:
  ingressClassName: nginx
  rules:
    - host: shop.example.internal
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service: { name: shop-svc, port: { number: 80 } }
    - host: admin.example.internal
      http:
        paths:
          - path: /console
            pathType: Prefix
            backend:
              service: { name: admin-console-svc, port: { number: 8080 } }

kubectl apply -f storefront-ingress.yaml
INGRESS_IP=$(kubectl -n ingress-nginx get svc ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

curl --resolve shop.example.internal:80:$INGRESS_IP http://shop.example.internal/
curl --resolve admin.example.internal:80:$INGRESS_IP http://admin.example.internal/console/
curl --resolve nowhere.example.internal:80:$INGRESS_IP http://nowhere.example.internal/   # default backend 404

🐘 Storage — T11–T12 (10 points)

☺ Like you're 10: This section is about disks that outlive the pod using them — making one grow safely while it's in use, and fixing a claim that's stuck refusing to match an existing disk.

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

T11 · A retained, resizable volume for compliance logs (5 points · 6 min)

An audit-log volume must survive Pod and PVC deletion — compliance requires the disk isn't auto-reclaimed — and must grow without downtime as log volume increases.

Your task:

1. Create StorageClass audit-retain with reclaimPolicy: Retain and allowVolumeExpansion: true.
2. Create PVC audit-logs (5Gi) using it, mounted into Pod auditor at /var/log/audit.
3. Expand the PVC to 8Gi and confirm the filesystem inside the pod actually grew — not just the PVC object's requested size.

Done when: kubectl get pvc audit-logs -o jsonpath='{.status.capacity.storage}' prints 8Gi, and kubectl exec auditor -- df -h /var/log/audit shows roughly 8G available. (5 points)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: audit-retain
provisioner: rancher.io/local-path   # swap for your cluster's actual CSI driver
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: audit-logs
spec:
  storageClassName: audit-retain
  accessModes: ["ReadWriteOnce"]
  resources:
    requests: { storage: 5Gi }
---
apiVersion: v1
kind: Pod
metadata:
  name: auditor
spec:
  containers:
    - name: auditor
      image: busybox:1.36
      command: ["sleep", "3600"]
      volumeMounts:
        - name: logs
          mountPath: /var/log/audit
  volumes:
    - name: logs
      persistentVolumeClaim: { claimName: audit-logs }

kubectl apply -f audit-storage.yaml
kubectl patch pvc audit-logs -p '{"spec":{"resources":{"requests":{"storage":"8Gi"}}}}'
kubectl get pvc audit-logs -w
kubectl exec auditor -- df -h /var/log/audit

kubectl delete pvc audit-logs
kubectl get pv   # the PV is Released, not gone — Retain honored

T12 · Fix a PVC stuck Pending against a static PV (5 points · 6 min)

A legacy dataset already has a pre-provisioned static PV, archive-pv (5Gi, ReadWriteOnce, storageClassName: manual). A PVC written against it, archive-claim, has been Pending for an hour, and Pod archive-reader is stuck waiting on it.

Your task:

1. Diagnose why archive-claim won't bind to archive-pv.
2. Correct the mismatch — the PVC's spec is largely immutable once created, so delete and recreate it with matching values.
3. Confirm the Pod becomes Running.

Done when: kubectl get pvc archive-claim -o jsonpath='{.status.phase}' prints Bound and kubectl get pod archive-reader -o jsonpath='{.status.phase}' prints Running. (5 points)

kubectl describe pvc archive-claim   # Events: no persistent volumes available for this claim
kubectl get pv archive-pv -o yaml | grep -E "capacity|storageClassName|accessModes"
# archive-pv: 5Gi, manual, ReadWriteOnce — but archive-claim requested 10Gi, too large to bind statically

kubectl delete pvc archive-claim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: archive-claim
spec:
  storageClassName: manual
  accessModes: ["ReadWriteOnce"]
  resources:
    requests: { storage: 5Gi }

kubectl apply -f archive-claim.yaml
kubectl get pvc archive-claim
kubectl get pod archive-reader

🦊 Troubleshooting — T13–T17 (30 points)

☺ Like you're 10: This is the biggest section on purpose — something is broken, and your job is to find out why using only what the cluster tells you, fix the actual cause, and prove it's actually fixed.

The largest domain, and it's a method more than a new set of facts: node before app, describe before logs, logs before exec. Background: the D5 blueprint page and a troubleshooting methodology.

T13 · Recover a NotReady node (6 points · 5 min)

worker-03 shows NotReady, and every pod scheduled there is stuck. Recently someone changed the container runtime's cgroup driver without updating the kubelet to match.

Your task:

1. Confirm the node condition from the control plane, then check kubelet's status on worker-03 itself.
2. Read the kubelet's journal to find the actual failure reason.
3. Correct the mismatch and confirm the node returns to Ready.

Done when: kubectl get node worker-03 shows Ready, and previously-Pending pods on that node move to Running. (6 points)

kubectl describe node worker-03 | grep -A5 Conditions

# on worker-03
systemctl status kubelet
journalctl -u kubelet -n 50 --no-pager
# ... misconfiguration: kubelet cgroup driver "cgroupfs" is different from the container runtime cgroup driver "systemd"

sudo sed -i 's/cgroupDriver: cgroupfs/cgroupDriver: systemd/' /var/lib/kubelet/config.yaml
sudo systemctl daemon-reload
sudo systemctl restart kubelet
systemctl status kubelet

# back on the control plane
kubectl get node worker-03 -w
kubectl get pods -A -o wide --field-selector spec.nodeName=worker-03

T14 · Fix an ImagePullBackOff behind a private registry (6 points · 5 min)

Every pod in the payments Deployment is stuck ImagePullBackOff, pulling from a private registry.

Your task:

1. Read the pod events to identify the exact failure — a bad tag, a missing pull secret, or an unreachable registry are three different fixes.
2. If it's an authentication failure, create the missing registry credentials and attach them so every future pod in the namespace inherits them.
3. Confirm the pods recover without editing the Deployment's own template.

Done when: kubectl get pods -n payments -l app=payments shows all pods Running, with no further pull errors in their events. (6 points)

kubectl describe pod -n payments payments-7d8f9-abcde | tail -20
# Events: Failed to pull image "registry.acme.internal/payments:4.2.0": ... 401 Unauthorized

kubectl create secret docker-registry acme-registry \
  --docker-server=registry.acme.internal \
  --docker-username=ci-bot \
  --docker-password="$REGISTRY_TOKEN" \
  -n payments

kubectl patch sa default -n payments \
  -p '{"imagePullSecrets":[{"name":"acme-registry"}]}'

kubectl rollout restart deploy/payments -n payments
kubectl get pods -n payments -l app=payments -w

T15 · Fix a Service with no endpoints (6 points · 5 min)

The orders Service in namespace orders times out on every request, even though its backing pods are all Running.

Your task:

1. Check whether the Service actually has any endpoints.
2. Compare the Service's selector against the real Pod labels to find the mismatch.
3. Fix the Service — not the Pods, which the Deployment already owns and would just re-diverge.

Done when: kubectl get endpoints orders -n orders lists non-empty pod IPs, and kubectl exec test -n orders -- curl -s orders.orders.svc.cluster.local succeeds. (6 points)

kubectl get endpoints orders -n orders   # <none>
kubectl get svc orders -n orders -o jsonpath='{.spec.selector}'
kubectl get pods -n orders --show-labels
# svc selector: app=orders-api  —  actual pod label: app=orders

kubectl patch svc orders -n orders -p '{"spec":{"selector":{"app":"orders"}}}'
kubectl get endpoints orders -n orders
kubectl exec -n orders test -- curl -s orders.orders.svc.cluster.local

T16 · Fix a CrashLoopBackOff caused by the probe, not the app (6 points · 5 min)

The inventory Deployment keeps restarting. Its logs look completely healthy right up until each kill.

Your task:

1. Read the pod's events for the liveness probe's failure reason, and its previous logs to see what the app was actually doing before it was killed.
2. Compare the probe's target port against the port the app is really listening on.
3. Correct the Deployment's probe and confirm restarts stop.

Done when: kubectl get pods -n inventory -l app=inventory shows RESTARTS not incrementing over at least two minutes, with no new Liveness failures in kubectl describe pod. (6 points)

kubectl describe pod -n inventory inventory-6c9d-xyz | grep -A5 Liveness
# Liveness probe failed: Get "http://10.244.1.9:8080/healthz": dial tcp ... connection refused

kubectl logs -n inventory inventory-6c9d-xyz --previous
# inventory listening on :9090

kubectl patch deploy inventory -n inventory --type=json \
  -p='[{"op":"replace","path":"/spec/template/spec/containers/0/livenessProbe/httpGet/port","value":9090}]'

kubectl rollout status deploy/inventory -n inventory
kubectl get pods -n inventory -l app=inventory -w

T17 · Fix a broken static-pod control-plane component (6 points · 5 min)

After a manual edit, kube-scheduler is CrashLoopBackOff in kube-system. New pods across the cluster stay Pending — nothing is deciding placement.

Your task:

1. Check the scheduler's previous logs for its actual startup error.
2. Find and correct the bad flag in its static-pod manifest on the control-plane node's disk.
3. Confirm the kubelet picks up the fix on its own and scheduling resumes.

Done when: kubectl get pods -n kube-system -l component=kube-scheduler is Running with no new restarts, and a freshly created Pod with no nodeName set leaves Pending promptly. (6 points)

kubectl get pods -n kube-system -l component=kube-scheduler
kubectl logs -n kube-system kube-scheduler-cp-01 --previous
# invalid value "999.999.999.999" for flag --bind-address

# on the control-plane node
sudo grep bind-address /etc/kubernetes/manifests/kube-scheduler.yaml
sudo sed -i 's/--bind-address=999.999.999.999/--bind-address=127.0.0.1/' /etc/kubernetes/manifests/kube-scheduler.yaml

kubectl get pods -n kube-system -w -l component=kube-scheduler
kubectl run probe --image=busybox:1.36 --command -- sleep 60
kubectl get pod probe -o wide   # should leave Pending promptly once the scheduler is healthy again

Score yourself

☺ Like you're 10: Add up your points, then do the more useful thing: look at which section lost the most points and go study that section, not the whole syllabus again.

Mark after a short break — grading your own work while still adrenalized from the clock produces generous nonsense. Award full points only when the done-when check actually passed on your cluster, half credit when the resource exists and is broadly right but the check didn't pass, and zero for anything unattempted.

Computing your result. The points total 100, so your raw score is your percentage, and the pass mark is 66%. That leaves 34 points spendable — but the more useful arithmetic is per domain, not total: a 70 built from five roughly even domains and a 70 built from four strong domains plus a zeroed-out Troubleshooting are completely different results, and the second one fails the real exam the day the task draw is unkind.

What your score means

☺ Like you're 10: One number doesn't predict a pass — but the shape of it tells you exactly what to practice next, which is more useful anyway.

One pattern worth checking independent of the total: how many tasks did you leave completely unattempted? More than two, and your problem is pacing rather than knowledge — the cheapest thing on this list to fix. Sit a paper again in a week with a hard rule that you touch every task once before returning to any of them.

That's the whole paper. Score it, write your domain breakdown somewhere you'll actually see it again, and let the two weakest numbers pick your next week of practice. When the numbers stop moving, the remaining work is logistical, not technical: exam day — proctoring & environment covers the sitting itself, Field Notes collects what people actually reported afterward, and the exam-prep checklist is the last thing worth reading before you sit down. See the same domains explained from a different angle on Platform Engineering's CKA page, SRE's CKA page, and DevSecOps's CKA page — and if the CKA is one stop on the way to the full ladder, see the Golden Astronaut course for the other nine CNCF certs plus the LFCS.