The CKAD (Certified Kubernetes Application Developer) certification from the Cloud Native Computing Foundation (CNCF) validates your ability to design, build, and deploy applications in Kubernetes. Unlike multiple-choice exams, CKAD is entirely performance-based — you work in a live terminal using kubectl for two hours with the kubernetes.io documentation open as your only reference. This free, printable CKAD practice test PDF helps you build the conceptual foundation you need before drilling hands-on terminal work.
The PDF covers all six CKAD exam domains: core concepts, configuration, multi-container pods, observability, pod design, services and networking, and storage. Study it offline, annotate it, and use it alongside live kubectl practice to build real exam confidence.
Each domain in the CKAD exam blueprint is covered in the PDF questions below. Understanding these concepts at the knowledge level makes hands-on terminal work faster and more accurate.
The foundation of every Kubernetes workload is the Pod — the smallest deployable unit, running one or more containers. ReplicaSets ensure a specified number of Pod replicas run at all times. Deployments manage ReplicaSets and enable declarative updates with rolling update and rollback capabilities. Namespaces provide logical isolation within a cluster. Essential kubectl commands: kubectl get, kubectl describe, kubectl delete, kubectl apply -f, and kubectl create — including imperative generators like kubectl run nginx --image=nginx --dry-run=client -o yaml to scaffold manifests quickly.
ConfigMaps store non-sensitive configuration as key-value pairs and can be injected as environment variables or mounted as files. Secrets store sensitive data (base64-encoded) and follow the same injection patterns. Resource limits and requests (resources.requests and resources.limits) control CPU and memory allocation per container — the scheduler uses requests for placement decisions. ServiceAccounts provide Pod-level identity for RBAC-controlled API access.
Multiple containers in a single Pod share the same network namespace and can share volumes. The sidecar pattern adds a helper container (log shipper, proxy) alongside the main app. Init containers run to completion before app containers start — used for setup tasks like waiting for a service or seeding data. The ambassador pattern uses a proxy container to simplify external communication; the adapter pattern normalizes output for external monitoring systems.
Liveness probes determine whether a container should be restarted — a failing liveness probe triggers a container restart. Readiness probes determine whether a container should receive traffic — a failing readiness probe removes the Pod from the Service endpoint list without restarting it. Startup probes protect slow-starting containers by disabling liveness and readiness checks until the startup probe succeeds. Container logs are accessed with kubectl logs pod-name -c container-name. Node and Pod resource usage is checked with kubectl top nodes and kubectl top pods.
Labels are key-value metadata on resources; selectors filter resources by label. Annotations store non-identifying metadata. Deployment rolling updates use kubectl set image or manifest updates; rollback uses kubectl rollout undo. Jobs run Pods to completion for batch tasks (completions, parallelism). CronJobs schedule Jobs using standard cron syntax (schedule: "0 * * * *").
ClusterIP (default) exposes a service on an internal IP — reachable only within the cluster. NodePort exposes a service on each Node's IP at a static port. LoadBalancer provisions an external load balancer (cloud-provider specific). NetworkPolicies control Pod-to-Pod traffic using label selectors — by default all traffic is allowed; a NetworkPolicy with an empty podSelector acts as a default-deny rule. DNS in Kubernetes resolves services as service-name.namespace.svc.cluster.local.
emptyDir volumes are ephemeral — created when a Pod starts and deleted when it stops, useful for sharing data between containers in the same Pod. PersistentVolumes (PVs) are cluster-level storage resources provisioned by an admin or dynamically via StorageClasses. PersistentVolumeClaims (PVCs) are user requests for storage that bind to a matching PV. ConfigMap and Secret volumes mount configuration data as files inside containers.
Conceptual knowledge is only half the battle — CKAD is a hands-on exam. Our CKAD practice test reinforces the theory with timed, scored questions and answer explanations that help you understand what the exam expects. Combine online practice tests with live kubectl lab time for the strongest preparation.