CKAD Exam Breakdown: Domains and Weights Explained

The CKAD is a 2-hour, performance-based exam with 15 to 20 tasks. You need a 66% to pass. The exam tests whether you can design, build, configure, and expose applications on Kubernetes using a live terminal. No multiple choice. Just you, kubectl, and a timer.

This CKAD exam breakdown covers every domain, what each weight means for your study time, and specific tips for scoring points in each section. If you want the full study plan, see our CKAD study guide. This article focuses on the exam structure itself.

CKAD Exam Format at a Glance

Detail	Value
Price	$445
Duration	2 hours
Format	Performance-based (live terminal)
Number of tasks	15 to 20
Passing score	66%
Validity	2 years
Free retake	Yes, one included
Practice sessions	Two included (36 hours each)
Prerequisites	None
Open book	kubernetes.io/docs only

The CKAD format is identical to the CKA. Same proctoring platform, same terminal environment, same documentation access. The difference is content. The CKA focuses on cluster administration. The CKAD focuses on application development and deployment. For a side-by-side comparison, see CKA vs CKAD: Which Should You Take First?.

CKAD Exam Domains and Weights

The CKAD curriculum has five domains. Here is each domain with its weight, what it covers, and how to approach it.

Domain	Weight
Application Design and Build	20%
Application Deployment	20%
Application Observability and Maintenance	15%
Application Environment, Configuration, and Security	25%
Services and Networking	20%

The weights are not evenly distributed. Application Environment, Configuration, and Security is the heaviest at 25%. Services and Networking and Application Design and Build tie at 20% each. These three domains make up 65% of the exam, so they should get the bulk of your study time.

Domain 1: Application Design and Build (20%)

This domain tests whether you can create and configure the building blocks of Kubernetes applications.

What gets tested

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

Tips for this domain

Know your workload types cold. The exam will ask you to create specific workload resources. You need to know when to use a Deployment vs. a Job vs. a CronJob vs. a DaemonSet without hesitating.

Workload	Use When
Deployment	Long-running stateless applications
StatefulSet	Applications that need stable network identity or persistent storage
DaemonSet	One Pod per node (logging agents, monitoring agents)
Job	Run-once tasks that should complete
CronJob	Scheduled tasks (backups, reports)

Imperative commands save massive time here. Memorize these:

# Create a Job
kubectl create job my-job --image=busybox -- echo "hello"

# Create a CronJob
kubectl create cronjob my-cron --image=busybox --schedule="*/5 * * * *" -- echo "hello"

# Create a Deployment
kubectl create deployment web --image=nginx --replicas=3

Multi-container Pods come up regularly. The three patterns to know are:

1. Sidecar: A helper container that runs alongside the main container (log shippers, proxies)
2. Init container: Runs before the main container starts (database migrations, config setup)
3. Ambassador/Adapter: Less common on the exam, but know the concept

Init containers are the most frequently tested. You add them to the Pod spec under initContainers:

spec:
  initContainers:
    - name: init-config
      image: busybox
      command: ['sh', '-c', 'echo "initialized" > /work-dir/ready']
      volumeMounts:
        - name: shared
          mountPath: /work-dir
  containers:
    - name: main
      image: nginx
      volumeMounts:
        - name: shared
          mountPath: /usr/share/nginx/html
  volumes:
    - name: shared
      emptyDir: {}

Volume knowledge overlaps with the CKA, but the CKAD focuses on the application side. Know how to mount a PVC in a Pod, use emptyDir for shared storage between containers, and reference ConfigMaps/Secrets as volumes.

Domain 2: Application Deployment (20%)

This domain covers the deployment lifecycle: rolling updates, rollbacks, scaling, and deployment strategies.

What gets tested

• Use Kubernetes primitives for deploying applications (Deployments and rolling updates)
• Understand Deployment strategies
• Use Helm package manager to deploy applications

Tips for this domain

Rolling updates and rollbacks are nearly guaranteed to appear on the exam. The imperative commands are fast:

# Trigger a rolling update by changing the image
kubectl set image deployment/web nginx=nginx:1.26

# Check rollout status
kubectl rollout status deployment/web

# View rollout history
kubectl rollout history deployment/web

# Rollback to the previous revision
kubectl rollout undo deployment/web

# Rollback to a specific revision
kubectl rollout undo deployment/web --to-revision=2

Know the two deployment strategies:

• RollingUpdate (default): Gradually replaces old Pods with new ones. You can control the rate with maxSurge and maxUnavailable.
• Recreate: Kills all old Pods before creating new ones. Use when the application cannot have two versions running simultaneously.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

Setting maxUnavailable: 0 means zero downtime during updates. Setting maxSurge: 1 means only one extra Pod is created at a time. Know what these fields do because the exam might ask you to configure a specific strategy.

Helm basics are in the CKAD curriculum. You should know how to:

# Search for a chart
helm search repo nginx

# Install a chart
helm install my-release bitnami/nginx

# List releases
helm list

# Upgrade a release
helm upgrade my-release bitnami/nginx --set replicaCount=3

