CKAD Practice Tasks

Fifteen performance-based practice tasks, one bank, all five official CKAD domains, sized to the same weights the real exam uses — four tasks in the biggest domain, two in the smallest, three each in the rest. Every task reads like an exam item: a short scenario, a numbered list of what to build, and a done when line naming the exact kubectl check that proves it — not "did you write correct-looking YAML," but "does the cluster actually do the thing." Work each one cold, on a real cluster, against a clock, before you look at the worked solution underneath. This bank complements the CKAD blueprint's domain-by-domain theory and the CKAD study plan's weekly schedule — read those first if a domain still feels shaky; come here once you're ready to prove it with your hands.

How to drill this bank

☺ Like you're 10: Try it yourself first, with a timer running — only lift the answer flap once you're stuck or done, or your brain learns "I can read solutions" instead of "I can do this."

CKAD has no question bank to cram, and neither does this page. Reading a worked solution feels like progress and mostly isn't — the exam never asks you to recognize correct YAML, it asks you to produce it, in a terminal, against a live cluster, before a two-hour clock runs out. Four habits make this bank behave like the real thing instead of a reading exercise.

One — start every task cold. Empty terminal, no leftover manifest from the last attempt, no tab open on the solution. That's how the exam starts you; starting warm just inflates the score you record for yourself.

Two — set an actual timer for five to seven minutes per task. That's roughly the real per-task budget on a two-hour paper. When it rings, stop — write one line about where you got stuck, and open the solution. Learning to abandon a task and move on is itself a scored skill on the day.

Three — run the context first, every time. The real exam prints a kubectl config use-context … line with every task, and solving a task perfectly against the wrong cluster or namespace scores zero — see Exam Day for the full habit. Get in the reflex here: kubectl config set-context --current --namespace=<ns> before you touch anything else.

Four — verify, don't trust. A fix you believe you made but never confirmed with kubectl get scores nothing, because grading only sees the cluster's end state, never your intent. Every task below names the exact command that proves it — run that command yourself, don't take the worked solution's word for it.

Weighted like the exam

☺ Like you're 10: The test doesn't grade every topic equally, so this bank doesn't either — the biggest domain gets four tasks, the smallest gets two.

The CKAD blueprint page covers the full official weights from CNCF curriculum v1.35; here's the same shape, translated into how many of the fifteen tasks below live in each domain.

🧩 20% — Application Design and Build

☺ Like you're 10: These three are about picking the right kind of container, the right kind of controller, and the right kind of storage for the job.

Three tasks: a multi-container Pod using the native sidecar pattern, choosing the right workload resource for something that runs on a schedule, and mixing persistent with ephemeral storage in one Pod.

B1 · Add a native sidecar to a worker Pod

The invoice-worker Pod in namespace orders writes its logs to a file inside the container instead of stdout, so nothing outside the Pod can currently read them. It also starts too fast relative to the queue it depends on and needs to wait.

Your task:

1. Create namespace orders if it doesn't exist.
2. Add a regular init container wait-for-queue that blocks until rabbitmq.orders.svc port 5672 is reachable.
3. Add a second init-container entry, log-shipper, with restartPolicy: Always so it runs as a native sidecar for the Pod's whole lifetime, tailing a shared log file.
4. Mount the same emptyDir volume into both log-shipper and the main worker container so they share the log file.

Done when: kubectl -n orders get pod invoice-worker shows READY 2/2 and STATUS Running, and kubectl -n orders logs invoice-worker -c log-shipper --tail=5 prints lines the worker container wrote.

apiVersion: v1
kind: Pod
metadata:
  name: invoice-worker
  namespace: orders
spec:
  initContainers:
    - name: wait-for-queue                # ordinary init container: runs once, then exits
      image: busybox:1.36
      command: ["sh", "-c", "until nc -z rabbitmq.orders.svc 5672; do sleep 2; done"]
    - name: log-shipper                   # native sidecar: restartPolicy makes it long-running
      image: busybox:1.36
      restartPolicy: Always
      command: ["sh", "-c", "touch /var/log/worker/invoice.log; tail -F /var/log/worker/invoice.log"]
      volumeMounts:
        - { name: worklogs, mountPath: /var/log/worker }
  containers:
    - name: worker
      image: registry.example.com/invoice-worker:1.4.0
      volumeMounts:
        - { name: worklogs, mountPath: /var/log/worker }
  volumes:
    - name: worklogs
      emptyDir: {}

