CKAD — the exam

The CKAD — Certified Kubernetes Application Developer — is a two-hour, performance-based exam about one thing: can you make an application run correctly inside a namespace somebody else administers? No multiple choice, no essay questions about theory. You are dropped into a browser terminal in front of several live, disposable clusters with a list of tasks — build this, deploy that, expose the other, fix why it's broken — and graded purely on the cluster state you leave behind. This page is the CKAD hub for this course: what the exam tests and deliberately doesn't, an honest read on when to sit it before or after the CKA, the full official domain breakdown from CNCF curriculum v1.35 — five domains, 24 competencies, summing to exactly 100% — and a single worked manifest that touches four of those five domains at once.

What the CKAD actually tests

☺ Like you're 10: It's a two-hour test on a real computer where you make actual apps run — nobody asks you to describe how you'd do it, they just watch you do it.

CKAD is one of the CNCF's three performance-based Kubernetes exams, alongside CKA and CKS. There is no question bank to memorize — you're given real tasks against real clusters, and the grading script inspects the resulting objects after time runs out. An elegant approach earns nothing extra; a working Deployment with the right probe on it earns full marks whether you got there by hand-writing YAML or by editing a generated skeleton.

Its scope sits entirely inside a namespace. Where the CKA is about operating the cluster itself — bootstrapping nodes, backing up etcd, running RBAC across the whole thing — CKAD assumes a cluster already exists and someone else keeps it alive. Your job is everything a workload author touches: Pods and their controllers, config and secrets, volumes, probes, Services, Ingress, and the debugging loop when any of it misbehaves.

Who should sit it

• Application developers shipping onto Kubernetes — the exam's primary, intended audience.
• Anyone newer to Kubernetes who wants a forcing function that's narrower and gentler than the CKA, without being multiple choice.
• Ops and SRE folk who inherited a cluster and want a structured, hands-on sweep through the workload half of the object model — see The Object Model if reconciliation itself is still fuzzy.
• Anyone collecting the full ladder — CKAD is one of the five certifications required for Kubestronaut, alongside KCNA, KCSA, CKA and CKS.

What it deliberately does not test

Not cluster installation, kubeadm, etcd backup and restore, node lifecycle, or control-plane troubleshooting — that's the CKA's territory, covered in this course's five-part Exam Blueprint. Not threat modeling, runtime detection, or supply-chain signing — that's CKS, which additionally requires an active, non-expired CKA before you're even allowed to register. CKAD asks a narrower question: can you make an application run correctly, safely and observably in a namespace you were handed, not one you built.

CKAD versus CKA — which to sit, and when

☺ Like you're 10: One badge is for the person who cooks in the kitchen, the other is for the person who keeps the kitchen itself running. Pick the one closest to what you actually do all day.

Neither exam has a formal prerequisite of its own, so nothing stops you from sitting either first — but "can" and "should" aren't the same question. The two exams share an exam environment and a similar clock, but almost no curriculum overlap:

If you already write and debug workload manifests daily and have done so for a year, CKAD will mostly confirm what you know — your study time is probably better spent on the CKA, the half of Kubernetes an application developer genuinely hasn't touched. If you're new to Kubernetes entirely, or you ship applications and want the exam that maps most directly onto your day job, CKAD is the gentler on-ramp and a fine place to start; this course's Certifications hub lays out three full starting paths depending on where you're coming from. Either order gets you toward the same place: hold all five core-Kubernetes certifications at once and you qualify for Kubestronaut.

The official domains and weights — CNCF curriculum v1.35

☺ Like you're 10: The test is split into five topics, and one of them — config and security — is worth a whole quarter of your score by itself.

Transcribed from the CNCF's published CKAD Exam Curriculum, version 1.35: five domains and 24 competencies. The weights are 20 + 20 + 15 + 25 + 20 = 100% — if a study guide you're reading doesn't add up to exactly 100, it's out of date or misquoting. Bars below are sorted by weight so you can see where the marks actually live; the domain sections that follow keep the curriculum's own order and wording.

🧩 20% — Application Design and Build

• Define, build and modify container images
• Choose and use the right workload resource (Deployment, DaemonSet, CronJob, etc.)
• Understand multi-container Pod design patterns (e.g. sidecar, init and others)
• Utilize persistent and ephemeral volumes

