CKA Certified Kubernetes Administrator Exam Topics and Questions

Storage is where many CKA candidates drop easy marks because the concepts look straightforward until you are inside a live cluster under time pressure. The domain tests whether you can wire persistent storage end-to-end: from the class that provisions it, through the volume and its claim, to the running Pod that actually uses it. Get one layer wrong and the application never starts, which is exactly the failure mode the exam recreates.

– Storage classes and persistent volumes

A StorageClass defines how a volume is provisioned: which provisioner handles it, what parameters it passes, and whether binding happens immediately or waits for a Pod to request it (WaitForFirstConsumer vs Immediate). Know that the reclaim policy sits on the PersistentVolume itself, not the class, even when the class created the volume. Retain, Delete, and Recycle behave very differently after a claim is released: Retain leaves the data and the PV in a Released state that no new claim can automatically bind to, while Delete removes the underlying asset. Access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) are advertised by the volume and requested by the claim; a mismatch causes the claim to stay Pending. Volume mode distinguishes Filesystem from Block, and using Block mode requires explicit support from the underlying driver.

– Persistent volume claims and application wiring

A PersistentVolumeClaim is the unit a Pod actually references. The claim must match a PV on access mode, volume mode, storage class name, and capacity (the PV must be at least as large as the claim requests). Static binding lets you target a specific PV with a label selector; dynamic binding lets the StorageClass create one on demand. Once a claim is Bound, mount it into a Pod under spec.volumes and then reference that volume in spec.containers.volumeMounts. Knowing how to configure applications with persistent storage means being able to write that full chain from scratch: PV, PVC, and Pod spec, with the correct paths and names threaded through all three. A common mistake is mismatching the claimName in the Pod spec with the actual PVC name, which leaves the Pod in Pending with an unhelpful volume-not-found message.

How Storage is tested

At 10% of the exam, Storage typically appears as one or two performance-based tasks in a live cluster. The format is almost always imperative: create these objects so that this application has persistent storage. Items reward candidates who can produce a working PV, PVC, and Pod configuration without consulting documentation for every field. The trap is in the details: a PVC that requests ReadWriteMany against a PV that only advertises ReadWriteOnce will sit Pending, and the task will score zero even if every other field is correct. Similarly, a reclaim policy question rewards knowing which policy leaves data intact after the claim is deleted. Candidates lose marks by applying a StorageClass name to the PVC without creating or referencing one that actually exists in the cluster, and by forgetting that a Released PV cannot be rebound without manual intervention. Verify that the Pod reaches Running state before moving on; that confirmation is the only reliable check that the full chain is working.

Troubleshooting carries the largest share of the exam, and it earns that weight because it does not test knowledge in isolation. Every other domain feeds into it: a broken deployment, a failed cluster component, or a networking fault all require you to move quickly through logs, events, and API state to find the root cause. Speed matters as much as accuracy here. Candidates who know the concepts but have not practised the diagnostic sequence under time pressure consistently under-score this domain.

– Logs, monitoring, and container output

kubectl logs is your first tool, but you need to know its limits. It reads from the container runtime's log buffer; if the container has already exited, add --previous to reach the prior run. For nodes, journalctl -u kubelet surfaces kubelet errors that never appear in kubectl. The exam may present a cluster where a standard monitoring pipeline is already in place and ask you to extract a specific metric or confirm that an application is emitting data correctly. Managing stdout and stderr means understanding that Kubernetes captures both streams from the container process, and that a misconfigured logging driver or a process that writes to a file instead of stdout will produce an empty kubectl logs output. That empty output is itself a diagnostic signal, not a dead end.

– Application failure

Application failures on the exam tend to be deliberately planted: a wrong image tag, a missing environment variable, a liveness probe that fires too aggressively, or a PVC that never bound. kubectl describe pod gives you the Events section, which names the failure clearly in most cases. Know the Pod phase and condition fields: a Pod in Pending with no node assigned points at scheduling, while a Pod in CrashLoopBackOff points at the container process itself. The OOMKilled exit code means the container exceeded its memory limit, which is a scheduling and resource-limit problem as much as an application one. For Deployments, check the ReplicaSet events too, because the Deployment controller delegates Pod creation to the ReplicaSet and errors can surface a level below where you first look.