kubectl create namespace orders --dry-run=client -o yaml | kubectl apply -f -
kubectl apply -f invoice-worker.yaml
kubectl -n orders get pod invoice-worker -w
kubectl -n orders logs invoice-worker -c log-shipper --tail=5

B2 · Convert a manual nightly job into a CronJob

Someone on the orders team currently SSHes into a box every night and runs a reconciliation script by hand. It must never overlap with itself if a run ever takes longer than expected, and you need a way to trigger a test run on demand without waiting for 3am.

Your task:

1. Create a CronJob nightly-reconcile in namespace orders, schedule 0 3 * * *.
2. Set concurrencyPolicy: Forbid so overlapping runs never happen, and keep only the last 3 successful and 1 failed Job.
3. Trigger one run right now, outside the schedule, to prove the template works.

Done when: kubectl -n orders get cronjob nightly-reconcile shows the correct schedule and policy, and a manually triggered Job from it reaches Complete.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-reconcile
  namespace: orders
spec:
  schedule: "0 3 * * *"
  concurrencyPolicy: Forbid       # never run two reconciles at once
  startingDeadlineSeconds: 120
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      backoffLimit: 2
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: reconcile
              image: registry.example.com/orders-reconcile:1.0.0
              command: ["./reconcile.sh"]

kubectl apply -f nightly-reconcile.yaml
kubectl -n orders get cronjob nightly-reconcile
kubectl -n orders create job --from=cronjob/nightly-reconcile manual-test-1
kubectl -n orders wait --for=condition=complete job/manual-test-1 --timeout=60s
kubectl -n orders get job manual-test-1

B3 · Combine persistent and ephemeral volumes in one Pod

A report-generation Pod in namespace orders needs its finished reports to survive a restart, but also needs scratch space for temporary files that should not survive one — mixing the two into the same volume today has already caused old scratch files to leak into delivered reports.

Your task:

1. Create a 1Gi ReadWriteOnce PVC named reports-data.
2. Create Pod report-generator mounting that PVC at /var/reports, and a separate 256Mi emptyDir at /tmp/scratch.
3. Write a file into each path, delete the Pod, then recreate it from the same manifest and confirm which file survived.

Done when: after recreation, kubectl -n orders exec report-generator -- cat /var/reports/report.txt still returns the original text, and /tmp/scratch is empty again.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: reports-data
  namespace: orders
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: standard        # kind's local-path-provisioner default SC
  resources:
    requests: { storage: 1Gi }
---
apiVersion: v1
kind: Pod
metadata:
  name: report-generator
  namespace: orders
spec:
  containers:
    - name: generator
      image: busybox:1.36
      command: ["sh", "-c", "sleep 3600"]
      volumeMounts:
        - { name: reports, mountPath: /var/reports }
        - { name: scratch, mountPath: /tmp/scratch }
  volumes:
    - name: reports
      persistentVolumeClaim: { claimName: reports-data }
    - name: scratch
      emptyDir: { sizeLimit: 256Mi }

kubectl apply -f reports-data-pvc.yaml -f report-generator.yaml
kubectl -n orders exec report-generator -- sh -c 'echo "Q3 totals" > /var/reports/report.txt; echo temp > /tmp/scratch/work.tmp'
kubectl -n orders delete pod report-generator
kubectl apply -f report-generator.yaml            # same claimName
kubectl -n orders exec report-generator -- cat /var/reports/report.txt   # "Q3 totals" survived
kubectl -n orders exec report-generator -- ls /tmp/scratch                # empty

🚢 20% — Application Deployment

☺ Like you're 10: These three are about the moment you ship a new version — swapping it in all at once, a little at a time, or letting a tool like Helm do the swapping for you.