The workload-resource question shows up constantly: know on sight when a bare Pod, a Deployment, a DaemonSet, a Job, or a CronJob is the right primitive — this course's Kubernetes Architecture and Scheduling & Resource Management pages cover the full set. The init and sidecar patterns are drilled hands-on in Capstone Part 2.

🚢 20% — Application Deployment

• Use Kubernetes primitives to implement common deployment strategies (e.g. blue/green or canary)
• Understand Deployments and how to perform rolling updates
• Use the Helm package manager to deploy existing packages
• Kustomize

"Blue/green or canary" here means labels, selectors and two Deployments handled by hand — no rollout controller does it for you on this exam. Helm and Kustomize are covered at exam depth and beyond in the Helm and Kustomize tool guides; rolling updates and rollbacks live in Workloads & Scheduling, the same CKA blueprint domain covering the controller mechanics underneath.

🔭 15% — Application Observability and Maintenance

• Understand API deprecations
• Implement probes and health checks
• Use built-in CLI tools to monitor Kubernetes applications
• Utilize container logs
• Debugging in Kubernetes

The smallest domain by weight but not by usefulness — probes in particular reappear inside nearly every other domain's tasks. Go deeper in Observability on Kubernetes and A Troubleshooting Methodology, and drill the debugging loop itself in Drill — Debug a Stuck Pod.

🔑 25% — Application Environment, Configuration and Security

• Discover and use resources that extend Kubernetes (CRD, Operators)
• Understand authentication, authorization and admission control
• Understand requests, limits, quotas
• Define resource requirements
• Understand ConfigMaps
• Create & consume Secrets
• Understand ServiceAccounts
• Understand Application Security (SecurityContexts, Capabilities, etc.)

The largest domain, and with eight competencies also the broadest — it's really three sub-topics wearing one name. Extension resources are the shallow end of Operators & Custom Resource Definitions; authn/authz/admission is the workload-facing slice of RBAC & Admission Control, hardened hands-on in Drill — Harden an RBAC Configuration; requests, limits and quotas are covered in Scheduling & Resource Management. For ConfigMaps and Secrets specifically, the sibling Platform Engineering course's Configuration & Packaging and Secrets & Workload Identity pages go further than this exam requires. SecurityContexts and Capabilities are this course's Security: Defense in Depth, and get a full deep-dive treatment from DevSecOps's Kubernetes Security Deep Dive if you want the attacker's-eye version.

🐦 20% — Services and Networking

• Demonstrate basic understanding of NetworkPolicies
• Provide and troubleshoot access to applications via services
• Use Ingress rules to expose applications

Only three competencies for a fifth of the marks, which makes this the domain most people under-study relative to its weight. Full coverage lives in Networking & the CNI and Services & Networking (the same domain name on the CKA side of the ladder, viewed from the cluster-operator angle instead); Ingress specifics are in ingress-nginx, and policy enforcement in Cilium or Calico.

One manifest, four domains

☺ Like you're 10: Almost everything on this test lives in one kind of file — the Pod template. Get really good at that one file and most of the exam is already done.

Strip the domain names away and CKAD is one skill, repeated: fluency in the Pod template. Controllers wrap it, volumes plug into it, ConfigMaps and Secrets feed it, probes and resources are fields on it, Services select the Pods it produces. Here's a single Deployment that touches Design & Build, Deployment, Observability, and Environment/Configuration/Security all at once — read it as a checklist of fields you should be able to write without looking anything up:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: catalog-api
  namespace: catalog
