CKAD Study Guide: How to Pass the Certified Kubernetes Application Developer Exam

The CKAD is a 2-hour, hands-on exam where you build, deploy, and troubleshoot applications on Kubernetes in a live terminal. You need a 66% to pass. The biggest mistake people make is studying like it is a knowledge test. It is not. It is a speed test. You already know most of the concepts if you have worked with containers. The question is whether you can translate that knowledge into kubectl commands fast enough to finish 15 to 20 tasks in 120 minutes.

This CKAD study guide focuses on exactly that: what the exam tests, how to move fast, and where people lose time.

How the CKAD Differs from the CKA

If you have already read our CKA study guide or passed the CKA, here is the short version of what changes.

The CKA is about cluster operations. Installing clusters with kubeadm, upgrading versions, backing up etcd, fixing broken control plane components. The CKAD skips all of that. It assumes somebody else set up the cluster and you are the developer deploying applications to it.

The CKAD goes deeper on:

• Multi-container Pod patterns (sidecars, init containers)
• Health probes (liveness, readiness, startup)
• Helm operations
• Custom Resource Definitions
• API deprecations
• Application deployment strategies

There is roughly 40% overlap between the two exams: Pods, Deployments, Services, ConfigMaps, Secrets, PVs/PVCs, NetworkPolicies, and resource management all appear on both. If you have passed the CKA, you can prepare for the CKAD in 2 to 3 weeks. See our full CKA vs CKAD comparison for the detailed breakdown.

If the CKAD is your first Kubernetes certification, plan for 4 to 8 weeks of study depending on your experience.

CKAD Exam Domains and Weights

Five domains. The weights tell you exactly where to allocate your study hours.

Domain	Weight	What It Covers
Application Environment, Configuration & Security	25%	ConfigMaps, Secrets, ServiceAccounts, SecurityContexts, ResourceRequirements, admission controllers
Application Design and Build	20%	Multi-container Pods, init containers, volumes, CRDs, Jobs, CronJobs
Application Deployment	20%	Deployments, rolling updates, rollbacks, Helm, deployment strategies, API deprecations
Services & Networking	20%	Services, Ingress, NetworkPolicies
Application Observability and Maintenance	15%	Probes, logging, debugging, monitoring, API deprecation awareness

No single domain dominates the way troubleshooting dominates the CKA (30%). The CKAD spreads the weight more evenly, which means you cannot afford to skip any domain.

The Study Plan

Weeks 1 to 2: Pods, Deployments, and Imperative Speed

This is your foundation. Every CKAD task involves creating or modifying Kubernetes resources. The faster you can do that, the more tasks you finish.

What to master:

Creating Pods, Deployments, and Services imperatively. This is the single most important skill on the exam.

# Create a pod
kubectl run nginx --image=nginx --port=80

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

# Expose a deployment
kubectl expose deployment web --port=80 --target-port=80 --type=ClusterIP

# Generate YAML without creating the resource
kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml

# 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 "tick"

The --dry-run=client -o yaml pattern is your best friend. Generate a template, pipe it to a file, edit the file, apply it. This is faster than writing YAML from scratch for every task.

Labels and selectors:

# Add a label
kubectl label pod nginx app=web

# Show labels
kubectl get pods --show-labels

# Filter by label
kubectl get pods -l app=web

# Remove a label
kubectl label pod nginx app-

You will use labels constantly on the exam. Services find Pods through label selectors. If the label does not match, the Service has no endpoints and your app is unreachable. This is one of the most common debugging scenarios.

Scaling and updating:

# Scale a deployment
kubectl scale deployment web --replicas=5

# Update the image
kubectl set image deployment/web nginx=nginx:1.25

# Check rollout status
kubectl rollout status deployment/web

# Rollback
kubectl rollout undo deployment/web

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

Practice until these commands are automatic. You should not have to think about syntax.

Weeks 2 to 3: Configuration and Security

This is the heaviest domain at 25%. It is also where people lose the most time on exam day because the YAML for some of these resources has deep nesting.

ConfigMaps and Secrets:

Three ways to use them, and the exam will test all three.

# Create a ConfigMap from literal values
kubectl create configmap app-config --from-literal=APP_ENV=production --from-literal=LOG_LEVEL=info

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

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

Mounting as environment variables:

spec:
  containers:
    - name: app
      image: myapp
      envFrom:
        - configMapRef:
            name: app-config
      env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-creds
              key: password