Three tasks: a blue/green cutover built from primitives, a rolling update and rollback, and deploying with both of the CKAD-scoped packaging tools.

D1 · Cut traffic over with a blue/green Service flip

The storefront team is about to ship v2 of their web app and wants zero gradual mixing — either everyone hits v1 or everyone hits v2, with an instant, reversible switch and no rolling update in between.

Your task:

1. Create Deployments web-blue (labels app: web, version: blue, image tag 1.0.0) and web-green (app: web, version: green, tag 2.0.0), 3 replicas each, in namespace storefront.
2. Create Service web initially selecting {app: web, version: blue}.
3. Confirm web-green is healthy independently, then flip the Service's selector to version: green to cut all traffic over at once.

Done when: kubectl -n storefront get endpoints web -o jsonpath='{.subsets[0].addresses[*].targetRef.name}' lists only web-green-… Pod names.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-blue
  namespace: storefront
spec:
  replicas: 3
  selector: { matchLabels: { app: web, version: blue } }
  template:
    metadata: { labels: { app: web, version: blue } }
    spec:
      containers:
        - name: web
          image: registry.example.com/storefront-web:1.0.0
          ports: [{ containerPort: 8080 }]
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-green
  namespace: storefront
spec:
  replicas: 3
  selector: { matchLabels: { app: web, version: green } }
  template:
    metadata: { labels: { app: web, version: green } }
    spec:
      containers:
        - name: web
          image: registry.example.com/storefront-web:2.0.0
          ports: [{ containerPort: 8080 }]
---
apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: storefront
spec:
  selector: { app: web, version: blue }     # flip this line to cut over
  ports:
    - { port: 80, targetPort: 8080 }

kubectl apply -f web-blue.yaml -f web-green.yaml -f web-svc.yaml
kubectl -n storefront get pods -l version=green

# prove green is healthy on its own before it takes real traffic
kubectl -n storefront port-forward deploy/web-green 8080:8080 &
curl -s localhost:8080/healthz; kill %1

# the actual cutover
kubectl -n storefront patch service web -p '{"spec":{"selector":{"app":"web","version":"green"}}}'
kubectl -n storefront get endpoints web -o jsonpath='{.subsets[0].addresses[*].targetRef.name}'

D2 · Roll out safely, then roll back a broken image

The billing-api Deployment in namespace billing must never drop below its current replica count during an update — even briefly — and the team needs to see what a bad rollout looks like and recover from it without redeploying by hand.

Your task:

1. Set billing-api (4 replicas) to a rolling update strategy that never has fewer than 4 healthy Pods and surges by at most 1 extra Pod.
2. Ship a broken image tag and observe the rollout stall.
3. Roll back to the last working revision using the rollout history, not by re-applying an old file.

Done when: kubectl -n billing rollout status deploy/billing-api reports success after the rollback, and kubectl -n billing rollout history deploy/billing-api shows the failed attempt as its own revision.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: billing-api
  namespace: billing
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }   # never below 4 healthy Pods
  selector: { matchLabels: { app: billing-api } }
  template:
    metadata: { labels: { app: billing-api } }
    spec:
      containers:
        - name: api
          image: registry.example.com/billing-api:3.1.0
          readinessProbe:
            httpGet: { path: /readyz, port: 8080 }
            periodSeconds: 5

kubectl apply -f billing-api.yaml
kubectl -n billing rollout status deploy/billing-api

kubectl -n billing set image deploy/billing-api api=registry.example.com/billing-api:3.2.0-broken
kubectl -n billing rollout status deploy/billing-api --timeout=30s || true   # times out, never finishes

kubectl -n billing rollout undo deploy/billing-api
kubectl -n billing rollout status deploy/billing-api
kubectl -n billing rollout history deploy/billing-api

D3 · Deploy the same shape with Helm, then with Kustomize

Two unrelated requests land on the same day: the platform team wants a standalone Redis cache deployed from an existing chart with persistence turned off for a dev environment, and the session-store app — currently one flat manifest — needs a dev overlay that trims it to a single replica and pins a dev image tag, without touching the base file.

