The Certified Kubernetes Application Developer (CKAD) examination tests whether a developer can actually build, configure, expose and troubleshoot applications in Kubernetes. It is an online, remotely proctored, performance-based assessment: candidates work through command-line tasks in a two-hour session. The Linux Foundation and CNCF maintain the current curriculum, exam policies and cluster-version information. Preparing from an old article’s screenshots or memorized YAML will not be enough; the objective is to complete functional tasks efficiently and verify the result.<\/p>\n
A good plan uses one safe practice cluster and a small application that grows in complexity. Begin with an image and Deployment, add configuration and Service exposure, deliberately break readiness and networking, then package and redeploy it. You should be able to explain the Kubernetes resources you selected as well as the commands you ran. The exam is not a general infrastructure-administration credential; those responsibilities are more central to CKA. CKAD focuses on what application developers can control and diagnose.<\/p>\n
The current published domain allocation is Application Design and Build (20%), Application Deployment (20%), Application Observability and Maintenance (15%), Application Environment, Configuration and Security (25%), and Services and Networking (20%). The percentages guide relative study effort; they are not a promise that a fixed number of tasks will appear in the same order. Design and build covers images, appropriate workload objects, multi-container Pods and volumes. Deployment covers updates, rollout strategies and tools such as Helm and Kustomize. Observability covers health checks, logs and debugging.<\/p>\n
The environment and security domain includes resource requirements, ConfigMaps, Secrets, service accounts, authentication, authorization, admission concepts and application SecurityContexts. Networking covers exposing and troubleshooting Services, Ingress and relevant policies. Map every listed competency to a short command-line exercise. The CKAD preparation objectives<\/a> can be useful supplementary reading, but the Linux Foundation’s current curriculum remains authoritative if a page and the issuer differ.<\/p>\n Do not rely on a fixed Kubernetes minor version in a training screenshot. The Linux Foundation states that the assessment environment is aligned with recent Kubernetes releases and updates over time; the exam page and Candidate Handbook identify the current version and permitted resources. Learn how to inspect the version in a lab and navigate the exact API resources offered by the cluster. Kubernetes commands often persist across versions, but some resource versions and feature defaults change.<\/p>\n Create an isolated namespace, then deploy an ordinary HTTP service using a Deployment. Specify an image with an explicit tag or digest, suitable labels, a container port and resource requests. Check that the desired replicas become ready; inspect Pods and the owning ReplicaSet to understand reconciliation. Delete one Pod and observe the replacement rather than assuming manually creating Pod objects gives the same lifecycle guarantees. Note which configuration belongs in a Pod template and which belongs at the Deployment level.<\/p>\n Next implement a Job that performs a finite task and a CronJob that schedules work. Compare their completion behavior with a Deployment that runs continuously. Add an init container to prepare a test directory or wait for a simulated dependency, and a sidecar only when a second cooperating process is justified. These patterns can be tested with short, safe images instead of a large production application. The important CKAD decision is which workload primitive expresses the desired life cycle, not whether a command happens to succeed once.<\/p>\n Practise both ephemeral and persistent storage with a volume and an appropriate PersistentVolumeClaim where the lab cluster provides a storage class. Determine whether data remains after a container restarts and whether the claim is portable between nodes under the selected driver. A volume with the right mount path does not automatically make an application recoverable. Explain what state the test preserves and what would require a separate backup. Use invented data and clean up any claims after the exercise.<\/p>\n Change the container image in a Deployment and watch rollout status. Inspect the old and new ReplicaSets, then test a deliberately invalid image and observe the failure. Learn when rollout undo is appropriate and when a changed database schema makes a manifest rollback insufficient. Test maxSurge and maxUnavailable with enough replicas and capacity to see their effects. You should be able to describe what happens to currently serving traffic while replacement Pods fail readiness or are still initializing.<\/p>\n Create distinct readiness, liveness and startup probes for an application that has a delayed initialization step. Arrange for readiness to fail while the process remains alive; inspect Service endpoints and note how traffic eligibility changes. Then simulate a genuinely stuck process and observe how liveness affects restarts. The probe behavior in Kubernetes<\/a> matters because incorrect probe design can create an outage during an otherwise valid rollout. Don’t treat a liveness check as a generic substitute for end-to-end dependency testing.<\/p>\n Use Helm to install an existing chart in a test namespace, inspect values and compare the rendered manifests with the resources created. Modify a harmless value, perform an upgrade and check release history. Use Kustomize for a simple base-and-overlay configuration and understand how the tools differ. The Helm chart workflow<\/a> adds depth where your lab uses packaging rather than manually applying every YAML file. A templating tool can generate invalid or insecure output, so verify the resulting objects.<\/p>\n Put a nonsecret feature flag in a ConfigMap and supply it to the application through an environment variable or mounted file. Create a fictional credential as a Secret and configure a workload to consume it without printing the value to logs. Check what happens when either object changes: some configuration patterns require a Pod restart, while mounted projections and application reload behavior differ. Avoid assuming that changing a Kubernetes object automatically reconfigures a running process in every case.<\/p>\n Create a dedicated ServiceAccount for the workload and a narrowly scoped Role and RoleBinding for a safe resource-read operation in its namespace. Test kubectl auth can-i or an equivalent authorized check and record both allowed and forbidden actions. A ServiceAccount token or Pod identity tells the API which principal is calling; it does not grant broad permissions by itself. Do not solve a practice denial by assigning cluster-admin. Use a minimal SecurityContext and understand how container capabilities and filesystem permissions can affect application startup.<\/p>\n Set resource requests and limits, then create a workload that cannot schedule because its request exceeds available allocatable capacity. Diagnose the Pending state through events. Separately create a test that triggers CPU throttling or memory pressure under controlled, inexpensive conditions and inspect what happens. These are not interchangeable failures. The developer should know when to adjust the application, choose a more suitable resource request, or ask an administrator about cluster-level constraints rather than making a blind increase.<\/p>\n Expose your Deployment through a ClusterIP Service and confirm that the selector matches the Pods. Use a second Pod to resolve the Service name and call the expected port. Then deliberately change the selector so no ready endpoints match, observe EndpointSlices and restore the correct label. Distinguish this from an application that does not listen on the expected port or a DNS resolver that cannot answer. A Service object with no backend is a different problem from a network policy blocking a valid backend.<\/p>\n Create an Ingress resource only when an Ingress controller is installed in the lab; the API object alone does not provide routing. Verify the host and path rules from an authorized client. Use a simple NetworkPolicy to restrict traffic to selected Pods and test both the allowed and denied paths with a CNI implementation that supports policy enforcement. A written deny rule without enforcement is not a successful test. Study how the Kubernetes networking components<\/a> connect service discovery, endpoint selection and application Pods.<\/p>\n Record these failures in a notebook that names the symptom, Kubernetes resource, command used to inspect it, root cause and successful verification. The same problem should be solved again in a fresh namespace with slightly different labels and ports. That variation helps prevent false confidence from memorizing resource names or relying on a particular course’s prewritten manifest.<\/p>\n Practise quick but careful use of kubectl get, describe, logs, exec, explain, apply and rollout commands. Develop the habit of setting the correct context and namespace before any write, and verifying object state after a command returns. Use generated manifests and client-side dry-run only where appropriate; commands that create objects still need an accurate manifest and a corresponding outcome test. Know how to read events and inspect the actual resource schema rather than guess an API field from memory.<\/p>\n The official CKAD exam offers two hours for performance tasks and a passing threshold of 66% according to Linux Foundation guidance. Exam purchases currently include a defined scheduling window and retake provisions; terms and applicable price are set by the issuer and may change. Read the Candidate Handbook for identification, remote proctoring, permitted documentation and exam workspace restrictions before test day. Do not assume that normal browser tabs, notes or terminal tools available at home are permitted during the supervised session.<\/p>\n A useful final mock assessment is to take a clean lab environment and attempt five to eight unfamiliar tasks under time pressure, saving a small final verification for each. Include a Deployment change, a configuration secret, a read-only service account, a failing readiness probe and Service connectivity. Measure whether you complete the requested behavior rather than merely issuing commands. A passing score in a practice environment is evidence of progress only if the tasks and constraints were genuinely unfamiliar and checked independently.<\/p>\nBuild a small working application from a clean namespace<\/h2>\n
Configure releases, health checks and rollback behavior<\/h2>\n
Practise environment settings and application security<\/h2>\n
Make Service networking a repeatable troubleshooting exercise<\/h2>\n
Develop command-line speed without sacrificing verification<\/h2>\n
Know what CKAD validates and what should come next<\/h2>\n