# Rollback a release
helm rollback my-release 1

# Uninstall a release
helm uninstall my-release

The Helm questions on the CKAD tend to be straightforward. Install a chart, upgrade with specific values, or check the status of a release. Deep Helm template customization is unlikely.

Domain 3: Application Observability and Maintenance (15%)

This domain covers monitoring, logging, and debugging applications.

What gets tested

• Understand API deprecations
• Implement probes and health checks
• Use provided tools to monitor Kubernetes applications
• Use built-in CLI tools to monitor Kubernetes applications
• Opt-in to and use container resource metrics

Tips for this domain

Probes are the highest-value topic in this domain. Know the three types:

Probe	Purpose	Failure Action
livenessProbe	Is the container alive?	Restart the container
readinessProbe	Is the container ready for traffic?	Remove from Service endpoints
startupProbe	Has the container started?	Block other probes until success

Each probe supports three mechanisms:

# HTTP probe
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

# TCP probe
readinessProbe:
  tcpSocket:
    port: 3306
  initialDelaySeconds: 5
  periodSeconds: 10

# Exec probe
livenessProbe:
  exec:
    command:
      - cat
      - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

The exam will give you specific requirements: "Add a liveness probe that checks HTTP path /health on port 8080 with an initial delay of 15 seconds." You need to translate that into YAML accurately.

Debugging commands you need to be fast with:

# Check Pod status and events
kubectl describe pod <name>

# View container logs
kubectl logs <pod>
kubectl logs <pod> -c <container>  # specific container in multi-container Pod
kubectl logs <pod> --previous       # logs from crashed container

# Get resource usage
kubectl top pods
kubectl top nodes

# Execute into a running container
kubectl exec -it <pod> -- /bin/sh

API deprecations are a conceptual topic. Know that Kubernetes removes deprecated API versions after a deprecation period. If a question mentions a deprecated API version, check what the current version is using kubectl api-resources or the docs.

Domain 4: Application Environment, Configuration, and Security (25%)

This is the heaviest domain at 25%. It covers how applications get configured and secured on Kubernetes.

What gets tested

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

Tips for this domain

ConfigMaps and Secrets appear on almost every CKAD exam. Know both the imperative creation and the YAML mounting.

# Create ConfigMap from literals
kubectl create configmap app-config \
  --from-literal=DATABASE_HOST=postgres \
  --from-literal=DATABASE_PORT=5432

# Create ConfigMap from file
kubectl create configmap app-config --from-file=config.properties

# Create Secret from literals
kubectl create secret generic db-creds \
  --from-literal=username=admin \
  --from-literal=password=s3cret

Mount as environment variables:

env:
  - name: DATABASE_HOST
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: DATABASE_HOST
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-creds
        key: password

Mount as a volume:

volumes:
  - name: config
    configMap:
      name: app-config
volumeMounts:
  - name: config
    mountPath: /etc/config

Resource requests and limits control scheduling and enforcement. Requests determine where a Pod gets placed. Limits set the ceiling.

resources:
  requests:
    memory: "128Mi"
    cpu: "250m"
  limits:
    memory: "256Mi"
    cpu: "500m"

Know the difference: a Pod will not be scheduled if the node does not have enough resources to satisfy the request. A Pod will be killed (OOMKilled) if it exceeds its memory limit.

ResourceQuotas and LimitRanges restrict what can run in a namespace:

# Create a ResourceQuota
kubectl create quota my-quota --hard=cpu=2,memory=4Gi,pods=10 -n my-namespace

SecurityContext settings appear regularly. Know how to run a container as a specific user, prevent privilege escalation, and drop capabilities:

securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL
    add:
      - NET_BIND_SERVICE

ServiceAccounts tie into RBAC. The CKAD might ask you to create a ServiceAccount and assign it to a Pod:

kubectl create serviceaccount my-sa

spec:
  serviceAccountName: my-sa
  containers:
    - name: app
      image: my-app

This domain has the most variety in question types. Allocate extra study time here.

Domain 5: Services and Networking (20%)

This domain covers how applications communicate inside and outside the cluster.

What gets tested

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

Tips for this domain

Services come in three flavors on the exam:

Type	What It Does
ClusterIP	Internal-only access (default)
NodePort	Exposes on a port on every node (30000 to 32767)
LoadBalancer	Provisions an external load balancer

Create them imperatively:

# ClusterIP
kubectl expose deployment web --port=80 --target-port=8080

# NodePort
kubectl expose deployment web --port=80 --target-port=8080 --type=NodePort

# Specific NodePort
kubectl expose deployment web --port=80 --target-port=8080 --type=NodePort --overrides='{"spec":{"ports":[{"port":80,"targetPort":8080,"nodePort":30080}]}}'

The --overrides flag is ugly but it works when you need a specific NodePort value.

NetworkPolicies restrict traffic between Pods. The CKAD tests basic network policy creation. Key rules:

• By default, all Pods can talk to all other Pods
• Once you apply any NetworkPolicy that selects a Pod, all traffic not explicitly allowed by a policy is denied
• You can restrict both ingress (incoming) and egress (outgoing) traffic