Your task — part A (Helm):

1. Add the bitnami chart repo and install bitnami/redis as release cache into namespace caching.
2. Override values so it runs standalone, with auth and persistence both disabled.

Your task — part B (Kustomize):

1. Create a base/ with the plain session-store Deployment and a kustomization.yaml.
2. Create overlays/dev/ that sets namespace caching-dev, replicas to 1, and the image tag to dev — using Kustomize transformers, not an edited copy of the Deployment.

Done when: helm status cache -n caching reports STATUS: deployed, and kubectl -n caching-dev get deploy session-store -o jsonpath='{.spec.replicas}{" "}{.spec.template.spec.containers[0].image}' prints 1 registry.example.com/session-store:dev.

# part A — Helm
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install cache bitnami/redis -n caching --create-namespace \
  --set architecture=standalone \
  --set auth.enabled=false \
  --set master.persistence.enabled=false
helm status cache -n caching
kubectl -n caching get pods

# base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
---
# overlays/dev/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: caching-dev
resources:
  - ../../base
replicas:
  - name: session-store
    count: 1
images:
  - name: registry.example.com/session-store
    newTag: dev

# part B — Kustomize
kubectl kustomize overlays/dev              # render only — always check before applying
kubectl apply -k overlays/dev
kubectl -n caching-dev get deploy session-store \
  -o jsonpath='{.spec.replicas}{" "}{.spec.template.spec.containers[0].image}'

🔭 15% — Application Observability and Maintenance

☺ Like you're 10: Two tasks — teach the cluster to know when your app is actually ready, and learn to read the clues it leaves behind when something's broken.

The smallest domain by weight but the one that shows up inside almost every other domain's tasks too, since a broken probe or a misread error message can sink a task that has nothing else wrong with it.

O1 · Fix a slow-starting app stuck in a crash loop

The report-api Deployment in namespace reporting takes about 40 seconds to finish warming up on a cold start, but its livenessProbe was configured for a fast app and starts checking after only 5 seconds — kubelet keeps killing it mid-boot before it ever becomes ready, and it's stuck restarting forever.

Your task:

1. Add a startupProbe that gives the container up to roughly 60 seconds to finish booting before liveness checks begin at all.
2. Correct the readinessProbe, which is pointed at a path the app doesn't serve.
3. Restart the rollout and confirm both Pods come up clean.

Done when: kubectl -n reporting get pods -l app=report-api shows RESTARTS 0 and READY 1/1 for both Pods within about a minute of the restart.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: report-api
  namespace: reporting
spec:
  replicas: 2
  selector: { matchLabels: { app: report-api } }
  template:
    metadata: { labels: { app: report-api } }
    spec:
      containers:
        - name: api
          image: registry.example.com/report-api:2.0.0
          ports: [{ containerPort: 8080 }]
          startupProbe:
            httpGet: { path: /healthz, port: 8080 }
            failureThreshold: 30
            periodSeconds: 2          # up to ~60s to finish starting
          livenessProbe:
            httpGet: { path: /healthz, port: 8080 }
            periodSeconds: 10
            failureThreshold: 3
          readinessProbe:
            httpGet: { path: /readyz, port: 8080 }   # was pointed at a nonexistent /health
            periodSeconds: 5

kubectl apply -f report-api.yaml
kubectl -n reporting rollout restart deploy/report-api
kubectl -n reporting get pods -l app=report-api -w

O2 · Chase down a deprecated API and a silent config failure

Two unrelated problems land in namespace platform the same morning. First, a PodDisruptionBudget manifest that used to apply cleanly now fails outright. Second, the checkout Deployment's Pods are stuck and producing no logs at all.

Your task:

1. Diagnose why report-api-pdb.yaml (below) fails to apply, then create a correctly-versioned PodDisruptionBudget checkout-pdb with minAvailable: 2 selecting app: checkout.
2. Find out why the checkout Pods never start — kubectl logs shows nothing — using describe and cluster events, then fix the root cause.

# report-api-pdb.yaml — apply this first and read the error
apiVersion: policy/v1beta1     # removed from the Kubernetes API in v1.25
kind: PodDisruptionBudget
metadata:
  name: report-api-pdb
  namespace: platform
