CKAD — Certified Kubernetes Application Developer

The CKAD asks a narrower question than its sibling exam: not can you run a cluster, but can you design, build, and deploy a working application onto one that someone else already runs? Same format as the CKA — live terminal, real clusters, no multiple choice, two hours on the clock — pointed entirely at the developer's half of Kubernetes: container images, multi-container Pod patterns, Deployments and rollouts, ConfigMaps and Secrets, Services and Ingress. If you read the CKA page and felt like a third of it wasn't your job, this is probably the exam you actually want. Below: what it tests, the official domains and weights, exactly how it's different from the CKA, and how to prepare with the lessons already on this site.

What CKAD is, and who it's for

☺ Like you're 10: It's a two-hour hands-on test, just like the CKA — except every single task is about an application running on the cluster, never the cluster itself.

The Certified Kubernetes Application Developer is the CNCF and Linux Foundation's credential for people who build and ship applications onto Kubernetes, as opposed to the CKA's focus on the people who operate the cluster underneath them. It launched in 2018, a year after the CKA, specifically to give application developers their own performance-based exam instead of forcing them to sit a cluster-administration test full of etcd and kubeadm content they'd never touch on the job.

Performance-based, same format as the CKA

There's no multiple choice anywhere on this exam either. You're dropped into a browser-based terminal with several pre-built clusters and namespaces, and handed tasks like "In namespace shop, create a Deployment named web running image registry.example.com/web:1.5.0 with 3 replicas, expose it via a ClusterIP Service on port 80, and configure a liveness probe against /healthz." Grading is on the end state — the Deployment exists, the Service actually routes to it, the probe is configured correctly — not on the elegance of the YAML you wrote to get there. Speed matters just as much as it does on the CKA: most tasks are individually fast if you know the object model cold, and the clock punishes anyone who doesn't.

Who should sit it

It targets application developers writing Kubernetes-native software, and just as often it targets DevOps engineers who deploy onto clusters they don't administer — someone who owns CI/CD pipelines, writes the Deployment manifests and Helm charts, and needs a workload to run cleanly and stay observable, but who has a platform team or a managed control plane handling nodes, etcd, and cluster upgrades. It assumes comfort with containers (you should already know what a Dockerfile does) and basic kubectl, but it does not assume you've ever touched a node's filesystem or restored an etcd snapshot.

CKAD versus CKA — which exam actually matches your job

☺ Like you're 10: They feel identical on the day — same clock, same terminal, same no-multiple-choice format — but they hand you completely different broken things to fix.

Both exams are run by the same organizations, cost roughly the same, last two hours, and are graded the same way: on whether the cluster ends up in the state the task asked for. That's where the similarity ends. The CKA hands you a cluster that might be broken at the control-plane or node level and expects you to fix the substrate; the CKAD hands you a cluster that already works and expects you to build a correct, well-configured application on top of it.

In practice the honest test is which broken thing you'd rather be handed at 2 a.m.: a Pod stuck in CrashLoopBackOff because of a bad readiness probe and a missing ConfigMap key (CKAD territory), or a cluster where the API server won't start because someone edited a static Pod manifest on the wrong node (CKA territory). Most DevOps engineers who deploy onto Kubernetes without owning cluster operations live entirely in the first world — which makes CKAD the higher-signal, faster-to-prepare-for credential for that specific job.

The official domains and weights (CKAD curriculum v1.35)

☺ Like you're 10: Five topics, and one of them — configuration and security — is worth more than any of the others on its own.

These are the five domains and weights as published in the CNCF's Certified Kubernetes Application Developer (CKAD) Exam Curriculum, version 1.35, kept in sync with the same release train as the CKA curriculum. They sum to exactly 100% — 25 + 20 + 20 + 20 + 15. Note the shape: Application Environment, Configuration and Security alone is 25%, ahead of every other domain, which tells you where the exam's actual center of gravity sits.

The competencies below are transcribed one bullet per published item. As with the CKA curriculum, treat the exact wording and weights as a snapshot — the CNCF revises this document with roughly every Kubernetes minor version, and it's published openly for you to check against.

25% — Application Environment, Configuration and Security

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

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

20% — Services and Networking

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

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
• Debug in Kubernetes

That's 23 published competencies in total: 7 + 4 + 4 + 3 + 5. Two things surprise people who last studied an older CKAD syllabus: Kustomize now sits explicitly under Application Deployment alongside Helm, and API deprecations is its own competency under Observability and Maintenance — a real, examinable skill given how often Kubernetes removes beta APIs between minor versions.

What you actually need to be able to do

☺ Like you're 10: Here's the real work behind each bullet point above — the YAML and commands your fingers need to produce without a search engine.

Application Design and Build

You need a working mental model of how a container image is actually built — multi-stage Dockerfiles that keep the shipped image small and run as a non-root user — and fluency with the multi-container Pod patterns the curriculum names explicitly: an init container that runs to completion before the main container starts, and a sidecar that runs alongside it for the Pod's whole lifetime, sharing its network namespace and any volumes you mount into both.