A common exam pattern: "Create a NetworkPolicy that allows Pods with label app: web to receive traffic only from Pods with label app: api on port 80."

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-web
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api
      ports:
        - protocol: TCP
          port: 80

Ingress resources route external HTTP traffic to Services. The CKAD may ask you to create an Ingress with path-based or host-based routing:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-svc
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-svc
                port:
                  number: 80

Know the pathType field. Prefix matches the URL path prefix. Exact matches the exact path. The exam will specify which one to use.

CKAD Time Management Strategy

Two hours, 15 to 20 tasks. The CKAD tasks tend to be slightly faster to complete than CKA tasks because they focus on application-level operations rather than cluster-level troubleshooting. But time is still tight.

Recommended approach:

1. Minutes 0 to 5: Set up your environment (alias, autocompletion, vim settings)
2. Minutes 5 to 80: First pass through all questions. Solve everything you can quickly. Flag anything that takes more than 7 minutes.
3. Minutes 80 to 110: Second pass on flagged questions, starting with the highest-weighted ones.
4. Minutes 110 to 120: Final verification. Check that Pods are Running, Services have endpoints, and you are on the correct cluster context.

The setup:

alias k=kubectl
source <(kubectl completion bash)
complete -F __start_kubectl k
export EDITOR=vim

# Vim settings for YAML
cat <<EOF >> ~/.vimrc
set tabstop=2
set shiftwidth=2
set expandtab
EOF

Speed tips specific to the CKAD:

• Use kubectl run and kubectl create with --dry-run=client -o yaml to generate starter YAML, then edit it
• Use kubectl explain to check field names instead of switching to the docs tab
• For ConfigMaps, Secrets, and ServiceAccounts, the imperative commands are always faster than YAML
• Copy and paste from the docs when YAML structures are complex (Ingress, NetworkPolicy, probes)

CKAD vs CKA: Overlap and Differences

About 40% of the content overlaps between the CKA and CKAD. If you have already passed one, studying for the other is significantly easier.

Shared topics:

• Pods, Deployments, Services
• ConfigMaps and Secrets
• Persistent Volumes and PVCs
• NetworkPolicies
• Labels, selectors, annotations

CKA only:

• kubeadm cluster installation and upgrades
• etcd backup and restore
• Node troubleshooting (kubelet, static pods)
• RBAC (deeper coverage)
• Cluster-level operations

CKAD only:

• Helm
• CronJobs and Jobs (deeper coverage)
• Multi-container Pod patterns (init, sidecar)
• Probes and health checks (deeper coverage)
• Deployment strategies (rolling update config)
• Custom Resource Definitions

If you are wondering which to take first, read our CKA vs CKAD comparison. The short answer: CKA if you manage infrastructure, CKAD if you deploy applications.

For the full picture of all Kubernetes certifications, see Kubernetes Certification Path: The Right Order. If you have strong Linux skills already, you can go straight to the CKAD. If not, start with the LFCS or LFCA first.

FAQ

How hard is the CKAD exam?

The CKAD is a challenging hands-on exam, but most people who prepare properly pass on the first or second attempt. The difficulty comes from time pressure, not from the individual tasks. If you can create Deployments, configure probes, set up Services, and write NetworkPolicies without constantly checking the docs, you are in good shape. Budget 6 to 8 weeks of study if you already have basic Kubernetes experience.

How many questions are on the CKAD?

The CKAD has 15 to 20 performance-based tasks. Each task has a different point weight. Some are worth 2 to 3% while others are worth 8% or more. The exact number and weights vary between exam sessions.

What is the CKAD passing score?

You need 66% to pass. With variable task weights, this means you can miss several lower-weighted tasks and still pass. Focus your time on high-weight questions.

Is Helm on the CKAD exam?

Yes. Helm basics are part of the Application Deployment domain (20%). Expect questions about installing charts, upgrading releases, and checking release status. You will not need to write Helm templates from scratch.

Can I take the CKAD without the CKA?

Yes. There are no prerequisites for the CKAD. You can take it without the CKA. However, if you also plan to take the CKA, consider buying the CKA + CKAD bundle for a discount.

How long should I study for the CKAD?

With existing Kubernetes experience: 4 to 6 weeks. Without Kubernetes experience but with Linux skills: 8 to 10 weeks. Brand new to both: start with Linux fundamentals first, then plan 8 to 10 weeks for the CKAD.

What is the difference between CKAD and CKS?

The CKAD focuses on application development and deployment. The CKS focuses on Kubernetes security. The CKS requires a valid CKA (not CKAD) as a prerequisite. If your goal is security specialization, the path is CKA first, then CKS. See CKA vs CKAD vs CKS for the full comparison.

Does the CKAD include cluster administration tasks?

No. The CKAD does not test kubeadm, etcd, node management, or cluster-level troubleshooting. Those are CKA topics. The CKAD stays focused on what a developer does: build, deploy, configure, expose, and debug applications.