spec:
  minAvailable: 1
  selector: { matchLabels: { app: report-api } }

Done when: kubectl -n platform get pdb checkout-pdb shows a populated ALLOWED DISRUPTIONS column, and kubectl -n platform get pods -l app=checkout shows every Pod Running with no recent restarts.

kubectl apply -f report-api-pdb.yaml
# Error from server (NotFound): error when creating "report-api-pdb.yaml":
# no matches for kind "PodDisruptionBudget" in version "policy/v1beta1"
kubectl api-resources | grep -i poddisruptionbudget    # confirms the current group/version

apiVersion: policy/v1              # policy/v1beta1 was removed outright in Kubernetes 1.25
kind: PodDisruptionBudget
metadata:
  name: checkout-pdb
  namespace: platform
spec:
  minAvailable: 2
  selector: { matchLabels: { app: checkout } }

kubectl apply -f checkout-pdb.yaml
kubectl -n platform get pdb checkout-pdb

kubectl -n platform get pods -l app=checkout
kubectl -n platform describe pod <checkout-pod> | tail -15
# State: Waiting, Reason: CreateContainerConfigError
# Events: ...key "API_KEY" not found in Secret "checkout-secrets"
kubectl -n platform get events --sort-by=.lastTimestamp | tail -10

kubectl -n platform get secret checkout-secrets -o jsonpath='{.data}'
kubectl -n platform patch secret checkout-secrets --type=merge -p '{"stringData":{"API_KEY":"replace-me"}}'
kubectl -n platform get pods -l app=checkout -w

🔑 25% — Application Environment, Configuration and Security

☺ Like you're 10: The biggest pile of tickets — feeding config and secrets into an app, keeping it inside its resource budget, and locking down what it's allowed to do.

Four tasks for the largest, broadest domain: ConfigMaps and Secrets consumed two different ways, requests/limits under a namespace quota, least-privilege RBAC for a ServiceAccount, and SecurityContext/Capabilities hardening.

C1 · Feed a Deployment from a ConfigMap, a Secret, and a mounted TLS pair

The notifier app in namespace notifications needs its non-sensitive SMTP settings as environment variables, one sensitive credential also as an environment variable but not lumped in with everything else, and a TLS keypair that its library insists on reading as files on disk, not as env vars.

Your task:

1. Create ConfigMap notify-config with SMTP_HOST=smtp.internal and SMTP_PORT=587.
2. Create Secret notify-creds with SMTP_USER and SMTP_PASS.
3. Create a kubernetes.io/tls Secret notify-tls from a cert/key pair.
4. In Deployment notifier: pull the whole ConfigMap in with envFrom, pull only SMTP_PASS in individually via secretKeyRef, and mount notify-tls as a read-only volume at /etc/tls.

Done when: kubectl -n notifications exec deploy/notifier -- env includes correct values for SMTP_HOST, SMTP_PORT and SMTP_PASS, and kubectl -n notifications exec deploy/notifier -- ls /etc/tls lists tls.crt and tls.key.

kubectl create namespace notifications --dry-run=client -o yaml | kubectl apply -f -
kubectl create configmap notify-config -n notifications \
  --from-literal=SMTP_HOST=smtp.internal --from-literal=SMTP_PORT=587
kubectl create secret generic notify-creds -n notifications \
  --from-literal=SMTP_USER=notifier-bot --from-literal=SMTP_PASS='r3placeMe!'
kubectl create secret tls notify-tls -n notifications --cert=tls.crt --key=tls.key

apiVersion: apps/v1
kind: Deployment
metadata:
  name: notifier
  namespace: notifications
spec:
  replicas: 1
  selector: { matchLabels: { app: notifier } }
  template:
    metadata: { labels: { app: notifier } }
    spec:
      containers:
        - name: notifier
          image: registry.example.com/notifier:1.0.0
          envFrom:
            - configMapRef: { name: notify-config }         # SMTP_HOST, SMTP_PORT
          env:
            - name: SMTP_PASS
              valueFrom: { secretKeyRef: { name: notify-creds, key: SMTP_PASS } }
          volumeMounts:
            - { name: tls, mountPath: /etc/tls, readOnly: true }
      volumes:
        - name: tls
          secret: { secretName: notify-tls }

