CKAD Mock Exam · Set 2

Your second full sitting — same shape as Set 1, entirely new scenarios. Twelve performance-based tasks in one unbroken 120-minute block, weighted to the CKAD curriculum's own 20/20/15/25/20 domain split so the time you spend here maps honestly onto the real exam, not onto whichever domain happens to be easiest to write questions for. Application Environment, Configuration and Security still carries the single largest share — 25 of the 100 points — because it does on the real exam too, not because this paper leans on it deliberately the way a troubleshooting-heavy sitting might. Every task builds or fixes something that actually runs: a multi-container Pod, a blue/green cutover on a live Service, an immutable ConfigMap you can't just edit in place, a Deployment quietly starved by its own namespace's ResourceQuota, a cross-namespace NetworkPolicy. Each has an objective done when check and a worked solution folded away until you've genuinely attempted it. Sit it cold, total the sheet against the published pass mark, and let the domain breakdown decide what you study next — not the raw number.

Before you start — exam conditions

☺ Like you're 10: A dress rehearsal only teaches you something if you actually run the full play — one clock, no script in your pocket, nobody feeding you lines.

Build a disposable cluster the night before: a multi-node kind or minikube setup covers everything here. Install ingress-nginx and a NetworkPolicy-enforcing CNI — Calico or Cilium, N3 needs it, the default bridge silently ignores NetworkPolicy objects — and confirm both helm and kustomize are on your PATH ahead of time; D1 and D2 need them ready, not something you're installing mid-clock. Start one 120-minute timer and don't pause it. Keep only kubernetes.io/docs, kubernetes.io/blog, and — since this is CKAD — the Helm documentation open, matching the real exam's permitted-resource list; no search engine, no AI assistant, no notes from Set 1. Read all twelve tasks first: five minutes spent doing that is the only way to know which of the twelve is going to eat the most time before you've already committed to one.

Your time budget and domain weights

☺ Like you're 10: The clock gets sliced up ahead of time in the same proportions the real test uses — nothing here is stacked to make one topic feel scarier than it actually is.

These minutes and points track the same five domains and the same 20/20/15/25/20 weights laid out on the CKAD blueprint and budgeted week-by-week on the study plan — unlike a paper deliberately skewed toward one domain, this one is a faithful proportional sample of the real thing.

Application Design and Build — B1 to B2 (20 points)

☺ Like you're 10: This block is about picking the right shape of container for the job, and correctly stacking more than one of them inside the same Pod when the job needs it.

Background: The Object Model, Kubernetes Architecture, and the multi-container patterns drilled in Capstone Part 2.

B1 · A Pod with an init container and a log-shipping sidecar (12 pts)

Your task: build a Pod named report-generator in namespace reports where an init container fetches a template file into a shared volume before the main container starts, and a second, permanently-running sidecar container tails the main container's log file from a second shared volume and streams it to its own stdout.

Done when: kubectl get pod report-generator -n reports shows 2/2 Ready containers, the init container shows Completed in kubectl describe, and kubectl logs report-generator -n reports -c log-shipper prints lines written by the main container.

apiVersion: v1
kind: Pod
metadata:
  name: report-generator
  namespace: reports
  labels: { app: report-generator }
spec:
  initContainers:
    - name: fetch-template
      image: busybox:1.36
      command: ["sh", "-c", "wget -qO /templates/report.tmpl http://config-svc.reports.svc/report.tmpl"]
      volumeMounts:
        - { name: templates, mountPath: /templates }
  containers:
    - name: generator
      image: registry.example.com/report-generator:1.4.0
      volumeMounts:
        - { name: templates, mountPath: /templates, readOnly: true }
        - { name: logs, mountPath: /var/log/app }
    - name: log-shipper
      image: busybox:1.36
      command: ["sh", "-c", "touch /var/log/app/report.log; tail -F /var/log/app/report.log"]
      volumeMounts:
        - { name: logs, mountPath: /var/log/app, readOnly: true }
  volumes:
    - { name: templates, emptyDir: {} }
    - { name: logs, emptyDir: {} }

B2 · Replace a sleep-loop anti-pattern with a real CronJob (8 pts)

An existing nightly-cleanup Pod in reports has restartPolicy: Always and a shell script that sleeps until 2am, runs a cleanup, then loops forever — it has been "Running" for months and nobody can tell you whether last night's cleanup actually succeeded.

