CKAD — Certified Kubernetes Application Developer

The CKAD certifies the person your platform exists to serve. It is a hands-on, performance-based exam about authoring and running workloads on Kubernetes: designing Pods, deploying them, wiring in config and secrets, exposing them through Services and Ingress, and debugging them when they misbehave. For a platform engineer that makes it an unusually useful credential — not because you will spend your days writing Deployments, but because every golden path you pave ends at a developer doing exactly these tasks. This page covers the five official domains and weights from the CNCF curriculum, what you genuinely need to know, an honest verdict on whether to sit it, and a study plan built from lessons already here.

What the CKAD is, and who it is for

☺ Like you’re 10: It’s a two-hour test on a real computer where you have to actually make apps run on Kubernetes — not tick boxes about them.

The CKAD is one of the CNCF and Linux Foundation’s performance-based Kubernetes certifications. No multiple choice: you are dropped into a browser terminal with several live clusters and a list of tasks — create this, fix that, expose the other — and graded on the resulting cluster state, not how you got there. Elegance earns nothing; a working object earns full marks.

Its scope is narrow and deep. Where CKA is about operating a cluster, CKAD assumes the cluster exists and someone else looks after it. Your job is everything inside a namespace: workloads, volumes, config, secrets, service accounts, probes, Services, Ingress, NetworkPolicies.

Who should sit it

• Application developers deploying onto Kubernetes — the primary audience.
• Platform engineers early in their journey, who need the workload layer to be reflex before abstracting it behind self-service.
• DevOps and SRE folk who inherited a cluster and want a structured sweep through the object model.
• Anyone about to design a golden path — you cannot pave a road you have never walked.

What it deliberately does not test

Not cluster installation, kubeadm, etcd, node registration, upgrades or control-plane forensics — that is CKA. Not threat modelling, runtime detection or supply-chain signing — that is CKS. And not platform design: nothing asks you to build an IDP, expose a custom API, or reason about cognitive load. It asks whether you can make an application run correctly, safely and observably in a namespace someone gave you.

Why a platform engineer might take it — and when to skip it

☺ Like you’re 10: Taking the cook’s test makes you a better kitchen-builder — but if you already cook daily, the badge teaches you little.

Here is the honest case. A platform engineer’s core product is an abstraction over the workload API — a Helm chart, a Kustomize base, a Backstage template. Abstractions built by people who never felt the underlying pain are the most reliable source of the anti-pattern this course calls the platform nobody asked for. CKAD makes you feel that pain: getting a readinessProbe right, a read-only mounted Secret, the Ingress that silently 404s on a wrong class annotation. Each is a defect you can now design out of your golden path. The second benefit is speed — the imperative kubectl fluency transfers straight to the CNPE and to every incident you will run.

When to skip it

Skip it if you already write and debug workload manifests daily and have done so for a year. CKAD will confirm what you know rather than teach you anything, and your money is better spent on CKA — the cluster-operations half platform engineers genuinely lack — or straight at CNPE, the credential that actually describes your job. On a limited budget with an infrastructure-facing role, CKA is the higher-value single purchase.

Take it if you are new to Kubernetes and want a forcing function, if you are moving from an application team into a platform team, or if you intend to collect CKA and CKS anyway — CKAD is the gentlest on-ramp and shares an exam environment with both.

The official domains and weights

☺ Like you’re 10: The test is split into five topics, and one of them — config and security — is a whole quarter on its own.

Transcribed from the CNCF’s published CKAD Exam Curriculum (document version 1.35): five domains and 24 competencies. The weights are 20 + 20 + 15 + 25 + 20 = 100% — if a study guide you are reading does not add up to exactly 100, it is out of date. The bars are sorted by weight so you can see where the marks live; the lists below keep the curriculum’s own ordering and its own 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

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

15% — Application Observability and Maintenance

• Understand API deprecations — the published PDF spells it “depreciations”; the topic is the real one, kubectl against removed API versions
• Implement probes and health checks
• Use built-in CLI tools to monitor Kubernetes applications
• Utilize container logs
• Debugging in Kubernetes

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.)

20% — Services and Networking

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

What you actually need to know

☺ Like you’re 10: Almost everything on the test lives in one file — the Pod spec. Learn that one thing really well and most of the exam is already done.

Strip away the domain names 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 is one manifest touching four of the five domains — a checklist of what you must write without looking anything up:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
  namespace: shop
spec:
  replicas: 3
  selector:
    matchLabels: { app: checkout }
  template:
    metadata:
      labels: { app: checkout }
    spec:
      serviceAccountName: checkout            # ServiceAccounts domain
      securityContext:
        runAsNonRoot: true
        fsGroup: 2000
      initContainers:                          # init pattern
        - name: wait-for-db
          image: busybox:1.36
          command: ["sh", "-c", "until nc -z db 5432; do sleep 2; done"]
      containers:
        - name: app
          image: ghcr.io/acme/checkout:1.4.3
          ports: [{ containerPort: 8080 }]
          envFrom:
            - configMapRef: { name: checkout-config }   # ConfigMaps
          env:
            - name: DB_PASSWORD                         # Secrets
              valueFrom:
                secretKeyRef: { name: checkout-db, key: password }
          resources:                                    # requests / limits
            requests: { cpu: 100m, memory: 128Mi }
            limits:   { cpu: 500m, memory: 256Mi }
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities: { drop: ["ALL"] }
          readinessProbe:                               # probes
            httpGet: { path: /healthz, port: 8080 }
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet: { path: /livez, port: 8080 }
            failureThreshold: 3
          volumeMounts:
            - { name: scratch, mountPath: /tmp }        # ephemeral volume
      volumes:
        - name: scratch
          emptyDir: {}