kubectl apply -f notifier-deploy.yaml
kubectl -n notifications exec deploy/notifier -- env | grep -E 'SMTP_(HOST|PORT|PASS)'
kubectl -n notifications exec deploy/notifier -- ls /etc/tls

C2 · Cap a namespace with requests, limits, and a quota

The batch-jobs namespace currently lets anyone create Pods with no resource fields at all, and one team's runaway job already starved a neighbor's — before it happens again, every container needs a sane default and the namespace needs a hard ceiling.

Your task:

1. Create a LimitRange that defaults every container to 500m/256Mi limits and 100m/128Mi requests when a Pod spec doesn't set its own.
2. Create a ResourceQuota capping the namespace at requests.cpu: 2, requests.memory: 4Gi, limits.cpu: 4, limits.memory: 8Gi, and 10 Pods total.
3. Prove both work: a Pod with no resources field picks up the LimitRange defaults, and a Pod requesting more cpu than the remaining quota allows is rejected outright.

Done when: kubectl -n batch-jobs get pod plain-job -o jsonpath='{.spec.containers[0].resources}' shows the LimitRange's injected defaults, and applying an over-quota Pod returns a Forbidden error naming compute-quota.

apiVersion: v1
kind: ResourceQuota
metadata: { name: compute-quota, namespace: batch-jobs }
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi
    limits.cpu: "4"
    limits.memory: 8Gi
    pods: "10"
---
apiVersion: v1
kind: LimitRange
metadata: { name: default-limits, namespace: batch-jobs }
spec:
  limits:
    - type: Container
      default: { cpu: 500m, memory: 256Mi }
      defaultRequest: { cpu: 100m, memory: 128Mi }

kubectl apply -f compute-quota.yaml -f default-limits.yaml

kubectl -n batch-jobs run plain-job --image=busybox --restart=Never -- sleep 3600
kubectl -n batch-jobs get pod plain-job -o jsonpath='{.spec.containers[0].resources}{"\n"}'

kubectl -n batch-jobs apply -f oversized-pod.yaml   # requests.cpu: 3, exceeds the quota's headroom
# Error from server (Forbidden): exceeded quota: compute-quota, requested: requests.cpu=3, ...
kubectl -n batch-jobs describe resourcequota compute-quota

C3 · Grant a ServiceAccount least-privilege RBAC

A diagnostics Pod in namespace ops-tools needs to list Pods and read their logs — nothing more, and certainly not delete anything. Meanwhile every other Pod in that namespace is currently carrying the default ServiceAccount's token even though nothing else needs one at all.

Your task:

1. Create ServiceAccount log-reader.
2. Create Role pod-log-reader allowing get/list on pods and get on pods/log — nothing else.
3. Bind the Role to the ServiceAccount with a RoleBinding, and run Pod diagnostics using that ServiceAccount.
4. Disable automatic token mounting on the namespace's default ServiceAccount, since nothing else should be carrying a credential it never asked for.

Done when: kubectl -n ops-tools auth can-i list pods --as=system:serviceaccount:ops-tools:log-reader returns yes, and the same check with delete instead of list returns no.

apiVersion: v1
kind: ServiceAccount
metadata: { name: log-reader, namespace: ops-tools }
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: pod-log-reader, namespace: ops-tools }
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata: { name: log-reader-binding, namespace: ops-tools }
subjects:
  - kind: ServiceAccount
    name: log-reader
    namespace: ops-tools
roleRef: { kind: Role, name: pod-log-reader, apiGroup: rbac.authorization.k8s.io }
---
apiVersion: v1
kind: Pod
metadata: { name: diagnostics, namespace: ops-tools }
spec:
  serviceAccountName: log-reader
  containers:
    - name: kubectl
      image: bitnami/kubectl:1.30
      command: ["sleep", "3600"]