# multi-stage build: compile in a full image, ship almost nothing
FROM golang:1.23 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /out/app .

FROM gcr.io/distroless/static-debian12
COPY --from=build /out/app /app
USER 65532:65532
ENTRYPOINT ["/app"]

apiVersion: v1
kind: Pod
metadata:
  name: web-with-sidecar
spec:
  initContainers:
    - name: fetch-config              # runs once, to completion, before 'app' starts
      image: busybox:1.36
      command: ["sh", "-c", "wget -qO /config/app.conf https://config.example.com/app.conf"]
      volumeMounts:
        - { name: config, mountPath: /config }
  containers:
    - name: app
      image: registry.example.com/web:1.5.0
      volumeMounts:
        - { name: config, mountPath: /etc/app }
    - name: log-shipper                # sidecar: same Pod, same lifecycle, same network namespace
      image: fluent/fluent-bit:3.1
      volumeMounts:
        - { name: logs, mountPath: /var/log/app }
  volumes:
    - { name: config, emptyDir: {} }
    - { name: logs, emptyDir: {} }

Workload resource choice is graded too: a stateless web tier is a Deployment, a per-node agent is a DaemonSet, a scheduled batch job is a CronJob, and a workload that needs stable network identity and ordered startup is a StatefulSet. Picking the wrong one is a wrong answer even if the Pod spec inside it is perfect. Fuller context lives in containers & orchestration.

Application Deployment

Deployments, rolling updates, and rollback with kubectl rollout undo are the baseline. The curriculum explicitly names blue/green and canary as strategies to implement with Kubernetes primitives — meaning you build them out of ordinary Deployments, Services, and labels, not a dedicated CRD, because that CRD-based tooling belongs to Argo CD and friends, which sit outside this exam.

# imperative skeleton first, then edit — fastest path under a clock
kubectl create deployment web --image=registry.example.com/web:1.4.2 \
  --replicas=4 --dry-run=client -o yaml > web.yaml
kubectl apply -f web.yaml

kubectl set image deployment/web web=registry.example.com/web:1.5.0
kubectl rollout status deployment/web
kubectl rollout history deployment/web
kubectl rollout undo deployment/web --to-revision=2

# blue/green: two Deployments, one Service, flip the selector to cut over
kubectl label deployment web-green track=live --overwrite
kubectl patch service web -p '{"spec":{"selector":{"track":"live"}}}'

# canary: same Service selector on both, unequal replica counts control traffic share
kubectl scale deployment web-stable --replicas=9
kubectl scale deployment web-canary --replicas=1   # ~10% of requests land on the canary

# Helm and Kustomize both count for this domain
helm upgrade --install web example/web-app --version 2.3.1 \
  --namespace shop --create-namespace --set image.tag=1.5.0
kubectl apply -k overlays/production/

See deployment strategies for the concepts and feature flags & progressive delivery for how canary and blue/green extend past what a bare Deployment can express.

Application Observability and Maintenance

Probes are the piece people under-rehearse: a startup probe protects a slow-booting container from being killed by liveness checks before it's actually ready, a liveness probe restarts a container that's alive but stuck, and a readiness probe pulls a Pod out of a Service's Endpoints without restarting it — three different failure modes, three different probes, and the exam will hand you a Pod with the wrong one configured.

containers:
  - name: web
    image: registry.example.com/web:1.5.0
    startupProbe:
      httpGet: { path: /healthz, port: 8080 }
      failureThreshold: 30
      periodSeconds: 2            # up to 60s to finish booting before liveness takes over
    livenessProbe:
      httpGet: { path: /healthz, port: 8080 }
      periodSeconds: 10
      failureThreshold: 3         # three misses in a row -> container restarted
    readinessProbe:
      httpGet: { path: /ready, port: 8080 }
      periodSeconds: 5
      failureThreshold: 2         # pulled out of the Service, container keeps running

# the debugging sequence CKAD actually rewards
kubectl logs deploy/web -c web --since=10m --previous
kubectl describe pod web-7d9f4c8b9-x2k5n | tail -20        # Events are at the bottom
kubectl debug pod/web-7d9f4c8b9-x2k5n -it --image=busybox:1.36 --target=web
                                                              # ephemeral container, shares web's namespaces

# API deprecations: confirm what the cluster actually serves before you trust an old manifest
kubectl api-versions | grep networking.k8s.io
kubectl explain ingress --api-version=networking.k8s.io/v1

Application Environment, Configuration and Security

The heaviest domain, and mostly a matter of knowing the objects cold: ConfigMaps and Secrets consumed as environment variables or mounted volumes, resource requests and limits, ServiceAccounts, and a SecurityContext locked down the way a real reviewer would expect.

