CKAD: build, ship, and diagnose applications
CKAD rewards your ability to turn a requirement into a working application on Kubernetes. Learn the purpose of each object, choose the smallest change that meets the task, and prove the result from inside the cluster.
This guide follows the five published CKAD domains. The certification page currently lists a two-hour, performance-based exam using Kubernetes v1.35. Check it again before your appointment; lab time targets here are practice goals, not official task timings. Official CKAD scope and exam details ↗.
| Domain | Weight | The question you should be able to answer |
|---|---|---|
| Application Design and Build | 20% | What should run, how should it be packaged, and how long should it live? |
| Application Deployment | 20% | How do I release a change and recover from a bad one? |
| Application Observability and Maintenance | 15% | What evidence explains the application's behavior? |
| Application Environment, Configuration and Security | 25% | What configuration, resources, identity, and permissions does it need? |
| Services and Networking | 20% | How does traffic reach the right healthy workload? |
Use Concepts → Playbook → Exercises. First explain a concept in one sentence. Then practice the commands and checks. Finally solve an exercise without its solution. These are original practice tasks aligned to public objectives, not reproduced exam questions.
1. Application Design and Build — 20%
Choose a controller by the work's lifetime
| Resource | Use it for | Evidence of success |
|---|---|---|
| Pod | A directly managed group of tightly coupled containers | Required containers running and ready |
| Deployment | Replaceable application replicas and rolling releases | Desired replicas available; rollout complete |
| StatefulSet | Stable per-pod identities and associated storage | Expected identities, volumes, and readiness |
| DaemonSet | A copy on each eligible node | Desired and ready counts agree |
| Job | Work that finishes | Required successful completions |
| CronJob | Work that starts on a schedule | Correct schedule and a successful test Job |
Remember: keep serving → Deployment; finish work → Job; schedule work → CronJob. A Deployment replaces exited application containers; it is a poor choice for a batch command intended to finish. StatefulSet identity does not make an application automatically highly available. Workload management ↗.
For Jobs, completions is the success target and parallelism limits concurrent work. restartPolicy: Never prevents container restarts within a Pod; the Job can still create replacement Pods. backoffLimit limits retries and activeDeadlineSeconds limits the Job's active duration. Inspect both status and logs. Jobs ↗.
A CronJob's startingDeadlineSeconds controls late starts, while its Job template's active deadline controls execution duration. concurrencyPolicy: Forbid governs Jobs scheduled by that CronJob, not manual Jobs. suspend: true prevents future scheduling without stopping existing Jobs. Use timeZone: Etc/UTC when UTC is required. CronJobs ↗.
Build an image that can actually run
An image packages the application; a container is a running instance. In a multi-stage Dockerfile, compile in one stage and copy only runtime files into the final stage. COPY adds files, RUN executes build steps, and exec-form ENTRYPOINT starts the program directly. EXPOSE documents a port; it does not publish it. Keep credentials and unnecessary files out of the build context. Docker multi-stage builds ↗, Dockerfile reference ↗.
Build → inspect → load or push → deploy → request. A successful build does not prove the architecture, user, entrypoint, or application response is correct. KubeFit's image exercise loads into kind: the host's Docker images and each node's image store are separate. Use imagePullPolicy: Never only when the image has been loaded into those nodes. Other environments may require a registry and imagePullSecrets. Kubernetes images ↗, kind image loading ↗.
Practice: Build and deploy a container image, Jobs and CronJobs.
Containers share a Pod, not a filesystem
Containers in one Pod share networking and can communicate through localhost. They share files only through volumes mounted into each container. A regular init container completes before application containers start. A sidecar supports the application while it runs. Kubernetes also supports native sidecars: entries in initContainers with restartPolicy: Always; these do not prevent a Job from completing. The sidecar exercise explicitly asks for two regular containers. Read the task's lifecycle requirements before choosing a pattern. Init containers ↗, Native sidecars ↗.
emptyDir survives a container restart but disappears when its Pod is removed. A PVC requests persistent storage independently of a particular Pod. Mount the claim with persistentVolumeClaim.claimName and check binding, mount paths, permissions, and actual reads/writes. A volume's access mode is a storage capability, not a substitute for application coordination. Volumes ↗, Persistent volumes and claims ↗.
Practice: Share logs with a sidecar. Recall cue: same volume name, useful mount paths, correct container selected in logs.
2. Application Deployment — 20%
A rollout changes a Pod template
Changing a Deployment's image or template configuration creates a new ReplicaSet. Scaling alone does not create a rollout revision. maxSurge controls extra Pods during an update; maxUnavailable controls how many can be unavailable. Readiness probes help keep unready replicas out of normal Service traffic. maxUnavailable: 0 needs sufficient capacity and suitable probes; it cannot guarantee application-level continuity by itself. A rollback restores a previous Pod template, not external data or database changes. Deployments ↗.
Prove the release with kubectl rollout status, the actual image on Pods, ready EndpointSlices, and an application request. A command returning “configured” proves only that the API accepted a change.
Separate release identity from routing
For a simple canary, both Deployments share an application label; a second label identifies the stable or canary track. A Service selecting only the application label includes both. Four ready stable Pods and one ready canary Pod approximate a 4:1 allocation; connection reuse and random selection mean 50 requests need not split exactly 40:10.
For blue/green, keep two versions available and change the Service selector to the desired track. Existing connections may persist during the switch. Plan capacity and rollback before directing traffic. These are practice patterns built from Deployments and Services; labels themselves do not assign traffic weights. Services and selectors ↗.
Practice: Release a canary. Prove replicas + selection + both responses, not just the Deployment's existence.
Render configuration before applying it
Helm installs a chart as a named release. Inspect chart values, supply explicit overrides, then check release status and workloads. Know helm show values, template, upgrade --install, history, and rollback. Chart version and application image version are separate choices. Helm usage ↗.
Kustomize transforms a base into environment-specific resources. An overlay can change namespace, prefix, image tags, replicas, labels, and configuration without editing the base. kubectl kustomize DIR renders locally; kubectl apply -k DIR persists the result. Generated ConfigMaps normally get a content hash, and recognized references are rewritten. Check the rendered name and envFrom reference instead of guessing the suffix. Kustomize ↗.
Practice: Build a production overlay.
3. Application Observability and Maintenance — 15%
Three probes answer three different questions
| Probe | Question | Effect after its failure threshold |
|---|---|---|
| Startup | Has this container finished starting? | Container is terminated; restart follows its policy |
| Readiness | Can this container accept traffic now? | Pod becomes unready for normal Service routing |
| Liveness | Is this container stuck and needs recovery? | Container is terminated; restart follows its policy |
While startup has not succeeded, liveness and readiness checks wait. Readiness failure alone does not restart the container. Use a startup budget suitable for boot time; avoid a liveness check that restarts every replica merely because a shared dependency is temporarily unavailable. Check the action, path, port, delays, periods, and thresholds independently. Configure probes ↗.
Practice: Configure health probes.
Diagnose from evidence
Describe → events → logs → runtime test. A Pod can be Running while an application container is unready. CrashLoopBackOff describes repeated restart backoff, not the underlying cause. Inspect termination reason, exit code, and logs --previous. In multi-container Pods, choose -c NAME. Use exec when the image has the needed tool; ephemeral debugging containers can help with minimal images when permissions allow. kubectl top requires a working metrics API and reports usage rather than resource requests. Debug Pods ↗, Debug running Pods ↗, Resource metrics pipeline ↗.
Migrate the schema as well as the version
Use kubectl api-resources, api-versions, and explain against the target cluster. For old Ingress manifests, changing to networking.k8s.io/v1 also requires the current backend structure and pathType. CronJob uses batch/v1; PodDisruptionBudget uses policy/v1. Preserve selectors carefully: an empty PDB selector in v1 selects all Pods in its namespace, unlike the old beta behavior. Server-side dry-run validates the new shape before persistence. API migration guide ↗.
Practice: Migrate removed APIs. This exercise validates migration; the separate Ingress exercise verifies real HTTP routing.
4. Application Environment, Configuration and Security — 25%
Configuration belongs outside the image
Use a ConfigMap for ordinary configuration and a Secret for sensitive values. envFrom imports a source's keys; env[].valueFrom maps a specific key to a named variable. Volume projections provide files. Environment variables do not change in existing containers when their source changes. Ordinary projected ConfigMap volumes update eventually, but subPath mounts do not receive those updates; the application must also reload the file. ConfigMaps ↗.
Secret data is base64-encoded, which is not encryption. Protect access and avoid printing values during diagnosis; verifying a key or mounted file exists is often enough. Use only the supplied dummy values in this practice environment. Secret practices ↗.
Requests, limits, and quotas act at different levels
Request: schedule it. Limit: constrain it. Quota: admit it. CPU requests use units such as 100m; memory uses quantities such as 64Mi. CPU limits can throttle; memory limit breaches can lead to OOM termination. If the scheduler cannot satisfy requests, inspect a Pending Pod's events. Container resources ↗.
A ResourceQuota caps namespace consumption or object counts. A LimitRange can set defaults and per-object bounds. Required resource declarations depend on the quota's keys: a request quota and a limit quota are not interchangeable. Rejected Pod creation may appear on the ReplicaSet because no Pod was admitted. ResourceQuota ↗, LimitRange ↗.
Practice: Configuration, Secrets, and resource controls.
Identity, permission, and process privileges are separate
Authentication establishes identity; authorization decides permitted operations; admission checks or modifies a request before storage. A ServiceAccount is a workload identity. Assign it with serviceAccountName; use Roles and bindings for necessary API permissions. Do not assume choosing a ServiceAccount grants access. Modern Pods normally use projected, time-limited tokens rather than automatically generated long-lived Secret tokens. ServiceAccounts ↗, API access control ↗, RBAC ↗.
A security context controls process behavior: user/group IDs, privilege escalation, capabilities, filesystem access, and seccomp. Pod-level and container-level fields have different scopes. runAsNonRoot must match the image's user; a read-only root filesystem needs writable volumes for paths the application writes. Test the process after hardening it. Security contexts ↗.
A CRD adds an API resource type. An operator reconciles resources into application behavior. Discover the installed type and inspect its schema before creating a custom resource; accepting an object does not prove an operator is installed or healthy. Custom resources ↗, Operator pattern ↗.
5. Services and Networking — 20%
Follow traffic one boundary at a time
Client → Service port → ready endpoint → target port → listening process. Compare the Service selector with Pod labels, then inspect EndpointSlices. A declared containerPort does not start a listener. ClusterIP serves cluster-internal clients; NodePort exposes a node port; LoadBalancer needs an implementation. DNS names include namespace, so a same-name Service in another namespace is a different destination. Services ↗, Service debugging ↗.
Ingress routes HTTP(S) by host and path through an installed controller. Match ingressClassName, backend Service name and Service port, and pathType. Prefix matches path segments: /catalog matches /catalog/items, not /catalogue. A host-scoped test needs the correct Host header. Ingress ↗.
Practice: Route traffic with Ingress. The browser lab provides a maintained NGINX controller with class nginx; use the supplied internal controller Service to test traffic.
NetworkPolicy selects and allows
A policy selects Pods in its own namespace. Once a Pod is isolated for a direction, only allowed traffic in that direction passes. Policies are additive; a connection must satisfy both source egress and destination ingress when both are isolated. A namespaceSelector and podSelector in the same peer mean both must match; separate peer entries are alternatives. Plan DNS egress as well as application traffic. A CNI that enforces NetworkPolicy is required. NetworkPolicy ↗.
The current nine browser exercises use kind's default networking and do not assess NetworkPolicy enforcement. Use a policy-capable practice cluster for allow/deny tests; successfully creating a policy object is insufficient proof.
Know what you can prove
These guides cover all five domains. The nine browser exercises assess the topics linked above; additional practice is still needed for areas such as Helm, persistent storage, RBAC, security contexts, operators, and enforced NetworkPolicy. Use the Playbook to rehearse those workflows, then test yourself: can you explain the choice, make the change, and demonstrate the requested behavior without opening the solution?
Check the exam allowed-resources policy ↗ before your sitting. A useful study reference is not automatically permitted during the exam.