– Cluster component failure

When a cluster component fails, the blast radius depends on which component it is. A failed kube-scheduler leaves existing Pods running but new ones Pending with no node assigned. A failed kube-controller-manager stops ReplicaSet reconciliation: Pods die and are not replaced. On a kubeadm cluster, control-plane components run as static Pods under /etc/kubernetes/manifests; editing a manifest there restarts the component. For kubelet failures on a worker node, systemctl status kubelet and journalctl -u kubelet are the primary tools. Know where each component's configuration lives and how to restart it. The exam will not tell you which component is broken; it will show you a symptom and expect you to trace it to the source.

– Networking faults

Networking troubleshooting on the CKA covers both Pod-to-Pod connectivity and Service resolution. When a Service is unreachable, check in order: does the Service selector match the Pod labels, are the target ports aligned, and does the Endpoint object have addresses? An Endpoints object with no addresses means the selector matched nothing. For DNS failures, test with a temporary Pod running nslookup or dig against the CoreDNS ClusterIP, then check CoreDNS Pod health. Network policy is a common source of planted faults: a policy that inadvertently blocks egress or ingress will make connectivity appear broken at the application layer while the nodes and components are healthy. Verify CNI plugin health on affected nodes; a crashed CNI Pod will break all new veth pair creation on that node.

How Troubleshooting is tested

At 30% of the exam, Troubleshooting is the domain that determines whether you pass. Tasks are hands-on: a broken object is waiting in a named cluster and you must fix it, usually with a time budget that punishes hesitation. Items reward a systematic diagnostic sequence: check the object's status, read the events, follow the log trail, then make a targeted change. The trap is making changes without reading the error first. Candidates who immediately delete and recreate objects, or who edit manifests speculatively, waste minutes and sometimes introduce new faults. Networking tasks reward checking the Endpoint object early, because many planted faults are label mismatches that kubectl describe service exposes in seconds. Cluster component tasks reward knowing the static Pod manifest path on a kubeadm cluster; candidates who look for a systemd unit that does not exist on a kubeadm control plane lose significant time. Fix the fault, verify the symptom is gone, and move on.

After Troubleshooting's emphasis on diagnosis, Workloads & Scheduling shifts the focus to how applications are defined, configured, and placed. This domain tests whether you can manage the full lifecycle of a Deployment, feed configuration into Pods without baking it into the image, and control where and whether a Pod lands on a node. Mistakes here tend to be quiet: the object is created, but it does not behave the way the task requires.

– Deployments, updates, and rollbacks

Rolling updates on a Deployment are controlled by maxSurge and maxUnavailable in the update strategy. Know what each field does to the pace of the rollout and what happens when you set one to zero. kubectl rollout status tells you whether the rollout is progressing; kubectl rollout undo reverts to the previous ReplicaSet. Rollback does not reset the revision history to a clean state: it creates a new revision that matches the previous spec. Scaling is a separate operation from updating: kubectl scale adjusts the replica count without touching the Pod template. The exam may ask you to scale and update in sequence; doing them in the wrong order, or confusing the two commands, produces a Deployment that is either the wrong size or running the wrong image.

– Configuration and self-healing primitives

ConfigMaps and Secrets decouple configuration from the image. Both can be consumed as environment variables or as mounted files; the mounted-file approach means a ConfigMap update propagates to running Pods without a restart, while an environment variable injection does not. Secrets are base64-encoded in etcd by default, not encrypted at rest unless the cluster is configured for encryption. The exam may ask you to create either object and reference it correctly in a Pod spec. Self-healing primitives include readiness and liveness probes, which control whether a Pod receives traffic and whether it is restarted. A liveness probe with too short an initialDelaySeconds kills a slow-starting application in a loop. DaemonSets and StatefulSets are also in scope: know when each is the right primitive and what distinguishes their scheduling and identity guarantees from a standard Deployment.

– Scheduling, resource limits, and manifest tooling