spec:
  replicas: 2
  selector:
    matchLabels: { app: catalog-api }
  template:
    metadata:
      labels: { app: catalog-api }
    spec:
      serviceAccountName: catalog-api           # ServiceAccounts
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        fsGroup: 2000
      initContainers:                            # multi-container pattern: init
        - name: wait-for-migrations
          image: busybox:1.36
          command: ["sh", "-c", "until nc -z db 5432; do sleep 2; done"]
      containers:
        - name: api
          image: registry.example.com/catalog-api:2.3.1
          ports: [{ containerPort: 8080 }]
          envFrom:
            - configMapRef: { name: catalog-api-config }   # ConfigMaps
          env:
            - name: DB_PASSWORD                            # Secrets
              valueFrom:
                secretKeyRef: { name: catalog-api-db, key: password }
          resources:                                       # requests, limits
            requests: { cpu: 100m, memory: 128Mi }
            limits:   { cpu: 500m, memory: 256Mi }
          securityContext:                                  # Application Security
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities: { drop: ["ALL"] }
          readinessProbe:                                   # probes and health checks
            httpGet: { path: /readyz, port: 8080 }
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet: { path: /healthz, port: 8080 }
            failureThreshold: 3
          volumeMounts:
            - { name: cache, mountPath: /tmp }             # ephemeral volume
      volumes:
        - name: cache
          emptyDir: {}

The fifth domain, Services and Networking, sits right next to it — the Deployment above is worthless until something routes traffic to it, and the classic exam task is "nothing can reach this app, fix it":

apiVersion: v1
kind: Service
metadata:
  name: catalog-api
  namespace: catalog
spec:
  selector: { app: catalog-api }        # must match the Pod's labels exactly
  ports:
    - { port: 80, targetPort: 8080 }    # port vs targetPort is the #1 self-inflicted bug
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: catalog-api
  namespace: catalog
spec:
  ingressClassName: nginx
  rules:
    - host: catalog.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service: { name: catalog-api, port: { number: 80 } }

When a task like that fails, it's almost always one of three things: a label typo between the Service selector and the Pod template, a targetPort that doesn't match the container's real listening port, or a NetworkPolicy with no rule that matches. The failure modes and the fix for each are catalogued in Troubleshooting and drilled in Drill — Diagnose a Networking Failure.

Speed is examinable too

Two hours is not long enough to hand-type every manifest from a blank file. Nobody who passes does that — they generate a skeleton and edit the two or three lines that need it. This muscle memory, more than raw knowledge, separates a comfortable pass from a near-miss:

# pin context and namespace first — every task names one
kubectl config set-context --current --namespace=catalog

# generators: the fastest path to a valid skeleton
kubectl run tmp --image=nginx --restart=Never --dry-run=client -o yaml > pod.yaml
kubectl create deployment catalog-api --image=nginx --replicas=2 --dry-run=client -o yaml > d.yaml
kubectl create cronjob nightly --image=busybox --schedule="0 2 * * *" -- /bin/sh -c date

# config & secrets without opening an editor
kubectl create configmap catalog-api-config --from-literal=TIER=gold
kubectl create secret generic catalog-api-db --from-literal=password='s3cr3t'

# expose, roll, inspect, undo
kubectl expose deployment catalog-api --port=80 --target-port=8080
kubectl set image deploy/catalog-api api=registry.example.com/catalog-api:2.3.2
kubectl rollout status deploy/catalog-api && kubectl rollout undo deploy/catalog-api

# the debugging loop that answers most "why is it broken" tasks
kubectl describe pod catalog-api-xxxx | tail -30
kubectl logs catalog-api-xxxx -c api --previous
kubectl get events --sort-by=.lastTimestamp | tail -20

This exact command set, and the reasoning behind each one, is covered end to end in The kubectl Fluency Baseline — it's worth being fast at every one of these before you book, not during the exam itself.

Format and logistics — confirm every number before you book

☺ Like you're 10: Here's roughly how test day works — but the exact rules and prices change, so check the official page before you pay for anything.

What follows reflects the exam as commonly documented and reported at the time of writing. It is orientation, not a contract. Nothing in this table is a term of your purchase, and where it disagrees with the official page, the official page is right and this one is stale.

How to prepare using this course

☺ Like you're 10: There's already a page here for almost everything on the test — this is the short list of where to start.

Read How to Study for a CNCF Exam first for the general method, then work this exam's own pages: CKAD Study Plan for a full week-by-week schedule sized to the domain weights above, CKAD Practice Tasks for graded reps, and Mock Exam · Set 1 and Set 2 for full timed runs. The hands-on labs — the capstone track and the seven guided drills — are where the manifest above stops being something you read and starts being something your hands do without thinking. Keep a running list of anything that trips you up in Field Notes, and use the glossary whenever a term above doesn't fully click.