The Certified Kubernetes Administrator exam evaluates practical ability to operate Kubernetes clusters and diagnose real infrastructure problems. Its five official domains provide a useful preparation structure, but the work is not a simple memory test. A Kubernetes administrator needs to reason from requirements to cluster configuration, from symptoms to evidence and from a change to verified recovery. This guide distinguishes the current administrative skills from the developer-focused CKAD exam and emphasizes original lab activities.<\/p>\n
Cluster administration begins with knowing how the Kubernetes control plane, API server, state store, controllers, scheduler, nodes and kubelet cooperate. A managed cluster may delegate some infrastructure duties to a cloud provider, while a self-managed setup requires more direct control of certificates, networking and upgrades. A candidate should recognize where desired state is recorded and which component reconciles it. If a node cannot communicate with the API server, creating another Deployment is unlikely to solve the connectivity problem. Diagnose the proper control-plane or node boundary first.<\/p>\n
Practice joining and maintaining nodes, reviewing cluster configuration, managing namespaces and role-based access controls, and understanding upgrade and backup responsibilities in an authorized cluster. Learn how to inspect control-plane health and configuration instead of relying exclusively on a green dashboard. The Kubernetes architecture<\/a> explanation is helpful for connecting component roles, but actual administration requires manipulating resources and verifying the system afterwards. Document what state must be preserved before a change and how the team would recover if the upgrade or configuration edit failed.<\/p>\n A Kubernetes workload becomes useful only after the scheduler can place its Pods on suitable nodes and the application can run with the requested resources. A Deployment is appropriate for many replicated stateless applications; DaemonSets, Jobs, CronJobs and StatefulSets serve different purposes. An administrator should know how the workload controller, node labels, taints, tolerations, affinities, requests and resource limits affect scheduling. A Pending Pod does not necessarily imply that the image is invalid. It might request resources that no eligible node can provide or require a storage topology the cluster cannot satisfy.<\/p>\n Build a scheduling lab with two differently labeled nodes, a workload that initially cannot schedule, and a controlled correction. Inspect events before changing the configuration. Apply a taint to a test node and observe which Pod can be scheduled with a corresponding toleration. Change resource requests and confirm the expected effect. Do not memorize one YAML file without explaining the constraint. The exam tests whether you can manage desired workload behavior and diagnose why it differs from the actual running state.<\/p>\n Networking competence begins with the difference between Pod addresses, Services, cluster DNS, ingress traffic and the network policy controlling communication. A Service selector maps traffic to matching Pods; it cannot route to Pods with the wrong labels or no ready endpoints. ClusterIP Services support internal discovery, while other Service types and controllers can expose selected applications. An administrator should be able to trace a request from a client to a hostname, the appropriate gateway or Service, and a reachable Pod. DNS failure, route failure and application failure are different problems requiring different tests.<\/p>\n Practice creating a Service, examining its endpoints and testing it from a Pod in the same namespace. Deliberately change a selector or create a blocked network path, then observe how client requests fail. Review NetworkPolicy semantics and the fact that policy enforcement requires a compatible cluster network implementation. When preparing external HTTP exposure, use a currently supported controller or Gateway API implementation; the community ingress-nginx controller stopped receiving fixes after its March 2026 retirement. An administrator who can distinguish a frozen API from its maintained data-plane implementation is less likely to repeat insecure tutorial commands.<\/p>\n PersistentVolumeClaims express a workload’s storage request while PersistentVolumes and storage classes describe and provision storage resources. The actual behavior depends on the cluster’s supported Container Storage Interface drivers, access modes, reclaim policy and topology. A Pod may remain unscheduled because the expected volume cannot be bound in a suitable zone. A successful mount does not guarantee that the data is replicated or backed up. Understand when temporary volumes are suitable and when persistent state must survive Pod replacement and node failure.<\/p>\n In a lab, request a small volume through an available StorageClass and attach it to a test workload. Write non-sensitive sample data, recreate the Pod and verify what persists. Examine what happens after deleting the claim and review reclaim policy rather than assuming every volume is safely retained. Compare the outcome with application recovery requirements. Storage is a smaller portion of the CKA blueprint than troubleshooting, but a broken mount can be the direct cause of a workload outage. The right answer may involve diagnosing storage provisioning rather than restarting a container repeatedly.<\/p>\n Troubleshooting is the largest current CKA domain, reflecting the administrator’s responsibility to restore working systems. A problem may involve a node in NotReady state, failed image retrieval, API connectivity, exhausted resources, invalid service routing, incorrect DNS, a blocked policy or failed volume attachment. Start by classifying the symptom and affected scope. Is one Pod failing, an entire node unavailable, or all requests to a Service broken? Examine events, resource descriptions, logs and control-plane state in an order that separates possible causes. Changing several settings at once often destroys the evidence needed to identify the original fault.<\/p>\n Choose safe diagnostic drills. Create a Deployment whose image cannot be fetched, then read the event before correcting the image reference. Configure a Service with an incorrect selector, observe the missing endpoints and repair it. Change a readiness endpoint and verify that the Pod remains running but stops receiving normal traffic. Monitor node conditions separately from application logs. The Kubernetes logging<\/a> context helps distinguish application output from cluster events. A successful correction includes confirming the desired operational outcome, not simply clearing an error message.<\/p>\n Create a disposable two-node cluster with an application that depends on a Service, a configuration object and a persistent volume. Verify that the normal path works and record the expected state. Introduce one failure at a time: schedule the Pod on the wrong class of node, reference an unavailable storage claim, break the Service selector and alter readiness behavior. For each failure, state which layer is affected, choose the smallest observation that can confirm it, apply a controlled correction and test the outcome. Avoid introducing broad network changes just because a more targeted fix is not immediately obvious.<\/p>\nWorkloads and scheduling \u2014 15 percent<\/h2>\n
Services and networking \u2014 20 percent<\/h2>\n
Storage \u2014 10 percent<\/h2>\n
Troubleshooting \u2014 30 percent<\/h2>\n
Combine the domains in a realistic recovery exercise<\/h2>\n