Done when: the old Pod is deleted, kubectl get cronjob nightly-cleanup -n reports shows schedule 0 2 * * *, and kubectl create job --from=cronjob/nightly-cleanup test-run -n reports produces a Job that reaches Complete.

apiVersion: batch/v1
kind: CronJob
metadata: { name: nightly-cleanup, namespace: reports }
spec:
  schedule: "0 2 * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  jobTemplate:
    spec:
      activeDeadlineSeconds: 600
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: cleanup
              image: registry.example.com/report-cleanup:1.0
              command: ["/bin/sh", "-c", "/scripts/cleanup.sh"]

kubectl delete pod nightly-cleanup -n reports
kubectl apply -f cronjob.yaml
kubectl create job --from=cronjob/nightly-cleanup test-run -n reports
kubectl get job test-run -n reports -w

Application Deployment — D1 to D2 (20 points)

☺ Like you're 10: One task teaches you to swap in a new version of a running app without anyone noticing the switch; the other teaches you to keep one set of files and only ever change the small parts that differ per environment.

Background: Workloads & Scheduling for rollout mechanics, and the Helm and Kustomize tool guides.

D1 · Cut over a Service from blue to green without dropping traffic (10 pts)

Namespace catalog runs catalog-blue (Deployment, 3 replicas, label version: blue) behind Service catalog-svc, currently selecting version: blue. Ship catalog-green — same app, image tag 2.4.0, label version: green — verify it's healthy, then cut the Service over to it with zero dropped requests.

Done when: kubectl get endpoints catalog-svc -n catalog lists only green Pod IPs after the cutover, and at no point during the switch did the Service route to a Pod that hadn't yet passed its readiness probe.

apiVersion: apps/v1
kind: Deployment
metadata: { name: catalog-green, namespace: catalog }
spec:
  replicas: 3
  selector: { matchLabels: { app: catalog, version: green } }
  template:
    metadata: { labels: { app: catalog, version: green } }
    spec:
      containers:
        - name: api
          image: registry.example.com/catalog:2.4.0
          ports: [{ containerPort: 8080 }]
          readinessProbe: { httpGet: { path: /readyz, port: 8080 }, periodSeconds: 5 }

kubectl apply -f catalog-green.yaml
kubectl wait --for=condition=Ready pod -l app=catalog,version=green -n catalog --timeout=60s
kubectl patch svc catalog-svc -n catalog -p '{"spec":{"selector":{"app":"catalog","version":"green"}}}'
kubectl get endpoints catalog-svc -n catalog             # green IPs only, immediately
kubectl scale deploy/catalog-blue -n catalog --replicas=0 # once you're confident

D2 · A Kustomize overlay that never touches base (10 pts)

base/ holds a working Deployment named catalog, image registry.example.com/catalog:2.4.0, replicas: 1. Build overlays/staging/ that produces staging-catalog with 3 replicas and image tag 2.4.0-staging, without editing a single file under base/.

Done when: kubectl kustomize overlays/staging shows replicas: 3 and the staging image tag, kubectl apply -k overlays/staging/ creates staging-catalog, and base/deployment.yaml is byte-identical to before you started.

# overlays/staging/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
namePrefix: staging-
patches:
  - target: { kind: Deployment, name: catalog }
    patch: |-
      - op: replace
        path: /spec/replicas
        value: 3
images:
  - name: registry.example.com/catalog
    newTag: 2.4.0-staging

kubectl kustomize overlays/staging | grep -E "replicas|image:"
kubectl apply -k overlays/staging/
git status --short base/                    # empty output — confirms base/ was never touched

Application Observability and Maintenance — O1 to O2 (15 points)

☺ Like you're 10: This block is about noticing when something is actually broken — a manifest the cluster refuses to run at all, or a container that dies before it's finished waking up.

Background: Observability on Kubernetes and A Troubleshooting Methodology; drill the debugging loop itself in Drill — Debug a Stuck Pod.

O1 · A manifest the cluster won't even accept, then a crash that logs hide (8 pts)

Applying invoice-worker.yaml in namespace billing fails outright with no matches for kind "Deployment" in version "apps/v1beta1". Once it applies, the resulting Pods immediately go CrashLoopBackOff, and kubectl logs against the current container shows nothing useful.

Done when: kubectl apply -f invoice-worker.yaml succeeds with no API error, and the Pods reach Running with a stable restart count across two check intervals.

# before — two separate bugs stacked on top of each other
apiVersion: apps/v1beta1        # removed entirely in Kubernetes 1.16, not just deprecated
kind: Deployment
metadata: { name: invoice-worker, namespace: billing }
spec:
  replicas: 2
  template: { ... }             # v1beta1 defaulted the selector for you — v1 requires it explicit