kubectl apply -f log-reader-sa.yaml -f pod-log-reader-role.yaml -f log-reader-binding.yaml -f diagnostics-pod.yaml
kubectl -n ops-tools auth can-i list pods --as=system:serviceaccount:ops-tools:log-reader
kubectl -n ops-tools auth can-i delete pods --as=system:serviceaccount:ops-tools:log-reader
kubectl -n ops-tools patch serviceaccount default -p '{"automountServiceAccountToken": false}'

C4 · Harden a proxy's SecurityContext and Capabilities

The edge-proxy Deployment in namespace edge currently runs as root because it binds to port 80, which is below 1024 — security review wants it non-root, with every Linux capability dropped except the one it actually needs, and a read-only root filesystem.

Your task:

1. Set runAsNonRoot: true and a fixed non-root runAsUser, with allowPrivilegeEscalation: false.
2. Drop ALL capabilities, then add back only NET_BIND_SERVICE so it can still bind port 80.
3. Set readOnlyRootFilesystem: true, and mount a writable emptyDir over the one path the image needs to write to.

Done when: kubectl -n edge get pods -l app=edge-proxy shows every Pod Running with 0 restarts, kubectl -n edge exec deploy/edge-proxy -- id shows a non-root uid, and the proxy still answers on port 80.

apiVersion: apps/v1
kind: Deployment
metadata: { name: edge-proxy, namespace: edge }
spec:
  replicas: 2
  selector: { matchLabels: { app: edge-proxy } }
  template:
    metadata: { labels: { app: edge-proxy } }
    spec:
      containers:
        - name: proxy
          image: registry.example.com/edge-proxy:1.1.0
          ports: [{ containerPort: 80 }]
          securityContext:
            runAsNonRoot: true
            runAsUser: 10001
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
              add: ["NET_BIND_SERVICE"]
          volumeMounts:
            - { name: tmp, mountPath: /tmp }
      volumes:
        - name: tmp
          emptyDir: {}

kubectl apply -f edge-proxy.yaml
kubectl -n edge get pods -l app=edge-proxy
kubectl -n edge exec deploy/edge-proxy -- id
kubectl -n edge get pod -l app=edge-proxy -o jsonpath='{.items[0].spec.containers[0].securityContext}'

🐦 20% — Services and Networking

☺ Like you're 10: Three tasks about the plumbing — making sure requests actually reach a Pod, routing different paths to different apps, and locking down who's allowed to talk to whom.

Three tasks: the classic "nothing can reach this app" repair, path-based Ingress routing, and a NetworkPolicy default-deny with one allow rule punched through it.

N1 · Fix a Service nothing can reach

Namespace search has a running search-api Deployment and a Service in front of it, but every request to the Service times out. The Deployment and Service were written by different people on the same day.

Your task:

1. Check the Service's endpoints first — an empty list means the selector itself is wrong.
2. Fix the Service's selector so it matches the Pod template's labels.
3. Fix the Service's targetPort so it matches the port the container actually listens on.

Done when: kubectl -n search get endpoints search-api lists both Pod IPs on the correct port, and a request from inside the cluster to search-api returns a response.

# the broken Service as found — container listens on 8000, Pod labeled app: search-api
apiVersion: v1
kind: Service
metadata: { name: search-api, namespace: search }
spec:
  selector: { app: search }           # BROKEN — doesn't match the Pod's app: search-api label
  ports:
    - { port: 80, targetPort: 8080 }  # BROKEN — container listens on 8000, not 8080

kubectl -n search get endpoints search-api            # empty ADDRESSES before the fix

kubectl -n search patch svc search-api --type=merge -p \
  '{"spec":{"selector":{"app":"search-api"},"ports":[{"port":80,"targetPort":8000}]}}'

kubectl -n search get endpoints search-api            # now lists both Pod IPs:8000
kubectl -n search run smoke --rm -it --restart=Never --image=busybox -- wget -qO- http://search-api

N2 · Route two paths to two Services with one Ingress

The portal namespace runs a web UI and a separate API gateway as two Services, and they need to sit behind one hostname: portal.example.com/api/… should reach the gateway, everything else should reach the UI.