Resource requests and limits affect scheduling directly. The scheduler uses requests, not limits, to decide where a Pod fits; a Pod with no request is treated as zero-cost and can be placed on any node, but will be the first evicted under pressure. A Pod whose memory usage exceeds its limit is OOMKilled; one that exceeds its CPU limit is throttled, not killed. NodeSelector, nodeAffinity, taints, and tolerations all constrain placement: a taint on a node repels Pods that lack a matching toleration, while a NoSchedule taint prevents new placement without evicting existing Pods. Awareness of manifest management tools such as Helm and Kustomize is in the syllabus at a recognition level: you need to know what they do and where their output goes, but the exam does not require you to author complex templates from scratch.

How Workloads & Scheduling is tested

At 15%, this domain usually produces two to three tasks. Items reward precision with kubectl and with YAML spec fields. A task that asks for a rolling update with specific maxSurge and maxUnavailable values rewards writing the strategy block correctly; leaving those fields at default when the task specifies otherwise scores nothing. ConfigMap and Secret tasks reward referencing the object in the Pod spec with the exact key names the task provides. Scheduling tasks reward understanding the difference between a taint and an affinity rule: the two mechanisms overlap in effect but differ in where the constraint is declared, and items are written to distinguish them. Candidates lose marks by creating the right object with the wrong name, or by mounting a Secret as environment variables when the task asks for a file mount. Read the task requirement for the consumption method before writing the Pod spec. Verify the Pod is Running and the configuration is visible inside the container.

Cluster Architecture, Installation & Configuration sits at 25% and covers the layer most candidates treat as background knowledge rather than exam material. Knowing how a cluster is built is not enough here: the exam asks you to build one, secure it, upgrade it, and protect its state. Tasks in this domain tend to be longer than average and touch multiple components in sequence, so a mistake early in a task can invalidate work done later.

– RBAC and access control

Role-based access control is the most consistently tested sub-topic in this domain. The model has four objects: Role, ClusterRole, RoleBinding, and ClusterRoleBinding. A Role grants permissions within a single namespace; a ClusterRole grants them cluster-wide or can be bound into a namespace via a RoleBinding. The binding is what connects a subject (a user, group, or ServiceAccount) to the role: creating the role without the binding gives no access. Know the difference between a ServiceAccount token mounted into a Pod and a user certificate presented to the API server. The exam may ask you to verify that a given subject can perform a specific action; kubectl auth can --as is the tool for that check. Items reward getting the resource names and verbs right: 'pods' not 'pod', 'get,list,watch' not 'read'.

– Cluster installation and infrastructure

Kubeadm is the installation tool the exam uses. kubeadm init bootstraps the control plane and writes the kubeconfig to /etc/kubernetes/admin.conf; you then apply a CNI manifest and run kubeadm join on each worker using the token and CA hash from the init output. Know the flags that matter: --pod-network-cidr must match what the CNI plugin expects, and --apiserver-advertise-address must point at the interface the API server should listen on. Provisioning the underlying infrastructure means ensuring the nodes meet the prerequisites: container runtime installed, swap disabled, required ports open, and the correct kernel modules loaded. The exam environment typically provides nodes that are nearly ready; knowing what 'nearly ready' means is what lets you complete the final steps quickly.

– Upgrades, high availability, and etcd

A kubeadm-managed upgrade follows a fixed sequence: upgrade kubeadm on the control plane node, run kubeadm upgrade apply, then upgrade kubelet and kubectl on each node in turn. Draining a node before upgrading its kubelet is required; forgetting to uncordon it afterward leaves the node schedulable in etcd but marked unschedulable in practice. High availability in a kubeadm cluster means multiple control-plane nodes sharing a load-balanced API server endpoint and a stacked or external etcd topology. etcd backup and restore is a standalone task: use etcdctl snapshot save with the correct endpoint and TLS certificate flags to create a snapshot, and etcdctl snapshot restore to recover from one. The restore path requires stopping the etcd Pod, replacing the data directory, and restarting. Missing any certificate flag in the etcdctl command produces a connection-refused error that looks like a network problem.

How Cluster Architecture, Installation & Configuration is tested