# after
apiVersion: apps/v1
kind: Deployment
metadata: { name: invoice-worker, namespace: billing }
spec:
  replicas: 2
  selector: { matchLabels: { app: invoice-worker } }   # now mandatory, must match template labels
  template:
    metadata: { labels: { app: invoice-worker } }
    spec:
      containers:
        - name: worker
          image: registry.example.com/invoice-worker:3.1.0
          env:
            - { name: FEATURE_FLAG_KEY, value: "billing-v2" }   # the actual crash cause

kubectl logs -n billing <pod>                          # empty or unhelpful — this container just started
kubectl logs -n billing <pod> --previous                # panic: missing required env FEATURE_FLAG_KEY
kubectl apply -f invoice-worker.yaml
kubectl rollout status deploy/invoice-worker -n billing

O2 · A slow-starting app killed by its own liveness probe (7 pts)

model-loader in namespace inference takes roughly 50 seconds to load a model file before it can serve traffic. Its livenessProbe — periodSeconds: 10, failureThreshold: 3 — kills the container at around the 30-second mark, every time, before it ever finishes loading.

Done when: the Pod shows zero restarts a full two minutes after creation, and kubectl get endpoints model-loader -n inference gains the Pod's IP only once /readyz genuinely returns 200.

startupProbe:
  httpGet: { path: /healthz, port: 8080 }
  failureThreshold: 30
  periodSeconds: 2
livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 10
  failureThreshold: 3
readinessProbe:
  httpGet: { path: /readyz, port: 8080 }
  periodSeconds: 5

Application Environment, Configuration and Security — E1 to E3 (25 points)

☺ Like you're 10: This is the biggest block on the whole paper — it's about giving an app exactly the settings, secrets and permissions it needs, and not one thing more.

Background: Scheduling & Resource Management for requests, limits and quotas; RBAC & Admission Control and Security: Defense in Depth for the rest. For ConfigMaps and Secrets specifically, the sibling Platform Engineering course's Configuration & Packaging and Secrets & Workload Identity pages go further than this exam requires; DevSecOps's Kubernetes Security Deep Dive covers E3's territory from the attacker's side.

E1 · Roll out a config change to an immutable ConfigMap (8 pts)

The now-stable catalog Deployment (from D1) reads FEATURE_X from ConfigMap catalog-flags-v1, created with immutable: true — deliberate platform policy, not a bug. Turn FEATURE_X from off to on across every replica, with zero failed Pods and without removing immutability from anything.

Done when: kubectl exec into every catalog Pod shows FEATURE_X=on, and kubectl get cm -n catalog still shows catalog-flags-v1 present, untouched, alongside a new ConfigMap.

kubectl create configmap catalog-flags-v2 -n catalog --from-literal=FEATURE_X=on
kubectl patch deploy catalog -n catalog --type=json -p='[
  {"op":"replace","path":"/spec/template/spec/containers/0/envFrom/0/configMapRef/name","value":"catalog-flags-v2"}
]'
kubectl rollout status deploy/catalog -n catalog
kubectl exec -n catalog deploy/catalog -- env | grep FEATURE_X   # on, on every replica

E2 · A ResourceQuota silently starving a Deployment's rollout (9 pts)

Namespace batch has a ResourceQuota capping requests.cpu at 2 cores and a LimitRange that injects a default 500m CPU request onto any container that doesn't set its own. A batch-worker Deployment with 5 replicas and no resources block is stuck at 4 Pods forever — kubectl get pods alone looks unremarkable, just short a replica.

Done when: kubectl get pods -n batch -l app=batch-worker shows all 5 replicas Running, and kubectl describe resourcequota batch-quota -n batch shows requests.cpu used at or under the 2-core hard limit.

# kubectl get events -n batch --field-selector involvedObject.kind=ReplicaSet shows:
#   Error creating: pods "batch-worker-xxxxx" is forbidden: exceeded quota: batch-quota,
#   requested: requests.cpu=500m, used: requests.cpu=2, limited: requests.cpu=2
spec:
  template:
    spec:
      containers:
        - name: worker
          image: registry.example.com/batch-worker:1.2.0
          resources:
            requests: { cpu: 300m, memory: 200Mi }   # 5 × 300m = 1500m, fits under the 2-core cap
            limits:   { cpu: 600m, memory: 400Mi }

