CKAD is the Kubernetes cert that proves you can actually build for it.

The majority of cloud certifications in 2026 are multiple-choice exams. You can study flashcard decks, memorise which AWS service handles which use case, and pass at 72% without ever having opened a terminal in a production environment. The CKAD closes that gap entirely. The Cloud Native Computing Foundation and Linux Foundation administer the exam on a live Kubernetes cluster, and your score is determined by automated scripts that check the state of that cluster after each task. Either your Pod is running with the correct image and resource limits, or it is not. Either your Ingress routes traffic correctly to the backend service, or it does not.

This format matters because Kubernetes is operationally unforgiving. A misconfigured liveness probe brings down a Deployment. A missing securityContext fails an admission controller. A NetworkPolicy with an incorrect podSelector silently blocks traffic that the application expects. Engineers who have only read about Kubernetes consistently make these errors in production; engineers who have practiced under exam conditions are far less likely to. The CKAD is not a perfect proxy for production experience, but it is a meaningful signal that a candidate has sat down with a live cluster and solved real configuration problems under time pressure.

CKAD is specifically designed for developers and DevOps engineers who build and deploy applications on Kubernetes — not for platform engineers who provision and administer clusters. The CKA (Certified Kubernetes Administrator) covers cluster-level operations: etcd backup and restore, cluster upgrades, node management, kubeadm, and cluster networking configuration. CKAD focuses on the workload layer: Pods, Deployments, Services, ConfigMaps, Secrets, Ingress, NetworkPolicies, Helm charts, and application observability. Both certifications use the same live terminal format; many engineers eventually hold both.

What CKAD tests: the five domains

The 2023 CKAD curriculum update reorganised the exam into five domains. Red Hat's RHCSA and the CKA exams are updated periodically to track Kubernetes releases; the CKAD follows the same pattern. Exam tasks in 2026 run on Kubernetes 1.31 and use the tool versions available in the exam environment: kubectl, helm v3, and kustomize.

Domain 1: Application Design and Build — 20%

Designing container-based applications and choosing the correct Kubernetes workload resource for each use case. This domain tests foundational understanding of how applications are packaged and run on Kubernetes.

  • Container images: Define, build, and modify container images. Know the Dockerfile instructions that affect runtime behaviour: CMD vs ENTRYPOINT (CMD provides default arguments, ENTRYPOINT defines the executable — overriding ENTRYPOINT requires --entrypoint in the run command; overriding CMD is the default argument position). EXPOSE documents a port but does not publish it. ENV sets environment variables available at runtime. Understand multi-stage builds for reducing image size. The exam environment provides docker or podman for image operations.
  • Workload resources: Choose the right resource for the use case. Deployment for stateless applications with rolling updates and rollback. StatefulSet for stateful applications requiring stable network identity and ordered deployment (databases, message brokers). DaemonSet for workloads that must run on every node (log collectors, monitoring agents, network plugins). Job for batch tasks that run to completion. CronJob for scheduled recurring tasks — know the cron syntax and the concurrencyPolicy (Allow, Forbid, Replace), successfulJobsHistoryLimit, and failedJobsHistoryLimit fields.
  • Multi-container Pod patterns: The sidecar pattern (helper container enhances the main container — log shipper, proxy, secret rotation agent). The init container pattern (runs to completion before the main container starts — used for database migration, configuration fetching, permission setting). The ambassador pattern (proxy sidecar that abstracts a remote service). Know how to define initContainers in a Pod spec and understand that init containers share the Pod's volumes but run sequentially, each to completion, before any app container starts.
  • Persistent and ephemeral volumes: emptyDir is created when a Pod is scheduled and deleted when the Pod terminates — use for temporary scratch space or sharing data between containers in the same Pod. hostPath mounts a node filesystem path into the Pod — understand the security implications. PersistentVolumeClaim requests storage from a PersistentVolume or dynamic provisioner. Know how to mount a PVC into a Pod via volumes and volumeMounts. Understand accessModes: ReadWriteOnce, ReadOnlyMany, ReadWriteMany.

Domain 2: Application Deployment — 20%