Mounting as volumes:

spec:
  containers:
    - name: app
      image: myapp
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: app-config

Know the difference between envFrom (loads all keys), env with valueFrom (loads a single key), and volume mounts (writes files). The exam will specify which approach to use.

SecurityContexts:

spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
    - name: app
      image: myapp
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL

Pod-level security context applies to all containers. Container-level overrides the Pod-level for that specific container. The exam might ask you to set both.

ServiceAccounts:

# Create a service account
kubectl create serviceaccount my-sa

# Assign to a pod (in the pod spec)
spec:
  serviceAccountName: my-sa

Know how to create a ServiceAccount, assign it to a Pod, and optionally disable automatic token mounting with automountServiceAccountToken: false.

Resource Requests and Limits:

spec:
  containers:
    - name: app
      image: myapp
      resources:
        requests:
          memory: "128Mi"
          cpu: "250m"
        limits:
          memory: "256Mi"
          cpu: "500m"

Requests are what the scheduler uses to place the Pod. Limits are the ceiling the container cannot exceed. A container that exceeds its memory limit gets OOMKilled. A container that exceeds its CPU limit gets throttled.

Weeks 3 to 4: Application Design and Multi-Container Patterns

This domain is where the CKAD goes deeper than the CKA. Multi-container patterns are a CKAD staple.

Init Containers:

Init containers run before the main containers start. They must complete successfully before the app container begins. Use cases: waiting for a database to become available, populating a shared volume, running setup scripts.

spec:
  initContainers:
    - name: init-db
      image: busybox
      command: ['sh', '-c', 'until nslookup mysql; do echo waiting; sleep 2; done']
  containers:
    - name: app
      image: myapp

Sidecar Containers:

Sidecar containers run alongside the main container for the entire Pod lifecycle. Common use cases: log shipping, proxying, metrics collection.

spec:
  containers:
    - name: app
      image: myapp
      volumeMounts:
        - name: logs
          mountPath: /var/log/app
    - name: log-shipper
      image: fluentd
      volumeMounts:
        - name: logs
          mountPath: /var/log/app
  volumes:
    - name: logs
      emptyDir: {}

The key pattern: shared volumes via emptyDir. The app container writes logs to a shared volume. The sidecar reads from the same volume and ships them somewhere.

Jobs and CronJobs:

apiVersion: batch/v1
kind: Job
metadata:
  name: process-data
spec:
  completions: 5
  parallelism: 2
  backoffLimit: 3
  template:
    spec:
      containers:
        - name: worker
          image: my-worker
      restartPolicy: Never

Know these fields:

• completions: how many Pods need to finish successfully
• parallelism: how many Pods run at the same time
• backoffLimit: how many times to retry before marking the Job as failed
• restartPolicy: must be Never or OnFailure for Jobs (never Always)

CronJob scheduling uses standard cron syntax. */5 * * * * means every 5 minutes. The exam might give you a specific schedule to configure.

Custom Resource Definitions:

The exam might ask you to view or interact with CRDs. You will not need to create one from scratch, but you should know how to:

# List custom resources
kubectl get crd

# Get instances of a custom resource
kubectl get <custom-resource-name>

# Describe a custom resource
kubectl describe <custom-resource-name> <instance-name>

Weeks 4 to 5: Services, Networking, and Ingress

Twenty percent of the exam. If you have studied for the CKA, this will feel familiar.

Services:

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

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

# Create a service with a specific name
kubectl create service clusterip my-svc --tcp=80:8080

When a Service has no endpoints, it means the selector does not match any Pod labels. That is the first thing to check when troubleshooting.

# Check endpoints
kubectl get endpoints my-svc

Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend-service
                port:
                  number: 80

Know the three pathType values: Exact, Prefix, and ImplementationSpecific. Most exam questions use Prefix.

NetworkPolicies:

Same as the CKA. Once a NetworkPolicy selects a Pod, all traffic not explicitly allowed is denied. Practice writing both ingress and egress rules.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              env: production
      ports:
        - protocol: TCP
          port: 443
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: database
      ports:
        - protocol: TCP
          port: 5432

Weeks 5 to 6: Observability, Probes, and Helm

Liveness, Readiness, and Startup Probes:

This is CKAD-specific territory. The CKA barely touches probes. The CKAD expects you to configure all three types.