Speed is a skill, and it is examinable

Two hours is not long. Nobody types that from scratch under exam conditions — you generate a skeleton and edit it. This muscle memory separates a pass from a near-miss:

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

# 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 checkout --image=nginx --replicas=3 --dry-run=client -o yaml > d.yaml
kubectl create job hello --image=busybox --dry-run=client -o yaml -- echo hi
kubectl create cronjob nightly --image=busybox --schedule="0 2 * * *" -- /bin/sh -c date

# config & secrets without opening an editor
kubectl create configmap checkout-config --from-literal=TIER=gold --from-file=./app.properties
kubectl create secret generic checkout-db --from-literal=password='s3cr3t'

# expose, roll, inspect, undo — note: --record is deprecated, annotate change-cause instead
kubectl expose deployment checkout --port=80 --target-port=8080
kubectl set image deploy/checkout app=ghcr.io/acme/checkout:1.4.4
kubectl annotate deploy/checkout kubernetes.io/change-cause="bump to 1.4.4" --overwrite
kubectl rollout status deploy/checkout && kubectl rollout history deploy/checkout
kubectl rollout undo deploy/checkout --to-revision=2

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

Networking is a fifth of the exam and the easiest to under-study

Only three competencies, but 20% of the marks. Know the four Service types cold (ClusterIP, NodePort, LoadBalancer, ExternalName) plus the headless variant — which is not a type at all but clusterIP: None, giving you Pod addresses straight from DNS instead of a virtual IP. Then the selector-to-label relationship, the port triple (port / targetPort / nodePort), Ingress host and path rules under networking.k8s.io/v1 with an ingressClassName and an explicit pathType, and NetworkPolicy well enough for a default-deny plus a targeted allow. The classic task is “nothing can reach this app — fix it,” and the answer is usually a mismatched label, a wrong targetPort, or a policy with no matching rule:

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

Deeper background lives in Networking & Connectivity; the failure modes are catalogued in Triage · networking, RBAC & admission.

The parts a platform engineer will find familiar

Three competencies feel like home. “Discover and use resources that extend Kubernetes (CRD, Operators)” is the shallow end of Platform APIs, CRDs & Operators — you use a custom resource, you don’t build one. Helm and Kustomize are covered beyond exam depth in Helm, Kustomize and Configuration & Packaging. And “blue/green or canary” here means labels, selectors and two Deployments by hand — the primitive version of what Argo Rollouts automates.

How to prepare using this site

☺ Like you’re 10: Every topic on the test already has a page here — this table says which, so you can start today.

This site was written for the platform-engineering certifications, but the workload layer is shared ground and most CKAD topics already have a home here. Read the page, then do the task on a real cluster — reading alone never passed a performance exam. The hands-on sets live under Practice tasks and the guided builds under the lab track; the facts worth memorising outright are collected in Know cold.

A three-week plan

Week 1 — the Pod spec. Read Kubernetes as the Substrate and Configuration & Packaging. Hand-write a Deployment with probes, resources, a ConfigMap, a Secret and a security context — then rebuild it tomorrow from a generator in under four minutes.

Week 2 — around the Pod. Volumes, Services, Ingress, NetworkPolicy, Jobs and CronJobs. Do Networking and Storage, then break things deliberately and fix them with the triage playbook.

Week 3 — speed and packaging. Helm, Kustomize, blue/green and canary with plain primitives, then timed sets. Live in the Speed Reference until --dry-run=client -o yaml is something your hands do without you, and do a final pass over Know cold the night before.

Exam logistics — confirm every number before you book

☺ Like you’re 10: Here is roughly how test day works — but prices and rules change, so check the official page before you pay.

The following reflects the exam as commonly documented at the time of writing — orientation, not an authoritative source. Nothing in this table is a term of your purchase. Before you pay, confirm every row on the official Linux Foundation CKAD page and in the candidate handbook it links to; where they disagree with this page, they are right and this page is stale.

Deliberately absent: price and pass mark. Both move, both vary by region and promotion, and a stale number helps nobody. Read them on the official Linux Foundation CKAD page and the CNCF certification page, with the current candidate handbook — those are the contract; everything else, this site included, is commentary.

One stable practical note: the environment gives you multiple clusters, and every task names the cluster and namespace it belongs to. Getting that wrong is the commonest self-inflicted failure on any Kubernetes performance exam. Read the task, switch context, switch namespace, then type — the same discipline the CNPE rewards.

Where CKAD sits in the ladder, and what to do next

☺ Like you’re 10: These badges come in an order. CKAD is near the start, and points at two or three sensible next steps.

The Kubernetes certifications form a rough ladder; the platform-engineering ones sit alongside it rather than on top:

Heading for platform engineering? The highest-value next step is CKA — it fills in the cluster-operations half CKAD omits and is assumed knowledge across the CNPE blueprint. Then branch: CKS if your platform’s differentiator is security and policy, or CNPA then CNPE if it is self-service and developer experience. Every credential covered here is mapped on the Certifications hub.

Whichever you choose, keep the CKAD lens. The most useful sentence in a platform design review is “I’ve written that manifest by hand — here is the part that always goes wrong.” Turn that instinct into product with Developer Experience and Platform as a Product.