Kubernetes CKAD Certification Course

The CKAD exam is performance-based, so you will not be asked to install a cluster, but understanding the architecture helps you debug issues faster. If a Pod is stuck in Pending, the scheduler may not find a suitable node (check resource requests, taints, and node conditions). If a Pod is in CrashLoopBackOff, the kubelet is restarting a failing container. Use kubectl cluster-info and kubectl get nodes to verify cluster health during the exam.

Speed is essential on the CKAD exam. Use imperative commands to generate YAML quickly, then edit as needed: kubectl run mypod --image=nginx --dry-run=client -o yaml > pod.yaml. Practice creating, inspecting, and deleting Pods until it is second nature. Use kubectl describe pod [name] to view events and diagnose startup failures, and kubectl get pod [name] -o yaml to see the full spec including default values injected by the API server.

During the CKAD exam, you will work across multiple namespaces. Always check your current context with kubectl config get-contexts and switch namespaces as needed. A common mistake is creating a resource in the wrong namespace. Use the -n [namespace] flag explicitly or set the default namespace for your context. The kubectl explain command is your built-in documentation — use it liberally instead of guessing field names.

ConfigMaps and Secrets are frequently tested on the CKAD. Practice both imperative creation and YAML-based definitions. Remember that Secrets are only base64-encoded, not encrypted — enable encryption at rest in etcd for production security. On the exam, use kubectl create configmap and kubectl create secret generic with --dry-run=client -o yaml to generate manifests quickly. Always verify injection with kubectl exec [pod] -- env or kubectl exec [pod] -- cat /path/to/mounted/file.

Resource management is critical for the CKAD. Always set both requests and limits for production workloads. A common exam pattern is to debug a Pod that cannot be scheduled — check if the node has enough allocatable resources by comparing kubectl describe node capacity vs. allocated amounts. Remember the units: 1 CPU = 1000m, memory uses Mi (mebibytes) or Gi (gibibytes). Setting requests too high wastes cluster resources; setting them too low causes eviction under pressure.

Security contexts appear frequently on the CKAD exam. Common tasks include configuring a Pod to run as a specific user, preventing containers from running as root, and setting the filesystem to read-only. Always check whether the security settings should be at the Pod level (applies to all containers and volumes) or the container level (overrides for a specific container). For ServiceAccounts, the exam may ask you to create a ServiceAccount, assign it to a Pod, and verify it can access specific API resources.

On the CKAD exam, you may be asked to add a sidecar container to an existing Pod definition. The key is configuring the shared volume correctly: define the volume (typically emptyDir: {}) at the Pod level, then add matching volumeMounts in both the main and sidecar containers pointing to their respective mount paths. Remember that sidecar containers run for the entire lifetime of the Pod, unlike init containers which run to completion before the app starts.

Init containers are a common CKAD exam topic. The most typical scenario is adding an init container that waits for a Service or database to be ready. Remember that init containers are defined in spec.initContainers (not spec.containers) and run to completion in order. If you need to debug init container failures, use kubectl logs [pod] -c [init-container-name]. The ambassador and adapter patterns are tested conceptually — understand when to use each and how they differ from a basic sidecar.

Probes are a high-priority CKAD topic. A common exam task is to add a liveness or readiness probe to a Pod spec. Know the YAML structure: probes are defined under spec.containers[].livenessProbe, readinessProbe, or startupProbe. A frequent mistake is setting initialDelaySeconds too low, causing the liveness probe to kill the container before it finishes starting. Use a startup probe for slow applications instead of inflating the liveness probe's initial delay.

On the CKAD exam, you will frequently use kubectl logs to debug failing containers. Practice the flags: -c for multi-container Pods, --previous to see logs from crashed containers, and -f for live streaming. If the question asks why a container keeps restarting, the first step is always kubectl logs [pod] --previous to see the output from the last crashed instance. Combine with kubectl describe pod to read events and exit codes.

Debugging skills are paramount for the CKAD. Memorize this sequence for any Pod issue: (1) kubectl get pod to check status and restarts, (2) kubectl describe pod to read events and conditions, (3) kubectl logs to view application output, (4) kubectl exec to inspect the running container. The kubectl debug command with ephemeral containers is a powerful tool when the base image has no shell. Practice these commands until they are muscle memory.