At 25%, this domain is the second-largest on the exam. Tasks are procedural and sequential: the correct sequence of steps matters as much as knowledge of individual commands. RBAC items reward producing a binding that grants exactly the permissions specified, no more and no fewer. Candidates lose marks by creating a ClusterRoleBinding when the task asks for namespace-scoped access, or by binding the role to the wrong subject type. Upgrade tasks reward executing the kubeadm sequence in order and draining nodes before touching the kubelet. Skipping the drain step or upgrading worker nodes before the control plane produces a cluster that is partially upgraded and may fail subsequent tasks. etcd backup tasks reward supplying all three certificate flags (cacert, cert, key) to etcdctl; items are written to distinguish a successful snapshot from a failed one by the file it produces. Candidates who have not practised the etcdctl syntax under time pressure consistently miss this task.

Services & Networking closes out the exam at 20% and connects directly to the Troubleshooting domain you already covered: most networking faults in a live cluster trace back to a misconfigured Service, a missing DNS entry, or a CNI plugin in a bad state. This domain tests whether you understand the full path a packet takes from one Pod to another, and whether you can build and verify each layer of that path from the command line.

– Node networking and Pod connectivity

Host networking on a cluster node means understanding which interfaces, bridges, and routes the CNI plugin creates when a Pod is scheduled. You do not need to configure the underlying network infrastructure from scratch in the exam, but you do need to interpret what is there: ip addr, ip route, and iptables -L are all fair game. Pod-to-Pod connectivity relies on the CNI plugin establishing a flat network where every Pod IP is routable from every other node, without NAT. When that connectivity breaks, the fault is usually a CNI Pod that has crashed or a missing route on the host. Know that Pods on the same node communicate via the bridge interface, while Pods on different nodes depend on the overlay or underlay mechanism the CNI plugin provides. The cluster CIDR and the Pod CIDR must not overlap with the node network.

– Service types, endpoints, and DNS

ClusterIP is the default Service type and is only reachable within the cluster. NodePort exposes a port on every node's IP and forwards to the ClusterIP. LoadBalancer builds on NodePort and requests an external IP from the cloud provider or load-balancer controller. The Endpoints object is created automatically and populated with the IPs of Pods whose labels match the Service selector. An empty Endpoints object is the fastest way to confirm a selector mismatch. CoreDNS resolves Service names within the cluster using the pattern servicename.namespace.svc.cluster.local; knowing the full form matters when you are debugging cross-namespace DNS. ExternalName Services map a cluster DNS name to an external hostname without proxying traffic, and they have no Endpoints object. Items in this area reward knowing which Service type to create for a given connectivity requirement and how to verify that the Service is actually forwarding traffic.

– Ingress and CNI plugin selection

An Ingress resource defines HTTP and HTTPS routing rules: host-based and path-based routing to backend Services. It does nothing without an Ingress controller running in the cluster; the resource and the controller are separate objects. Know how to create an Ingress resource that routes traffic correctly and how to verify that the controller has picked it up. TLS termination at the Ingress requires a Secret containing the certificate and key, referenced by name in the Ingress spec. CNI plugin selection is in scope at an awareness level: know that plugins differ in their support for network policy enforcement, that some require a specific pod-network-cidr range, and that the exam environment will have one already installed. Choosing a CNI plugin in an exam task means recognising which constraints the scenario imposes and matching them to a plugin's documented capabilities.

How Services & Networking is tested

At 20%, Services & Networking produces two to three tasks. Items reward a clear mental model of how a Service, its Endpoints, and DNS resolution interact: candidates who can trace a connectivity failure from the client Pod through DNS to the Endpoint object and back to the Pod label will answer these tasks faster and more accurately than those who rely on trial-and-error. Ingress tasks reward knowing that the controller must exist before the resource has any effect; items are written so that creating only the resource appears to succeed but leaves traffic unrouted. Candidates lose marks by creating a NodePort Service when the task asks for ClusterIP, or by specifying the wrong target port. CoreDNS tasks reward knowing the full DNS name format; using a short name that works within a namespace will fail when the task requires cross-namespace resolution. Verify connectivity from inside a test Pod using curl or nslookup after each change: the exam rewards confirmed working state, not correct-looking configuration.