apiVersion: v1
kind: ConfigMap
metadata: { name: web-config, namespace: shop }
data:
  LOG_LEVEL: "info"
  FEATURE_NEW_CHECKOUT: "true"
---
apiVersion: v1
kind: Secret
metadata: { name: web-secrets, namespace: shop }
type: Opaque
stringData:
  DATABASE_URL: "postgres://app:REPLACE_ME@db.shop.svc:5432/orders"
---
apiVersion: apps/v1
kind: Deployment
metadata: { name: web, namespace: shop }
spec:
  replicas: 3
  selector: { matchLabels: { app: web } }
  template:
    metadata: { labels: { app: web } }
    spec:
      serviceAccountName: web-runtime
      containers:
        - name: web
          image: registry.example.com/web:1.5.0
          envFrom:
            - configMapRef: { name: web-config }
            - secretRef: { name: web-secrets }
          resources:
            requests: { cpu: "250m", memory: "256Mi" }
            limits:   { cpu: "500m", memory: "512Mi" }
          securityContext:
            runAsNonRoot: true
            runAsUser: 10001
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities: { drop: ["ALL"] }

RBAC in this domain is scoped narrower than on the CKA — you're expected to create a Role and RoleBinding for a ServiceAccount and confirm it with kubectl auth can-i, not design cluster-wide access policy. This is the domain where secrets & credential management and shift-left security for DevOps pay off directly.

Services and Networking

Lighter than the CKA's networking domain and asked from the consumer's side: expose a Deployment with a Service, get traffic in from outside with an Ingress, and show a basic-but-correct NetworkPolicy rather than debug a subtle one.

apiVersion: v1
kind: Service
metadata: { name: web, namespace: shop }
spec:
  selector: { app: web }
  ports:
    - { port: 80, targetPort: 8080 }
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata: { name: web, namespace: shop }
spec:
  ingressClassName: nginx
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service: { name: web, port: { number: 80 } }
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: db-allow-from-web, namespace: shop }
spec:
  podSelector: { matchLabels: { app: db } }   # selecting a Pod flips it to deny-by-default
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector: { matchLabels: { app: web } }
      ports:
        - { protocol: TCP, port: 5432 }

# quick service sanity check every CKAD candidate should have cold
kubectl get endpointslices -n shop -l kubernetes.io/service-name=web
kubectl run tmp --rm -it --image=busybox:1.36 --restart=Never -n shop \
  -- wget -qO- web.shop.svc.cluster.local

How to prepare using this site

☺ Like you're 10: Here's the map from each exam topic to the exact page here that teaches it, so you can start today.

This course is written for practicing DevOps engineers, so it runs deeper than CKAD on pipelines and delivery strategy and lighter on raw kubectl repetition — the gap worth closing with hands-on practice on a real cluster, which is also exactly what the exam rewards.

A workable four-week shape

CKAD's scope is narrower than the CKA's, and most working DevOps engineers already know a slice of it cold from daily deploys — so four weeks is realistic where the CKA warranted six. Week 1: images, multi-container Pod patterns, and workload resource choice, all imperative, no copy-paste. Week 2: Deployments, rollouts, Helm, and Kustomize — build a blue/green cutover and a canary by hand at least once. Week 3: ConfigMaps, Secrets, SecurityContexts, and a RoleBinding, then Services, Ingress, and one NetworkPolicy a day. Week 4: nothing but timed end-to-end runs like Benny and Olly's workshop above, plus a pass through the flashcards and the exam simulator. The habit that pays for itself fastest: alias k=kubectl and export do="--dry-run=client -o yaml" before the clock starts.

Exam logistics — and why you must verify them yourself

☺ Like you're 10: The shape of the test changes now and then. Read the official page before you pay for anything.

The details below are what the Linux Foundation and CNCF generally publish and what candidates consistently report. They're here to help you plan, not to be quoted back at anyone — several of them have changed at some point in the exam's history, exactly as they have for the CKA.

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

☺ Like you're 10: It's a middle rung, sitting right next to the CKA rather than above or below it.

Treat the CNCF certifications as a floor plan, not a straight line. KCNA is the entry-level, knowledge-based rung below both practitioner exams. CKA and CKAD sit side by side at practitioner level — same performance-based format, same clock, aimed at two different jobs on the same platform. Above them, CKS requires an active CKA specifically and goes deep on hardening, supply chain, and runtime security — a natural next step for a CKA holder, and a detour for a CKAD holder without one. Container fundamentals underneath CKAD's Design and Build domain are also covered from a different angle by Docker Certified Associate, if that gap is the one you actually have.

For most DevOps engineers who deploy onto Kubernetes without owning the cluster, CKAD is a complete, self-sufficient credential on its own — it doesn't need to be a stepping stone to anything. If your role later shifts toward owning the platform itself, the CKA is the natural next stop, not because CKAD was incomplete, but because it was never trying to cover that ground in the first place. The full comparison against every other certification on this site's radar lives on the certifications hub.