The CKAD is the developer’s Kubernetes exam, and like its administrator sibling it is entirely performance-based: you build, configure, deploy and debug real workloads in a live cluster from the command line, and you are scored on whether they actually work. There are no multiple-choice questions to recognise your way through. Where the CKA focuses on operating and repairing clusters, the CKAD focuses on the application side, the part a developer owns: turning a container image into a correctly configured, observable, deployable workload. The two things that decide your result are fluency with the core Kubernetes objects and speed with kubectl under a tight clock, because the exam is famously time-pressured. This guide is a full self-study course built around that reality: it works through all five curriculum domains in depth, explains the developer concepts behind each, and turns them into a hands-on plan that trains speed as deliberately as correctness. It is original teaching material and study guidance only. It contains no real or simulated exam tasks, and you should always confirm the current curriculum and exam environment version on the CNCF CKAD page before you book.
Chapter 1: How the exam works and how to use this guide
The format and why it is hard
The CKAD gives you roughly two hours to solve a set of performance-based tasks from a command line in a live cluster, and you need 66% to pass. You may use the official Kubernetes documentation at kubernetes.io during the exam, but the real constraint is time, not access to information. People who fall short on the CKAD usually understand Kubernetes perfectly well; they run out of time because they wrote YAML by hand, hunted through the docs for syntax they should have known, or made small errors that broke a task under pressure. Accept this framing from the outset, because it determines that the right way to study is to do tasks fast and correctly in a real cluster, not to read about them.
The five domains and their weights
The curriculum has five domains with published weights, and those weights tell you exactly where your hours belong. They are Application Environment, Configuration and Security at 25%, Application Design and Build at 20%, Application Deployment at 20%, Services and Networking at 20%, and Application Observability and Maintenance at 15%. The configuration and security domain is the single heaviest, and the three middle domains are tied at 20% each, so the weight is spread fairly evenly across the application lifecycle rather than concentrated in one place. That even spread means you cannot afford a blind spot: every domain carries real marks. The exam environment tracks recent Kubernetes releases, so confirm the current version in the CNCF FAQ and practise on a matching version.
How to use this course
Read the domain chapters in the lifecycle order used here: design and build an application, configure and secure it, deploy it, expose it over the network, and observe and maintain it. This order mirrors how a developer actually ships a workload, which makes the concepts stick and mirrors how exam tasks chain together. Every concept should become something you have created, configured and debugged in a real cluster, because the exam scores working results. Throughout, the guide flags the imperative kubectl patterns that turn correct-but-slow into correct-and-fast, since on this exam those are genuinely different outcomes. Short illustrations make ideas concrete; none are exam tasks.
Chapter 2: Application Design and Build (20%)
This domain is where the application starts: defining the smallest deployable unit, combining containers when a workload needs it, running batch work, and giving pods the storage they need. It is foundational because every later domain builds on the pods you define here.
Pods and the container image
The pod is the smallest deployable unit in Kubernetes, wrapping one or more containers that share a network and can share storage. You start from a container image (built with a tool such as Docker or another OCI-compliant builder and pushed to a registry), and a pod definition tells Kubernetes which image to run and how. You should be able to define a pod, set its container’s command and arguments, pass it environment variables, and understand that the image and its tag pin exactly what runs. Although you mostly deploy through higher-level objects, the pod is the unit you debug and reason about, so its structure must be second nature.
Multi-container pods and their patterns
Sometimes a single pod needs more than one container, and the exam expects you to recognise the standard patterns. A sidecar adds a helper alongside the main container (for example, a container that ships logs or syncs content), a init container runs to completion before the main containers start (for setup or waiting on a dependency), and the ambassador and adapter patterns proxy or reshape communication. The key idea is that containers in the same pod share the network and can share volumes, which is exactly why these patterns work. As a teaching example to make the init-container pattern concrete: if your application must not start until a configuration file exists, an init container can fetch that file into a shared volume and exit, after which the main container starts and finds it ready, which is cleaner than building the wait into the application.
Jobs, CronJobs and volumes
Not all work is a long-running service. A Job runs a pod to completion for a batch task and tracks success, and a CronJob runs a Job on a schedule, like a recurring backup or report. You should be able to create both and understand completions and restart behaviour. For storage at the application level, know the basic volume types a developer reaches for, especially emptyDir (scratch space that lives as long as the pod) and mounting a ConfigMap or Secret as a volume, with persistent storage covered more fully in the configuration domain. Practise creating a Job and a CronJob and mounting an emptyDir shared between two containers in a pod, because these are concrete, scorable tasks.
Chapter 3: Application Environment, Configuration and Security (25%)
This is the heaviest domain, and it covers everything about how a workload is configured and secured: externalising configuration, handling secrets, setting the security context a container runs under, controlling its resources, and giving it an identity. Give it the most attention, because it carries the most marks and threads through every application you deploy.
ConfigMaps, Secrets and the twelve-factor instinct
Good application design keeps configuration out of the image so the same image runs anywhere, and Kubernetes provides two objects for this. A ConfigMap stores non-sensitive configuration as key-value pairs, and a Secret stores sensitive data such as passwords, tokens and keys. You must be fluent at injecting both into a pod as environment variables and as mounted files, and at understanding the trade-off: environment variables are simple but fixed at container start, while files mounted from a ConfigMap can reflect updates in the running pod. As a teaching example of a precise distinction the exam can test: a database password belongs in a Secret rather than a ConfigMap, and whether you expose it as an environment variable or a mounted file changes both security posture and whether it updates live, so read each task for which delivery it demands.
SecurityContext and running safely
A SecurityContext sets the security parameters a pod or container runs under, and it is a recurring task. You should be able to make a container run as a specific non-root user ID, drop or add Linux capabilities, and set a read-only root filesystem, and you should understand why these matter: running as non-root and dropping unnecessary capabilities limit the damage if a container is compromised. The distinction between a pod-level SecurityContext (applying defaults to all containers) and a container-level one (overriding for a specific container) is the kind of detail tasks hinge on, so practise both.
Resources, ServiceAccounts and custom resources
You should set resource requests and limits on containers, where a request is what the scheduler guarantees and a limit is the ceiling the container cannot exceed, because these affect both scheduling and whether a container is throttled or killed. A ServiceAccount gives a pod an identity for talking to the Kubernetes API, distinct from the human users in RBAC, and you should be able to create one and attach it to a pod. Finally, understand custom resources at the level of recognising that Kubernetes can be extended with new resource types (defined by CustomResourceDefinitions) that you interact with through kubectl just like built-in objects. Practise setting requests and limits and binding a ServiceAccount to a pod, since both are concrete and frequently tested.
Chapter 4: Application Deployment (20%)
This domain covers getting your application running and updating it safely over time, plus the tooling that packages and customises manifests. The theme is controlled, repeatable change rather than ad-hoc edits.
Deployments and update strategies
A Deployment manages a set of identical pods and provides safe, declarative updates through a ReplicaSet. The default rolling update gradually replaces old pods with new ones so the application stays available, and you can pause, resume, check status with kubectl rollout status, and crucially roll back with kubectl rollout undo if a release goes wrong. Beyond the default, the exam expects awareness of deployment strategies: a blue/green deployment runs the new version alongside the old and switches traffic over at once, while a canary release sends a small slice of traffic to the new version first to test it before a full rollout. You should be able to create and scale a Deployment, update its image and watch the rollout, and roll it back, and to reason about when a canary or blue/green approach reduces risk.
Helm and Kustomize
Two tools for managing manifests are in scope at a basic level. Helm packages applications as reusable, parameterised charts that you can install and upgrade, which is how many teams distribute and deploy software on Kubernetes. Kustomize (built into kubectl) customises plain manifests for different environments through overlays, without templating, so you keep a base set of YAML and layer environment-specific changes on top. You do not need deep expertise in either, but you should know what each is for and the difference between Helm’s templated packages and Kustomize’s overlay approach. As a teaching example of the distinction: Helm is suited to packaging and sharing an application with configurable values, whereas Kustomize is suited to taking one set of manifests and adjusting them per environment, and recognising which fits a described need is what the exam wants.
Chapter 5: Services and Networking (20%)
This domain covers how your application is reached and how you control traffic to it. The concepts trip people up more than the syntax, so aim for a clear picture of how a request reaches your pod and how you secure it, the developer-facing slice of Kubernetes networking.
Services and exposing your application
Because pods are ephemeral, you expose your application through a Service, which gives a stable address and load-balances across the pods it selects by label. Know the types you will use: ClusterIP (internal-only, the default), NodePort (reachable on a port of every node), and LoadBalancer (an external load balancer where supported). The link between a Service and its pods is the label selector, and the most common failure is a selector that does not match the pods, leaving the Service with no endpoints. As a teaching example of the first thing to check: when your application is unreachable through its Service, inspecting whether the Service has endpoints tells you immediately whether the problem is the selector or something else, which saves time on a clock-bound exam.
Ingress and NetworkPolicies
Ingress exposes HTTP and HTTPS Services to the outside world through a single entry point with host- and path-based routing, fronted by an ingress controller, and you should be able to define an Ingress that routes to your Service. NetworkPolicies control which pods may communicate, acting as a pod-level firewall, and the essential concept is the default behaviour: with no policies, all traffic to a pod is allowed, but once a pod is selected by any NetworkPolicy, anything not explicitly permitted is denied. Understanding that shift from default-allow to default-deny is exactly what NetworkPolicy tasks test. Practise exposing an application through a Service and then an Ingress, and then writing a NetworkPolicy that permits only the intended traffic, confirming both the allowed and blocked paths so you understand the effect rather than just the syntax.
Chapter 6: Application Observability and Maintenance (15%)
This domain is about knowing whether your application is healthy and fixing it when it is not. It is the smallest slice at 15%, but probes in particular recur throughout the exam, and debugging skill underpins your ability to recover from your own mistakes under time.
Probes: liveness, readiness and startup
Kubernetes uses probes to manage container health, and the distinction between them is the most testable concept here. A liveness probe checks whether a container is still working and restarts it if it fails, recovering from deadlocks. A readiness probe checks whether a container is ready to receive traffic and removes it from the Service’s endpoints if it is not, without restarting it, which protects users during startup or temporary overload. A startup probe gives slow-starting containers time before the other probes apply. You should be able to add each probe to a container using the HTTP, TCP or command check types and set the timing fields sensibly. As a teaching example of why the difference matters: a readiness probe failing takes a pod out of rotation but leaves it running, whereas a liveness probe failing restarts it, so misusing one for the other either needlessly kills a recovering pod or keeps sending traffic to a broken one, which is precisely the trap the exam sets.
Logging, monitoring and debugging
You should be fluent at observing a running application: reading container logs with kubectl logs (including previous-instance logs for a crashed container with the appropriate flag), checking resource usage with kubectl top where metrics are available, and inspecting an object’s events and state with kubectl describe. Debugging is the practical payoff: when a pod will not start or behaves wrongly, you describe it to read the events, check the logs, and exec into a running container with kubectl exec to inspect it from inside. Practise this loop until it is reflexive, because in a timed exam your ability to quickly find why your own task is not working is what lets you fix it before the clock runs out.
Chapter 7: Getting fast with kubectl, the skill that decides the exam
Speed is a graded skill on the CKAD, not a nicety, because the clock is the main adversary and most failures are failures of time, not knowledge. This chapter is about the habits that make your work fast as well as correct, and they deserve as much practice as any domain.
Generate, do not type, your YAML
The single largest time saver is to stop authoring manifests by hand. kubectl generates most objects for you, and the —dry-run=client -o yaml flags scaffold a correct manifest you then edit rather than write. The workflow to internalise is: create the object imperatively to produce a baseline, redirect the YAML to a file, make the one or two changes the task requires (a probe, a SecurityContext, a resource limit), and apply it. Authoring YAML from a blank file is the habit that most often runs developers out of time, so replace it deliberately with generate-then-edit until it is automatic.
Aliases, autocompletion and the docs
At the very start of the exam, set up the efficiencies: alias kubectl to k, enable shell autocompletion, and configure your preferred editor through the environment variable if you have one. Learn a few patterns cold, kubectl explain for a resource’s structure, label selectors and the -n and —all-namespaces flags so you always operate in the right namespace, and kubectl get and describe for fast inspection. Rather than memorising every manifest, learn where in the kubernetes.io documentation the canonical examples live (probes, SecurityContext, volumes, network policies), because copying a known-good example in seconds beats recalling exact syntax under pressure. The aim is to need the docs only for details, never to learn a topic mid-exam.
Chapter 8: Study plan, mock exams and exam day
With the domains and the kubectl habits understood, the remaining work is pacing them so that the heavy configuration domain, probes, and timed practice are never squeezed out. The plan is built around living in a real cluster from day one.
Set up a real cluster first
Before studying any domain, set up a cluster you can build in and break freely. A local cluster with minikube or kind is perfectly adequate for the application-focused CKAD and costs nothing, so there is no excuse to study on paper. The non-negotiable rule is that everything in this course should be typed into a real cluster, because the exam scores working workloads, not understanding of them. Pair the cluster with the CNCF curriculum so the official objectives define your scope, and match your practice cluster to the current exam Kubernetes version.
Choose a timeline weighted by the domains
If you already develop and have some Kubernetes exposure, a three-week intensive at around fifteen hours a week works: drill all five domains hands-on, then move to timed practice. A common pace is a six-week plan at about eight hours a week, taking one domain area at a time in a real cluster, with mocks at the end. If you are newer to containers and Kubernetes, an eight-week plan at around five hours a week spends the early weeks on container and command-line fundamentals before the exam domains. Whichever you choose, give the most time to Application Environment, Configuration and Security, the heaviest domain, keep the three 20% domains genuinely solid because they tie, and treat kubectl speed as its own recurring drill. To turn a timeline into dated weeks for your own start date, use the free study-plan generator.
Mock exams: train pacing above all
In the final stretch, sit full-length, timed practice exams in the hands-on format, because pacing is what the CKAD really tests and the only cure is rehearsal. Each timed session builds the stamina the real two hours demand and surfaces the tasks you are slow on, especially anything where you reached for hand-written YAML instead of a generator. Aim to finish comfortably within time on fresh task sets before you book, and review not only your wrong answers but the tasks you completed slowly, since slowness is this exam’s signature failure mode. If you are weighing the developer track against the administrator one before committing, the CKAD vs CKA comparison covers who each is for and how they overlap.
Exam day and format
On the day, the exam is roughly two hours of performance-based tasks in a live terminal, online-proctored, and you may consult the official Kubernetes documentation. Manage the clock deliberately. Set up your alias and autocompletion in the first minute, read each task for exactly what it asks and which namespace it applies to, and confirm your context before acting, because correct work in the wrong namespace scores nothing. If a task resists you, flag it mentally and move on rather than letting it eat time other tasks need, since you only need 66% and an unattempted easy task costs more than one hard task left unfinished. Verify your work with a quick kubectl get or describe, because the exam scores whether your workload actually runs. Having built and debugged applications in a cluster for weeks and trained for speed, the format will feel like ordinary development work under a clock, which is exactly the advantage your hands-on preparation was built to give you.