Labels and selectors are fundamental to Kubernetes and heavily tested on the CKAD. Many exam questions involve creating a Deployment or Service that selects Pods via labels — if the selector does not match the Pod's labels, the resource will not work. Use kubectl get pods --show-labels to verify labels and kubectl label pod [name] key=value --overwrite to modify them. Remember: labels are for Kubernetes to select objects, annotations are for humans and tools to store metadata.

Deployments are the most heavily tested resource on the CKAD. Practice creating Deployments imperatively, updating images, checking rollout status, and performing rollbacks. A key exam pattern is to update a Deployment's image to a non-existent version, observe the failing rollout, and then roll back. Remember that the revisionHistoryLimit field (default 10) controls how many old ReplicaSets are retained. Use kubectl rollout history deployment/[name] --revision=2 to see the exact Pod template for a specific revision.

Jobs and CronJobs are frequently tested on the CKAD. Create Jobs quickly with kubectl create job [name] --image=[image] -- [command] and CronJobs with kubectl create cronjob [name] --image=[image] --schedule="*/5 * * * *" -- [command]. A common pitfall is forgetting to set restartPolicy: Never or OnFailure — Jobs cannot use the default Always policy. Verify CronJob schedules by checking the next scheduled run time in kubectl get cronjob.

Services are a core CKAD topic. The fastest way to create a Service on the exam is kubectl expose with the correct port and target-port. Remember that port is what the Service listens on and targetPort is what the container listens on — they can be different. If a Service is not reaching its Pods, verify that the selector labels match the Pod labels using kubectl describe svc [name] and check the Endpoints list. An empty Endpoints list means no Pods match the selector.

Ingress questions on the CKAD require you to write Ingress YAML from scratch or modify existing rules. Memorize the basic structure: apiVersion: networking.k8s.io/v1, kind: Ingress, with rules containing host, http.paths with path, pathType, and backend.service.name/port.number. Use kubectl explain ingress.spec.rules during the exam to check field names. A frequent mistake is putting the port name instead of the port number in the backend.

Network Policies are a critical CKAD exam topic. The most important thing to understand is that policies are additive — if multiple policies select the same Pod, the union of all their rules applies. A common exam task is to create a default deny policy and then allow specific traffic. Pay attention to whether the question asks for ingress, egress, or both. Remember that a namespaceSelector and podSelector in the same from/to entry act as an AND condition; in separate entries they act as OR.

Volume questions on the CKAD typically involve creating a PVC, binding it to a Pod, and verifying that data persists across Pod restarts. Practice the workflow: create a PVC with the desired storage size and access mode, reference it in the Pod's volumes section, and mount it via volumeMounts. If dynamic provisioning is available, you only need a PVC — the PV is created automatically. Use kubectl get pv,pvc to verify binding status. A PVC stuck in Pending means no PV satisfies its requirements.

StatefulSets are tested on the CKAD in the context of stateful application deployment. The key exam tasks include creating a StatefulSet with a headless Service and volumeClaimTemplates. Remember the three guarantees: stable unique network identity, stable persistent storage, and ordered graceful deployment and scaling. If you need to access a specific Pod in a StatefulSet, use its DNS name (pod-0.service-name.namespace.svc.cluster.local) rather than the Service's cluster IP, which does not exist for headless Services.

Helm was added to the CKAD curriculum to test application deployment skills. On the exam, you may need to install a chart, override values, upgrade a release, or roll back to a previous version. Practice the core commands: helm repo add, helm search repo, helm install, helm upgrade, helm rollback, helm list, and helm uninstall. Use helm show values [chart] to inspect available configuration options before installing.

The CKAD tests your ability to implement different deployment strategies. For blue-green, understand that you maintain two separate Deployments and switch the Service selector. For canary, know how to run two Deployments with a shared label that the Service selects. Kustomize is available in the exam environment via kubectl apply -k — it is useful for applying common labels or name prefixes to multiple resources. Practice the difference between kubectl apply and kubectl create, as the exam may require either approach depending on the task.