spec:
  containers:
    - name: app
      image: myapp
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 10
        periodSeconds: 5
        failureThreshold: 3
      readinessProbe:
        httpGet:
          path: /ready
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 3
      startupProbe:
        httpGet:
          path: /healthz
          port: 8080
        failureThreshold: 30
        periodSeconds: 10

What each probe does:

• Liveness: Is the container alive? If it fails, kubelet restarts the container.
• Readiness: Is the container ready to receive traffic? If it fails, the Pod is removed from Service endpoints.
• Startup: Has the app started yet? While running, liveness and readiness probes are disabled. Use this for slow-starting apps.

Three probe types: httpGet, tcpSocket, exec. The exam will specify which one to use.

Know the timing fields:

• initialDelaySeconds: wait before first check
• periodSeconds: how often to check
• failureThreshold: how many failures before acting
• successThreshold: how many successes before marking healthy (only relevant for readiness)

Debugging applications:

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

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

# Execute a command in a running container
kubectl exec -it <pod-name> -- /bin/sh

# Check resource usage
kubectl top pods
kubectl top nodes

The --previous flag is critical for debugging CrashLoopBackOff. The current container has already crashed and the logs are gone. The previous container's logs show you what went wrong.

Helm:

Helm is on the CKAD but not the CKA. You need to know the basic operations:

# Search for charts
helm search repo nginx
helm search hub nginx

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

# Install with custom values
helm install my-release bitnami/nginx --set replicaCount=3
helm install my-release bitnami/nginx -f values.yaml

# List releases
helm list

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

# Rollback
helm rollback my-release 1

# Uninstall
helm uninstall my-release

You will not need to create Helm charts from scratch. The exam tests whether you can install, configure, upgrade, and rollback releases.

Exam Day Tips

The most important tip: speed over perfection

The CKAD is a race. Every minute you save on one question is a minute you can spend on a harder one. This is why imperative commands matter so much. Writing YAML from memory takes 3 to 5 minutes per resource. Running kubectl create with --dry-run=client -o yaml takes 30 seconds.

Set up your environment immediately

At the start of the exam:

# Verify alias exists (usually pre-configured)
alias k=kubectl

# Enable completion
source <(kubectl completion bash)
complete -F __start_kubectl k

# Set vim defaults
cat >> ~/.vimrc << 'EOF'
set tabstop=2
set shiftwidth=2
set expandtab
set number
EOF

export EDITOR=vim

Know the kubectl shortcuts

# Shorthand resource types
k get po          # pods
k get deploy      # deployments
k get svc         # services
k get ns          # namespaces
k get no          # nodes
k get cm          # configmaps
k get sa          # serviceaccounts
k get ing         # ingress
k get netpol      # networkpolicies
k get pv          # persistentvolumes
k get pvc         # persistentvolumeclaims
k get cj          # cronjobs

Use output formatting

# Wide output for more columns
k get pods -o wide

# Get a specific field
k get pod nginx -o jsonpath='{.status.podIP}'

# Custom columns
k get pods -o custom-columns=NAME:.metadata.name,STATUS:.status.phase

# Sort by a field
k get pods --sort-by=.metadata.creationTimestamp

Handle the question weight

The exam shows point values for each question. Questions range from about 2% to 8%. Do the high-value questions first if you are running low on time. Flag anything that takes more than 7 minutes and come back later.

Always switch context

Every question specifies which cluster to use. Run the context switch command before doing anything else. On the CKAD this matters less than the CKA (fewer clusters typically), but building the habit prevents mistakes.

Common Mistakes on the CKAD

Forgetting the restartPolicy for Jobs. Jobs need restartPolicy: Never or restartPolicy: OnFailure. The default Always is invalid for Jobs. If your Job keeps failing to create, check this first.

Mixing up envFrom and env with valueFrom. envFrom loads all keys from a ConfigMap or Secret. env with valueFrom loads a single key. The exam question will specify which approach. Read carefully.

Wrong probe types. An httpGet probe needs path and port. A tcpSocket probe needs port. An exec probe needs command. Mixing up the fields wastes time on debugging YAML errors.

Not using the right namespace. Many CKAD questions specify a namespace. If you create the resource in the default namespace instead, you get zero points. Add -n <namespace> to every command, or set the namespace context:

kubectl config set-context --current --namespace=my-namespace