Your task:

1. Create Services web-ui (port 80 → container 3000) and api-gateway (port 80 → container 8080).
2. Create Ingress portal using ingressClassName: nginx, host portal.example.com, with a /api path routed to api-gateway and / routed to web-ui.

Done when: kubectl -n portal get ingress portal lists both rules with the correct backends, and a request for /api/health with the right Host header reaches api-gateway while /dashboard reaches web-ui.

apiVersion: v1
kind: Service
metadata: { name: web-ui, namespace: portal }
spec:
  selector: { app: web-ui }
  ports: [{ port: 80, targetPort: 3000 }]
---
apiVersion: v1
kind: Service
metadata: { name: api-gateway, namespace: portal }
spec:
  selector: { app: api-gateway }
  ports: [{ port: 80, targetPort: 8080 }]
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: portal
  namespace: portal
spec:
  ingressClassName: nginx
  rules:
    - host: portal.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service: { name: api-gateway, port: { number: 80 } }
          - path: /
            pathType: Prefix
            backend:
              service: { name: web-ui, port: { number: 80 } }

kubectl apply -f portal-services.yaml -f portal-ingress.yaml
kubectl -n portal get ingress portal

kubectl -n ingress-nginx port-forward svc/ingress-nginx-controller 8080:80 &
curl -s -H "Host: portal.example.com" http://localhost:8080/api/health
curl -s -H "Host: portal.example.com" http://localhost:8080/dashboard

N3 · Default-deny a namespace, then open exactly one path

The ledger Deployment in namespace payments currently accepts traffic from anything in the cluster. Security wants nothing able to reach it except Pods labeled app: frontend, on the exact port it serves.

Your task:

1. Create a default-deny-ingress NetworkPolicy selecting every Pod in payments.
2. Create a second NetworkPolicy that allows ingress to app: ledger Pods, only from Pods labeled app: frontend, only on port 8080.
3. Prove it from both sides: a request from a frontend-labeled Pod succeeds, a request from an unlabeled Pod does not.

Done when: a Pod labeled app: frontend can reach ledger:8080, and a Pod without that label times out reaching the same address.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: payments
spec:
  podSelector: {}          # every Pod in the namespace
  policyTypes: [Ingress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-frontend
  namespace: payments
spec:
  podSelector: { matchLabels: { app: ledger } }
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector: { matchLabels: { app: frontend } }
      ports:
        - { protocol: TCP, port: 8080 }

kubectl apply -f ledger.yaml -f default-deny-ingress.yaml -f allow-from-frontend.yaml

kubectl -n payments run allowed --labels=app=frontend --rm -it --restart=Never \
  --image=busybox -- wget -qT 3 -O- http://ledger:8080
kubectl -n payments run blocked --rm -it --restart=Never \
  --image=busybox -- wget -qT 3 -O- http://ledger:8080     # times out

Score yourself, then move to a mock exam

☺ Like you're 10: Once you've done every ticket cold, redo only the ones you got wrong tomorrow — then try a full timed paper.

Read the pattern across all fifteen, not any single result. A whole domain dragging is a knowledge gap — reread that domain's section on the CKAD blueprint before you retry it. Consistently finishing correct but over the five-to-seven-minute box is a speed problem, fixed by drilling the imperative shortcuts in the kubectl fluency baseline rather than by re-reading YAML. A task you got wrong once is worth doing again tomorrow, cold, more than doing three you already know well a second time — keep a running list in Field Notes and strike items off only once they run clean without help.

Once the whole bank runs clean, move on to CKAD Mock Exam · Set 1 and Set 2 for full two-hour timed sittings that interleave all five domains the way the real paper does, and revisit the CKAD study plan if a whole week's worth of material needs a second pass rather than one task. For a different explanation of any domain that still isn't clicking, the sibling Platform Engineering course's CKAD page covers the same exam from a platform-team angle, and if CKAD is one stop on your way to the full ladder, the Golden Astronaut course covers the other Kubestronaut and Golden Kubestronaut certifications.