Deploying applications to Kubernetes using both primitive resources and package management tools. This domain includes rolling update strategies, Helm, and Kustomize — the tools that define how applications are shipped to real clusters.

  • Deployments and rolling updates: Create a Deployment imperatively: kubectl create deployment nginx --image=nginx:1.25 --replicas=3. Update the image: kubectl set image deployment/nginx nginx=nginx:1.26. Monitor the rollout: kubectl rollout status deployment/nginx. Roll back: kubectl rollout undo deployment/nginx. View rollout history: kubectl rollout history deployment/nginx. The exam will ask you to perform updates and verify the rollout completes successfully. Know the strategy.rollingUpdate.maxSurge and maxUnavailable fields that control how many Pods are replaced at once.
  • Blue/green and canary deployments: Kubernetes does not have native blue/green or canary objects — these patterns are implemented using multiple Deployments with label selectors. Blue/green: run two identical Deployments (blue and green); switch traffic by updating the Service selector from version: blue to version: green. Canary: run a second Deployment with fewer replicas and the same label that the Service selects — a percentage of traffic routes to the canary based on the ratio of replicas. Know how to create and modify Service selectors with kubectl edit or kubectl patch.
  • Helm: The exam includes Helm v3 tasks. Know the core workflow: helm repo add name url adds a chart repository. helm repo update updates the local cache. helm install release-name chart-name --namespace ns deploys a chart. helm upgrade release-name chart-name upgrades a release. helm rollback release-name revision rolls back to a previous revision. helm list -n namespace lists installed releases. helm uninstall release-name removes a release. Override chart values with --set key=value or -f values.yaml. The exam typically asks you to install a chart from a provided repository with specific values — practice the full workflow without reference material.
  • Kustomize: Kustomize is a built-in kubectl feature (kubectl apply -k ./dir) and also available as a standalone kustomize binary. It layers configuration changes on top of base YAML without templating. A kustomization.yaml file in a directory defines resources, patches, commonLabels, and namePrefix/nameSuffix. The exam may ask you to use a provided kustomize directory structure to apply or preview changes: kubectl kustomize ./dir to preview, kubectl apply -k ./dir to apply.

Domain 3: Application Observability and Maintenance — 15%