E3 · Harden the catalog Deployment's SecurityContext and ServiceAccount (8 pts)

The catalog Deployment (from D1/E1) still runs as root under the namespace's default ServiceAccount, which auto-mounts an API token the app never uses, with no capability restrictions at all. Lock it down.

Done when: kubectl exec into a catalog Pod shows a non-root UID, ls /var/run/secrets/kubernetes.io/serviceaccount from inside the container fails (no token mounted), and the container still starts successfully despite a read-only root filesystem.

apiVersion: v1
kind: ServiceAccount
metadata: { name: catalog-sa, namespace: catalog }
automountServiceAccountToken: false
---
spec:
  template:
    spec:
      serviceAccountName: catalog-sa
      securityContext: { runAsNonRoot: true, runAsUser: 10001, fsGroup: 2000 }
      containers:
        - name: api
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities: { drop: ["ALL"] }
          volumeMounts:
            - { name: scratch, mountPath: /tmp }   # rootfs is read-only — writable scratch space needed
      volumes:
        - { name: scratch, emptyDir: {} }

Services and Networking — N1 to N3 (20 points)

☺ Like you're 10: These three teach the cluster to actually deliver traffic where it belongs — to the right container, to the right host, and only to visitors who are allowed in.

Background: Networking & the CNI, ingress-nginx, and Cilium or Calico for policy enforcement; drilled hands-on in Drill — Diagnose a Networking Failure.

N1 · A Service left pointing at a port the app no longer listens on (6 pts)

In namespace shop, Service cart-svc has targetPort: 8080. A recent image rebuild moved the app to listen on 3000 instead, and nobody updated the Service. kubectl get endpoints cart-svc currently shows Pod IPs with no working port behind them.

Done when: a curl from another Pod in shop to http://cart-svc/health returns a real response, not a connection refused or timeout.

kubectl describe pod -n shop -l app=cart | grep -i port     # confirm: container actually listens on 3000
kubectl patch svc cart-svc -n shop -p '{"spec":{"ports":[{"port":80,"targetPort":3000}]}}'
kubectl run probe -n shop --image=busybox:1.36 --restart=Never --rm -it -- wget -qO- cart-svc/health

N2 · Host-based Ingress routing for two Services (7 pts)

Still in shop: web-svc and api-svc both listen on port 80 and both need to be reachable through one Ingress — shop.example.com to web-svc, api.shop.example.com to api-svc.

Done when: curl -H "Host: shop.example.com" http://<ingress-ip>/ reaches web-svc, and curl -H "Host: api.shop.example.com" http://<ingress-ip>/ reaches api-svc.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata: { name: shop, namespace: shop }
spec:
  ingressClassName: nginx
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend: { service: { name: web-svc, port: { number: 80 } } }
    - host: api.shop.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend: { service: { name: api-svc, port: { number: 80 } } }

N3 · Allow one cross-namespace caller through a default-deny NetworkPolicy (7 pts)

Namespace payments already enforces default-deny ingress. Monitoring Pods labeled role: monitoring, running in a separate namespace ops, need to scrape /metrics on tcp/9090 from every Pod in payments — and only those specific Pods, not the whole ops namespace.

Done when: a request from a role: monitoring Pod in ops to any payments Pod on 9090 succeeds, and the same request from any other Pod in ops — unlabeled — still times out.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: allow-monitoring-scrape, namespace: payments }
spec:
  podSelector: {}
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector: { matchLabels: { kubernetes.io/metadata.name: ops } }
          podSelector: { matchLabels: { role: monitoring } }
      ports: [{ protocol: TCP, port: 9090 }]

Score yourself

☺ Like you're 10: Add up the points, but pay closer attention to whether your misses cluster in one domain — that pattern is worth more than the total number.

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

CKAD's commonly published pass mark is 66% — this paper uses the same figure as a study reference. Below that here, don't just re-read the explanations above; that teaches these twelve exact answers, not the underlying skill. Go re-run the matching drill instead: B1/B2 point back to Capstone Part 2, D1/D2 to the Helm and Kustomize tool guides, O1/O2 to debug a stuck pod, E1/E3 to harden an RBAC configuration, E2 to Scheduling & Resource Management, and N1/N2/N3 to diagnose a networking failure.

That's Set 2. Whichever domain your misses clustered in, loop back to the matching week on 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 shorter, single-topic reps instead of a full timed paper, see CKAD Practice Tasks; for the full official domain breakdown this paper is weighted against, see the CKAD blueprint.