Preparation for the Certified Kubernetes Administrator (CKA) Exam

Get a structured overview of the CKA certification (Certified Kubernetes Administrator): exam format (2 hours, 15-20 tasks, 66% passing score), the 5 exam domains (Troubleshooting 30%, Cluster Architecture 25%, Services & Networking 20%, Workloads & Scheduling 15%, Storage 10%), and practical learning strategies. Understand how to optimize your exam time and what skills the certification demonstrates.

Understand how a Kubernetes cluster is structured and which components work together. The control plane manages all decisions (API server as command center, etcd as data store, scheduler for placement), while worker nodes do the actual work. This knowledge is essential for quickly isolating errors and understanding where problems can occur.

Kubernetes uses various container runtimes like containerd or CRI-O to actually start containers. Learn how these runtimes are integrated, how to switch between them, and how to identify runtime-specific issues. This is especially important when containers won't start or terminate unexpectedly.

kubectl is your primary tool for cluster management. Learn how to quickly retrieve information, debug problems, and edit resources directly. Especially important: when is a fast command line shortcut worth it, and when should you work with YAML files? This decision saves valuable minutes during the exam.

In practice and during the exam, you frequently work with multiple clusters simultaneously (e.g., test, staging, production). Learn how to seamlessly switch between different clusters while maintaining overview. You'll also understand how access configuration works and what to do when authentication fails.

Build a production-ready Kubernetes cluster from scratch. Learn how individual components are initialized, how worker nodes join, and how the network plugin enables pod communication. By the end, you'll understand exactly what happens during cluster startup and can systematically fix installation issues.

A Kubernetes upgrade follows a controlled order because the control plane and workers only interoperate across supported version skews. You remove a Node from scheduling with cordon and drain, update the intended components, and return it to service. While doing so, you observe the workloads and assess which conditions preserve their availability during the upgrade.

etcd holds the authoritative cluster state; a backup is only useful when the snapshot, certificates, and restore path fit together. You create a snapshot, inspect its status, and restore the prepared cluster state from that backup. You then compare Kubernetes resources before and after the restore and identify which operational data must be backed up separately.

Pods are the basic units in Kubernetes. Learn various design patterns: a Pod with multiple containers working together (e.g., main app + log collector), containers that perform preparatory tasks before startup, and how to set up health checks so Kubernetes automatically replaces unhealthy containers. These patterns are indispensable in practice.

Kubernetes must decide how much CPU and RAM each container gets. Learn how to define requests (minimum requirements) and limits (upper bounds) per container so critical applications are guaranteed sufficient resources and no single app can monopolize the entire server. This prevents performance issues and keeps your cluster stable.

With Deployments, you run applications that automatically run multiple instances and restart on failures. Especially important: how to roll out updates via rolling update without users experiencing downtime. Learn the various update strategies and how to quickly revert to the previous version via rollback when problems arise.

Systematic troubleshooting separates symptoms, the affected layer, and the cause instead of trying commands at random. Given a prepared failure, you inspect Pods, Nodes, and related services with kubectl, journalctl, and systemctl, form a hypothesis, and test it against available events and logs. The result is a traceable diagnostic path you can reuse for other cluster failures.

Pods come and go, their IP addresses change. Services give your applications a stable address where they're always reachable. Learn the different service types and when to use each: internally in the cluster, accessible from outside, or for special database setups. This is fundamental for any Kubernetes application.

Kubernetes itself doesn't handle networking: that's done by a CNI plugin (Container Network Interface). Learn how these plugins connect Pods across different servers and how to identify network problems. Understanding the network layer is essential when Pods can't reach each other or the network is slow.

Not everything runs continuously: database migrations, nightly backups, generating reports. Learn how to implement one-time tasks (Jobs) and scheduled jobs (CronJobs) in Kubernetes. These workload types are perfect for batch processing and automated maintenance work. Understand how Kubernetes recognizes successful jobs, handles retries on failures, and cleans up old job results.

Some services must run on every server: log collectors, monitoring agents, storage drivers. With a DaemonSet, you automatically deploy such system services on all nodes (or a selection). As soon as a new server joins, Kubernetes automatically starts the service there.

Large clusters quickly become confusing. Namespaces are like virtual rooms that separate different teams or projects. Learn how to organize resources cleanly and assign fixed resource budgets (ResourceQuotas) to each area: maximum CPU, RAM, number of Pods. With LimitRanges, you set default values and prevent individual Pods from claiming too many resources. This prevents one team from accidentally consuming everyone else's resources.

Make your applications accessible from outside: HTTP/HTTPS routing with the Ingress API and the modern Gateway API. Learn various controller implementations (Traefik, Caddy) and configure path-based and host-based routing for multi-service architectures. This is essential for deploying production applications securely and at scale.

Network Policies describe permitted connections through Pod, Namespace, and IP selection, while the installed network plugin enforces them. You first create a restrictive baseline for a sample workload, then allow only the required ingress and egress traffic. Connection tests before and after the policy show which rule permits a given communication path.

Containers often need access to files: temporary caches, configuration files, secrets. Learn the various volume types and when to use each. This ranges from simple temporary directories to complex storage solutions for databases.

When containers restart, their data is normally gone. For databases and stateful apps, you need permanent storage. Learn how to connect storage systems via PersistentVolumes, request storage with a PersistentVolumeClaim, and bind it to your applications. With StorageClasses, Kubernetes even provisions new storage automatically when needed.

Databases are different from normal apps: each instance needs its own identity and storage. With a StatefulSet, you properly deploy such stateful workloads so they retain their data during updates and restarts and start up in the correct order.

Applications need configuration: database URLs, feature flags, API keys. ConfigMaps separate configuration from container images, allowing you to deploy the same app in different environments. Secrets protect sensitive data like passwords and certificates from being stored unencrypted. Learn how to inject this data as environment variables or files into your Pods and when each method makes sense.

RBAC connects permitted API actions to subjects without granting broad access across the cluster. You define a namespace-scoped Role, assign it to a user or ServiceAccount through a RoleBinding, and compare it with a ClusterRole. You then check permissions from the subject's perspective and identify where the scope of each rule ends.

Kubernetes automatically decides which server runs which Pod: does the server have enough resources? Does the Pod fit this node? Understand how these decisions are made and when you should intervene. Sometimes you want to control where Pods land: GPU workloads only on GPU servers, no databases on master nodes, apps distributed across availability zones. Learn the various placement mechanisms (NodeSelector, taints/tolerations, node/pod affinity) and when to use each. This is essential for high availability and special hardware requirements.

Many popular applications (monitoring, databases, message queues) have complex setups with dozens of YAML files. Helm is like an app store for Kubernetes: you install ready-made packages with one command and customize them to your needs. Learn how to use, update, and remove these packages when needed.

Kustomize keeps shared Kubernetes manifests in a base and expresses environment differences as overlays instead of copying entire files. You create a development, test, or production adjustment for replicas, resources, or configuration values and render the result. Comparing it with the base shows exactly which fields change and which definitions remain shared.

The CKA exam is different from theoretical tests: you solve real problems in a real cluster. Learn proven strategies for time management, how to effectively use the allowed documentation, and what to expect in the Killer.sh simulator. This session gives you the confidence to successfully pass the exam.

Everyone learns differently and has different prior knowledge. You'll receive concrete recommendations on how to continue learning after the workshop: which topics to deepen? Which practice platforms to use? How often should you practice? This tailored plan maximizes your chances of exam success.