The lowest-weighted domain but the one that catches the most candidates off guard. Observability tasks in the exam test your ability to understand what a running application is doing, why it is failing, and how to confirm it is healthy.

  • Probes and health checks: The three probe types. livenessProbe: if it fails, the kubelet kills the container and restarts it (subject to the Pod's restartPolicy). Use for detecting deadlocks. readinessProbe: if it fails, the Pod is removed from Service endpoints — it stops receiving traffic but is not restarted. Use for detecting when an application is not ready to serve requests (still initialising, temporarily overloaded). startupProbe: runs before liveness and readiness probes; gives slow-starting applications time to initialise without being killed. Probe types: httpGet (HTTP GET against a path and port), tcpSocket (TCP connection check), exec (runs a command inside the container — success is exit code 0). Key fields: initialDelaySeconds, periodSeconds, failureThreshold, successThreshold, timeoutSeconds.
  • Container logs: kubectl logs pod-name streams logs from a single-container Pod. kubectl logs pod-name -c container-name for a specific container in a multi-container Pod. kubectl logs pod-name --previous shows logs from the previous (crashed) container instance — critical for debugging crash loops. kubectl logs pod-name -f follows logs in real time. kubectl logs -l app=myapp aggregates logs from all Pods matching a label selector.
  • Debugging Pods: kubectl describe pod pod-name shows events (scheduling failures, image pull errors, probe failures) and the current state of each container. kubectl get events --sort-by=.lastTimestamp shows cluster events in chronological order. For interactive debugging: kubectl exec -it pod-name -- /bin/sh (or /bin/bash). Ephemeral debug containers: kubectl debug -it pod-name --image=busybox --target=container-name attaches a temporary debug container to a running Pod without requiring a restart.
  • Monitoring with metrics-server: kubectl top nodes and kubectl top pods show resource consumption from metrics-server. These commands require metrics-server to be installed in the cluster. The exam environment provides this; if kubectl top returns no output, metrics-server may not be ready yet.
  • API deprecations: Kubernetes deprecates API versions on a defined schedule. Know how to check whether a resource manifest is using a deprecated API: kubectl api-versions lists all available API versions. kubectl explain resource.field shows the current API schema. Deprecated resources in old YAML manifests must be updated to current API groups before applying to newer clusters.

Domain 4: Application Environment, Configuration, and Security — 25%

The highest-weighted domain and the one with the most detail. Configuration and security are where most real-world Kubernetes application failures originate, and the exam reflects this with a proportionally higher question count.

  • ConfigMaps: Create a ConfigMap from literal values: kubectl create configmap app-config --from-literal=DB_HOST=localhost --from-literal=DB_PORT=5432. From a file: kubectl create configmap app-config --from-file=config.properties. Consume in a Pod as environment variables via envFrom.configMapRef (injects all keys as env vars) or env.valueFrom.configMapKeyRef (injects a single key). Mount as a volume (each key becomes a file, value becomes file content) via volumes.configMap and volumeMounts. Know that ConfigMap changes do not automatically propagate to running Pods when used as environment variables — the Pod must be restarted. Volume-mounted ConfigMaps update eventually without a restart.
  • Secrets: Create a Secret: kubectl create secret generic db-secret --from-literal=password=mysecretpass. TLS Secret: kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key. Consume identically to ConfigMaps (envFrom, env.valueFrom.secretKeyRef, volume mount). Understand that Secrets are base64-encoded in etcd by default, not encrypted — encryption at rest requires additional cluster configuration. The exam will ask you to create Secrets and inject them into Pods.
  • ServiceAccounts: Every Pod runs under a ServiceAccount. The default ServiceAccount in each namespace has minimal permissions. Create a custom ServiceAccount: kubectl create serviceaccount my-sa. Assign it to a Pod via spec.serviceAccountName. ServiceAccount tokens are auto-mounted into Pods at /var/run/secrets/kubernetes.io/serviceaccount/token — disable automatic mounting with automountServiceAccountToken: false for Pods that do not need to call the Kubernetes API.
  • SecurityContexts: A securityContext can be set at the Pod level (applies to all containers) or at the container level (overrides the Pod-level setting). Key fields: runAsUser and runAsGroup (the UID/GID the container process runs as), runAsNonRoot: true (fails if the container image runs as UID 0), readOnlyRootFilesystem: true (mounts the container root filesystem as read-only — best practice for most workloads), allowPrivilegeEscalation: false (prevents the process from gaining more privileges than its parent), capabilities.add and capabilities.drop (add or remove Linux capabilities). The exam will ask you to configure a Pod to run as a specific user, disable privilege escalation, or drop all capabilities and add only the ones required.
  • Resource requests and limits: resources.requests is what the scheduler uses to place the Pod — the scheduler finds a node with at least this much CPU and memory available. resources.limits is the ceiling — the container is throttled if it exceeds the CPU limit and OOMKilled if it exceeds the memory limit. Requests must be ≤ limits. A container with a memory limit but no memory request has its request set equal to its limit. Know the units: CPU in cores (1.0 = one core) or millicores (500m = 0.5 cores); memory in bytes, Ki, Mi, Gi.
  • Resource Quotas and LimitRanges: ResourceQuota limits the total resource consumption in a namespace (total CPU, memory, number of Pods, number of Services). LimitRange sets defaults and constraints on resource requests and limits for individual containers in a namespace — if a container is created without resource requests and limits, the LimitRange's defaults are applied. Know how to create both and understand how they interact: a Pod that exceeds a ResourceQuota is rejected at admission.
  • Custom Resource Definitions and Operators: CRDs extend the Kubernetes API with custom resource types. Know how to list installed CRDs (kubectl get crd), view the schema of a CRD (kubectl explain myresource once installed), and create instances of a custom resource. Operators are controllers that manage the lifecycle of a custom resource — CKAD expects familiarity with how to interact with Operators (deploying via Helm or applying an Operator manifest), not with writing them.

Domain 5: Services and Networking — 20%

Exposing applications to traffic within the cluster and externally. NetworkPolicies for controlling traffic flow are a common exam failure point — the selector logic is unintuitive until you have practiced it extensively.

  • Services: The four Service types. ClusterIP (default): exposes the Service on an internal cluster IP. Accessible only within the cluster. NodePort: exposes the Service on each node's IP at a static port (30000–32767 range). Accessible from outside the cluster by connecting to any node IP + the NodePort. LoadBalancer: provisions a cloud load balancer (on supported platforms) that routes external traffic to the Service. ExternalName: maps the Service to a DNS name by returning a CNAME record — used for bridging cluster workloads to external services. Create a Service imperatively: kubectl expose deployment myapp --port=80 --target-port=8080 --type=ClusterIP. Know how label selectors link Services to Pods — a Service routes traffic to Pods whose labels match spec.selector.
  • Ingress: An Ingress resource defines HTTP/HTTPS routing rules that an Ingress controller (nginx, Traefik, HAProxy) enforces. Key fields: spec.rules[].host (the hostname to match), spec.rules[].http.paths[].path and pathType (Exact, Prefix, ImplementationSpecific), spec.rules[].http.paths[].backend.service.name and port.number. TLS termination: spec.tls[].hosts and spec.tls[].secretName (the Secret must contain tls.crt and tls.key). The exam environment includes an Ingress controller — you only need to create the Ingress resource, not install the controller.
  • NetworkPolicies: By default, all Pods in a Kubernetes cluster can communicate with all other Pods. A NetworkPolicy selects Pods and defines allowed ingress (incoming) and egress (outgoing) traffic rules. If a Pod is selected by at least one NetworkPolicy, only traffic explicitly allowed by a NetworkPolicy is permitted — all other traffic is denied. If a Pod is not selected by any NetworkPolicy, all traffic is allowed. Key selector fields in a NetworkPolicy: podSelector (selects the Pods the policy applies to — an empty podSelector selects all Pods in the namespace), namespaceSelector (selects Pods in matching namespaces), ipBlock (selects IP ranges). A rule can combine podSelector AND namespaceSelector in a single from entry (both must match) or list them separately (either match). This distinction is the most commonly misunderstood part of NetworkPolicy and the most reliably tested on the CKAD exam.
The single most common CKAD failure is running out of time because candidates write YAML from scratch for every task. The exam environment provides kubectl with imperative commands, the --dry-run=client -o yaml flag to generate YAML skeletons, and documentation at kubernetes.io/docs. Generate, edit, apply — never write a Pod spec from scratch. Saving three minutes per task across 17 tasks is the difference between finishing and not finishing.

Exam format and practical tips

The CKAD exam runs in a browser-based terminal environment. You receive access to multiple Kubernetes clusters (each task specifies which context to use — always run kubectl config use-context cluster-name at the start of each task before touching any resources). The exam environment provides kubectl, helm, vim, nano, and access to the official Kubernetes documentation at kubernetes.io.

The most important exam technique is using kubectl imperatively to generate YAML skeletons rather than writing manifests from scratch. The pattern is: kubectl create deployment myapp --image=nginx:1.25 --dry-run=client -o yaml > deploy.yaml — then edit the generated YAML to add the fields required by the task (resource limits, probes, volume mounts) and apply with kubectl apply -f deploy.yaml. This is faster and less error-prone than hand-writing YAML under time pressure. Master the imperative commands that generate YAML for the most common resource types: kubectl create deployment, kubectl create service, kubectl create configmap, kubectl create secret, kubectl create ingress, kubectl create job, kubectl create cronjob, kubectl create serviceaccount.

Set up shell aliases and tab completion before the exam starts. The exam environment allows you to configure your shell during the exam: alias k=kubectl, export do="--dry-run=client -o yaml", export now="--force --grace-period=0". These aliases reduce keystrokes significantly across 15–20 tasks. Enable kubectl bash completion with source <(kubectl completion bash) — this allows tab-completion for resource names, which eliminates a class of typos that cause tasks to fail silently.

Exam logistics

CKAD costs approximately $395 USD and includes one free retake if you fail. The exam is proctored remotely via a webcam and screen share. Scheduling is available globally through the Linux Foundation's portal. Results are delivered within 24 hours of completing the exam. The CKAD credential is valid for three years; recertification requires passing the exam again (there is no continuing education credit path). The Linux Foundation occasionally offers bundle pricing for CKAD + CKA + CKS.

CKAD vs CKA vs CKS

The CNCF Kubernetes certification stack consists of three exams. They share the same live terminal format and exam delivery platform. Understanding what each tests helps you choose the right starting point and plan your progression.

The CNCF Kubernetes certification track

  • CKAD — Certified Kubernetes Application Developer: Application-layer focus. Workloads, Helm, ConfigMaps, Secrets, SecurityContexts, Services, Ingress, NetworkPolicies. Designed for developers and DevOps engineers who deploy to Kubernetes. The right starting point if you write code or CI/CD pipelines that target Kubernetes.
  • CKA — Certified Kubernetes Administrator: Cluster-level focus. Cluster installation with kubeadm, etcd backup and restore, node management and troubleshooting, cluster networking (CNI plugins, DNS), RBAC at cluster scope, storage classes and PersistentVolumes. Designed for platform engineers and SREs who operate Kubernetes clusters. The right starting point if you are responsible for the cluster itself rather than the workloads running on it.
  • CKS — Certified Kubernetes Security Specialist: Security focus. Requires a current CKA or CKAD to attempt. Covers cluster hardening (API server flags, network policies, RBAC), supply chain security (image scanning with Trivy, signing), runtime security (Falco, AppArmor, Seccomp profiles), and monitoring for security anomalies. Designed for security engineers working with Kubernetes in regulated or high-security environments. CKS holders earn $140k–$185k in security-focused cloud roles.
  • KCNA — Kubernetes and Cloud Native Associate: A multiple-choice entry-level cert that covers Kubernetes fundamentals, cloud native concepts, GitOps, observability, and container runtimes. Not a practical exam — a knowledge test. Useful as a confidence-building stepping stone before CKAD for candidates with no prior Kubernetes exposure, but not a substitute for the practical certs.
  • KCSA — Kubernetes and Cloud Native Security Associate: The multiple-choice counterpart to CKS, introduced in 2023. Tests security concepts at a conceptual level without requiring a live cluster. Useful for security professionals assessing Kubernetes environments without hands-on operational responsibilities.

Certification stack and career paths

Where CKAD fits in the cloud-native career map

  • CKAD → CKA → CKS — The full CNCF practical certification track. CKAD establishes your workload-layer competency, CKA proves cluster administration, and CKS signals security depth. Engineers holding all three are rare and command $150k–$185k in platform engineering and cloud security roles in 2026. Many employers who run Kubernetes at scale list CKA or CKAD as required or preferred on job postings.
  • CKAD + AWS SAA-C03 or AZ-104 — A powerful cross-cloud combination. AWS EKS, Azure AKS, and GCP GKE all run Kubernetes. Pairing CKAD with a cloud provider certification proves you can deploy workloads and understand the managed Kubernetes offering's networking, IAM integration, and storage provisioning. This combination targets DevOps Engineer and Cloud Engineer roles paying $120k–$155k.
  • CKAD + Terraform Associate — The IaC + workload stack for GitOps and platform engineering roles. Terraform provisions the infrastructure (EKS cluster, VPC, IAM roles); CKAD covers deploying and configuring the workloads on that infrastructure. Platform engineers who hold both can own the full stack from cluster provisioning to application delivery.
  • CKAD + GitHub Actions / ArgoCD experience — CKAD covers the Kubernetes primitives; adding CI/CD tooling completes the delivery pipeline picture. Employers building GitOps workflows (code push → image build → Helm chart update → ArgoCD sync → Kubernetes rollout) value engineers who understand both the pipeline orchestration and the Kubernetes deployment mechanics.
  • CKAD for software engineers moving into DevOps or SRE — Many software engineers in 2026 are expected to deploy and operate their own services on Kubernetes. CKAD is the fastest path to demonstrating that competency formally. The exam content maps directly to day-to-day tasks in a modern cloud-native team: writing Deployments, debugging failing Pods, configuring resource limits, and exposing services via Ingress.

Salary data and job market (2026)

Kubernetes continues to dominate container orchestration in 2026, with adoption reaching the majority of cloud workloads at organisations with more than 500 employees. The CNCF's 2025 annual survey reported that 84% of respondents use Kubernetes in production — up from 78% in 2022. This adoption curve has driven strong demand for engineers who can prove Kubernetes competency.

CKAD holders in DevOps Engineer, Platform Engineer, and Site Reliability Engineer roles earn $120k–$160k in major US markets in 2026. Engineers who combine CKAD with CKA or a security cert (CKS, AZ-500, SCS-C02) reach $140k–$185k. Cloud native architecture roles (designing multi-cluster or service mesh environments) command $155k–$195k and typically require significant production experience alongside the certification.

The certification has particularly strong recognition at technology companies and enterprises running microservices architectures at scale. Consulting and professional services firms (Accenture, Deloitte, SADA, Slalom) actively hire CKAD/CKA-certified engineers to staff cloud migration and platform modernisation engagements. Government and defence sector cloud deployments using Kubernetes (on-premises OpenShift, AWS GovCloud EKS) also hire CNCF-certified engineers at competitive rates with clearance premiums.

How to prepare for CKAD

CKAD is a practical exam. Reading about Kubernetes or watching video courses is insufficient preparation without sustained hands-on practice. The standard preparation timeline is 2–3 months of daily practice for candidates with existing Docker and Linux experience, or 3–5 months for those approaching Kubernetes from scratch.

Practice Kubernetes and IT certification concepts with CertQuests — scenario-based quizzing for CKAD, CKA, AWS, Azure, and more.

Browse Practice Packs →