Editing the wrong container in a multi-container Pod. Read the question carefully. It might ask you to add an init container, a sidecar, or modify a specific container. Adding the config to the wrong container is an easy mistake when you are moving fast.

Spending too long on Helm questions. Helm commands are straightforward. If you know helm install, helm upgrade, and helm rollback, you can answer Helm questions in 2 to 3 minutes. Do not overcomplicate them.

Best CKAD Study Resources

Courses

The Linux Foundation's official CKAD training (LFD259) covers the full curriculum. Thorough and focused on the CKAD exam domains.

Choose a structured training course with integrated hands-on labs so you can practice in a real cluster environment as you learn.

Practice

Practice sessions come free with your exam purchase (two sessions, 36 hours each). The questions are harder than the real exam on purpose. If you can handle the practice sessions, exam day feels easier. Use one session a week before your exam and the second session 2 to 3 days before.

CKAD exercises on GitHub (dgkanatsios/CKAD-exercises) is a free, community-maintained repository of practice questions organized by exam domain. Excellent supplement to a course.

Your own cluster with kind or minikube is the best practice environment. Create resources, break them, fix them. Repetition builds speed.

Documentation

Bookmark these for exam day:

• kubectl Cheat Sheet
• kubectl Reference Docs
• Helm Documentation

Practice navigating the Kubernetes docs quickly. You will reference them for YAML field names and less common resource specs. But if you are looking up basic Pod or Deployment syntax during the exam, you need more practice.

Study Timeline

Background	Study Time
Already passed the CKA	2 to 3 weeks
Working with Kubernetes daily	3 to 4 weeks
Familiar with containers, some K8s experience	4 to 6 weeks
Strong Linux skills, new to Kubernetes	6 to 8 weeks
New to both Linux and Kubernetes	Start with LFCS first, then 6 to 8 weeks for CKAD

These assume 1 to 2 hours of study per day. The ratio should be about 30% reading/watching and 70% hands-on practice. If you flip that ratio, you will know the concepts but not be fast enough on exam day.

What Comes After the CKAD

CKA if you have not taken it yet. The 40% overlap works in both directions. Going from CKAD to CKA takes 4 to 6 weeks because you need to learn cluster administration, etcd, kubeadm, and advanced troubleshooting. Still faster than starting from zero.

CKS if security interests you (requires CKA, so take that first if you only have the CKAD).

Kubestronaut if you want all five. The recommended order starting from the CKAD: take CKA next, then CKS, then KCNA and KCSA. See the Kubestronaut path guide for timing and strategy.

For the career ROI of stacking certifications, read Is Kubernetes Certification Worth It?

FAQ

How hard is the CKAD exam?

The CKAD is moderately hard. It is easier than the CKA because the scope is narrower and does not include cluster administration or heavy troubleshooting. The difficulty comes from the time pressure. Fifteen to twenty tasks in two hours means about 6 to 8 minutes per task. If you are slow with kubectl or spend too long writing YAML, you will not finish.

Can I take the CKAD without the CKA?

Yes. The CKAD has no prerequisites. You can take it as your first and only Kubernetes certification. The only Kubernetes cert with a prerequisite is the CKS, which requires a valid CKA.

How many questions are on the CKAD?

The CKAD has 15 to 20 performance-based tasks. Each task has a point value. The values are not equal, so check the weight before deciding how much time to spend on each question. Prioritize the high-value tasks.

Is the CKAD open book?

Yes, with restrictions. You can access kubernetes.io/docs, the Kubernetes blog, and helm.sh/docs during the exam. No other websites. No personal notes. No Stack Overflow.

What is the pass rate for the CKAD?

The exact pass rate is not publicly disclosed, but it is estimated at 50 to 65% based on community reports. It is passable with proper preparation. The people who fail are usually the ones who studied concepts but did not practice enough in a terminal.

How long is the CKAD valid?

Two years from the date you pass. After that, you need to take the current version of the exam to recertify.

CKAD or CKA first?

For most people, CKA first is more efficient because of the broader scope and 40% overlap. But if you are purely a developer who deploys to Kubernetes and never touches cluster infrastructure, the CKAD is the more relevant starting point. Read our full CKA vs CKAD comparison for the detailed breakdown.

Do I need Helm experience for the CKAD?

You need basic Helm skills: install, upgrade, rollback, list, and uninstall. You do not need to create Helm charts from scratch. If you have never used Helm, spend an afternoon going through the official Helm quickstart guide. That is enough for the exam.