Must-Know 20 Questions for Certified Kubernetes Administrator Exam
The Certified Kubernetes Administrator exam is a performance-based test administered by the Cloud Native Computing Foundation that evaluates a candidate’s practical ability to manage Kubernetes clusters. Unlike multiple-choice exams, it requires candidates to perform real tasks in a live Kubernetes environment within a two-hour time limit. This hands-on format makes preparation both more demanding and more rewarding, as every skill you build translates directly into real-world competence.
Passing this exam signals to employers that you can handle production-grade Kubernetes environments with confidence. The exam covers a broad range of topics including cluster architecture, workload management, networking, storage, and troubleshooting. Knowing the types of questions you are likely to face helps you focus your study time efficiently and walk into the exam with a clear sense of what to expect across each domain.
Cluster Architecture Core Concepts
One of the most frequently tested areas involves cluster architecture, and a common question asks candidates to describe the role of the control plane components. The control plane includes the API server, etcd, the scheduler, and the controller manager. Each plays a distinct role: the API server acts as the gateway for all cluster communication, etcd stores the cluster state, the scheduler assigns workloads to nodes, and the controller manager ensures the desired state is maintained at all times.
Another architecture question often asks candidates to explain the difference between a master node and a worker node. Master nodes run the control plane components and do not typically run application workloads. Worker nodes, by contrast, run the kubelet, kube-proxy, and a container runtime, and they are responsible for executing the actual application containers. A solid grasp of this separation is foundational to everything else on the exam and appears repeatedly across different question types.
Pod Creation And Management
A question that appears consistently involves creating a pod using the command line. Candidates are expected to use kubectl run to spin up a pod quickly, specifying the image and any relevant flags. The exam environment rewards speed, so knowing how to generate pod manifests using the dry-run flag and redirect the output to a YAML file is an essential technique that saves considerable time during the actual test.
Another common pod management question asks candidates to configure a pod to restart only under specific conditions using restart policies. The three available policies are Always, OnFailure, and Never. Always is the default and restarts the container regardless of exit code. OnFailure restarts only when the container exits with a non-zero code. Never means the container will not restart under any condition. Knowing when and how to apply these policies in a manifest is a practical skill tested in various scenario-based questions.
Namespace Isolation And Usage
Questions about namespaces test whether candidates understand how Kubernetes logically separates resources within a single cluster. A typical question asks candidates to create a namespace and then deploy a specific resource into it. Using the kubectl create namespace command followed by applying a manifest with the namespace field set correctly is the expected approach. Many exam tasks specify a namespace explicitly, and deploying to the wrong one results in lost marks.
Another namespace-related question involves listing all resources across every namespace in the cluster. The flag –all-namespaces or its shorthand -A appended to any kubectl get command achieves this. Candidates are also expected to know how to set a default namespace for their current context using kubectl config set-context, which eliminates the need to specify the namespace flag repeatedly during the exam and speeds up task completion significantly.
ConfigMaps And Secret Handling
ConfigMaps and Secrets are tested heavily because they represent the standard way to inject configuration and sensitive data into pods. A common question asks candidates to create a ConfigMap from a literal value and then mount it inside a pod as an environment variable. Knowing both the imperative command approach and the declarative YAML approach gives you flexibility depending on what the question requires.
Secrets follow the same general pattern but with base64 encoding applied to the values. A frequent exam question asks candidates to create a Secret and mount it as a volume inside a running pod. The key distinction to remember is that Secrets are base64-encoded but not encrypted by default. Candidates who confuse encoding with encryption often lose marks on questions that ask them to explain the security implications of Secrets and how to enhance their protection using encryption at rest.
Node Management And Maintenance
Node maintenance questions are among the most practical on the exam. One common task asks candidates to safely drain a node before performing maintenance, which involves evicting all running pods from that node without causing service disruption. The kubectl drain command with the –ignore-daemonsets flag handles most scenarios, as DaemonSet pods are not evicted by default because they are expected to run on every node.
After maintenance is complete, candidates are often asked to make the node schedulable again using kubectl uncordon. A related question involves cordoning a node, which marks it as unschedulable without evicting existing pods. This is useful when you want to prevent new workloads from being assigned to a node without disrupting what is already running on it. These three commands — drain, cordon, and uncordon — form a trio that appears regularly across node management scenarios.
Deployments And Rolling Updates
Deployment management is a core competency tested throughout the exam. A typical question asks candidates to create a deployment with a specific number of replicas and then update the container image to a new version. The kubectl set image command handles image updates efficiently, and candidates are expected to monitor the rollout status using kubectl rollout status to confirm the update completes successfully.
Rolling back a failed deployment is another scenario that appears frequently. If an image update causes issues, kubectl rollout undo reverses the deployment to the previous version. Candidates are also tested on pausing and resuming rollouts, which is useful when making multiple changes and wanting to apply them all at once rather than triggering a new rollout for each individual update. These commands demonstrate real operational knowledge that cluster administrators use regularly in production.
Services And Network Exposure
Networking questions test how candidates expose applications running inside pods to other services or external users. A common question asks candidates to create a Service of a specific type — ClusterIP, NodePort, or LoadBalancer — and verify that traffic reaches the correct pods. ClusterIP exposes the service only within the cluster, NodePort opens a port on every node, and LoadBalancer provisions an external load balancer when supported by the infrastructure.
Another networking question involves DNS resolution inside the cluster. Kubernetes assigns a DNS name to every Service, following the pattern servicename.namespace.svc.cluster.local. Candidates are expected to demonstrate that pods can reach services using these DNS names rather than hardcoded IP addresses. Questions may ask you to deploy a temporary pod and use tools like nslookup or curl to verify that DNS resolution and service connectivity are working as expected.
Persistent Volumes And Storage
Storage is a domain that trips up many candidates who have not spent enough time with Persistent Volumes and Persistent Volume Claims. A standard exam question asks candidates to create a Persistent Volume with a specific storage capacity, access mode, and host path, then create a matching Persistent Volume Claim and bind the two together. Understanding how binding works based on matching storage class, capacity, and access modes is essential.
Once a claim is bound, another common question asks candidates to mount the Persistent Volume Claim inside a pod at a specific path. The volumeMounts section of the pod spec defines where in the container’s filesystem the volume appears, while the volumes section references the claim by name. Getting both sections correct and verifying that the pod runs successfully with the volume attached demonstrates the practical storage knowledge the exam is designed to measure.
Role-Based Access Control Setup
RBAC questions assess whether candidates can implement proper security boundaries within a Kubernetes cluster. A typical question asks candidates to create a Role within a specific namespace that grants permissions to perform certain actions on particular resources. For example, a role might allow get, list, and watch operations on pods but nothing else. After creating the Role, candidates must bind it to a ServiceAccount using a RoleBinding.
ClusterRoles and ClusterRoleBindings extend the same concept to the entire cluster rather than a single namespace. An exam question might ask candidates to create a ClusterRole that grants read access to nodes and then bind it to a user. Candidates need to know the difference between namespace-scoped Roles and cluster-scoped ClusterRoles, as applying the wrong type to the wrong scope is a common error that results in the access permissions not working as intended.
Taints And Tolerations Explained
Taints and tolerations are tested because they control which pods can be scheduled on which nodes, and getting this wrong has visible consequences that are easy for examiners to verify. A common question asks candidates to apply a taint to a specific node using kubectl taint and then configure a pod with the corresponding toleration so that it can be scheduled on that tainted node. Without the matching toleration, Kubernetes will refuse to place the pod on that node.
There are three taint effects to know: NoSchedule, PreferNoSchedule, and NoExecute. NoSchedule prevents new pods without a matching toleration from being scheduled. PreferNoSchedule is a softer version that tries to avoid placing pods on the node but does not enforce it strictly. NoExecute evicts existing pods that do not have the matching toleration in addition to preventing new ones. Exam questions often require candidates to demonstrate the difference between these effects by observing pod behavior under each condition.
Node Affinity And Scheduling
Node affinity gives you more expressive control over pod placement than simple taints and tolerations. A question in this area typically asks candidates to label a node and then configure a pod to use requiredDuringSchedulingIgnoredDuringExecution affinity rules so that it only runs on nodes with that label. This hard requirement means the pod will remain in a pending state if no matching node is available rather than being placed on an unsuitable node.
The preferred version, preferredDuringSchedulingIgnoredDuringExecution, works as a soft rule and allows the pod to be scheduled on a non-matching node if no better option exists. Candidates are expected to write the affinity rules correctly in YAML format, including the nodeSelectorTerms and matchExpressions fields. Mistakes in the structure of these fields are common, so practicing the exact syntax until it becomes second nature is strongly recommended before sitting the exam.
Logging And Troubleshooting Techniques
Troubleshooting is weighted heavily in the exam because it reflects the realities of day-to-day cluster administration. A common question presents a pod that is failing to start and asks candidates to identify the root cause. The kubectl describe pod command provides detailed information about the pod’s events, resource limits, and any error messages generated during scheduling or container startup. Reading this output carefully usually reveals the problem quickly.
For runtime errors inside a running container, kubectl logs is the primary tool. If a container has already crashed, the –previous flag retrieves the logs from the terminated instance. Questions may also ask candidates to exec into a running container using kubectl exec to inspect the filesystem, check environment variables, or test network connectivity from inside the pod. Combining these tools effectively under time pressure is a skill that separates prepared candidates from those who struggle to complete the exam within the allotted time.
Etcd Backup And Restoration
Etcd backup and restore is one of the most important practical skills tested in the exam, and it is also one of the most specific in terms of the exact commands required. A question in this area asks candidates to take a snapshot of the etcd database using the etcdctl snapshot save command, specifying the correct endpoint and certificate paths. Getting the TLS flags right is critical because etcd requires secure communication and will reject requests that do not present valid credentials.
Restoring from a snapshot requires the etcdctl snapshot restore command followed by reconfiguring the etcd process to use the restored data directory. On kubeadm-managed clusters, this typically involves editing the etcd static pod manifest to point to the new data directory. Candidates who have never practiced this process under realistic conditions often struggle with the complexity of the steps involved. Running through a complete backup and restore cycle multiple times before the exam is strongly advised.
Network Policies For Traffic Control
Network Policy questions evaluate whether candidates can restrict traffic between pods using policy rules. A common question asks candidates to create a Network Policy that allows ingress traffic to a specific pod only from pods carrying a particular label. This requires writing a policy with a podSelector that targets the destination pod and an ingress rule with a from clause that specifies the source pod selector.
Egress policies follow the same pattern but control outbound traffic from pods rather than inbound traffic to them. An exam question might ask candidates to deny all egress from a namespace except for traffic destined for a specific external IP or port. It is important to remember that Network Policies are enforced by the CNI plugin installed in the cluster, and clusters without a compatible CNI plugin will not enforce policies even if they are correctly written. Understanding this dependency is part of the knowledge the exam expects candidates to demonstrate.
ServiceAccounts And Pod Identity
ServiceAccounts provide pods with an identity that can be used to interact with the Kubernetes API. A common exam question asks candidates to create a ServiceAccount, bind it to a Role using a RoleBinding, and then assign it to a pod so that the pod can perform specific API operations. By default, pods use the default ServiceAccount in their namespace, but assigning a custom ServiceAccount allows for more granular access control.
Candidates are also expected to know how ServiceAccount tokens are mounted inside pods. By default, Kubernetes automatically mounts a token at a known path inside the container, and applications can use this token to authenticate against the API server. Questions may ask candidates to disable this automatic mounting for security reasons by setting automountServiceAccountToken to false in either the ServiceAccount definition or the pod spec, depending on which scope of control is required.
Cluster Upgrade Process Steps
Cluster upgrade questions are practical and require candidates to follow a specific sequence of steps without skipping any. On a kubeadm-managed cluster, the process begins with upgrading the kubeadm tool itself, then running kubeadm upgrade plan to review available versions, followed by kubeadm upgrade apply to perform the actual upgrade of the control plane components. Each step must complete successfully before proceeding to the next.
Worker node upgrades follow a separate sequence: drain the node, upgrade kubeadm on that node, run kubeadm upgrade node, upgrade kubelet and kubectl, restart the kubelet service, and finally uncordon the node to return it to service. The exam may ask candidates to upgrade only the control plane or only a specific worker node, so knowing which commands apply to which part of the cluster is important. Practicing the full upgrade sequence in a lab environment before the exam eliminates uncertainty during the actual test.
Conclusion
Preparing for the Certified Kubernetes Administrator exam is a journey that rewards consistent, hands-on practice above all else. The twenty question areas covered in this guide represent the domains most likely to appear in your exam session, and each one builds on a core understanding of how Kubernetes functions as a distributed system for container orchestration. Working through these topics methodically, with real cluster environments rather than passive reading, is the most effective preparation strategy available to any candidate.
What sets successful candidates apart is not simply memorizing commands but understanding why those commands work and what happens inside the cluster when they are executed. When you drain a node, you should understand that pods are gracefully terminated and rescheduled elsewhere. When you create a Role and bind it to a ServiceAccount, you should be able to trace the chain of permissions from the API request all the way to the authorization decision. This depth of comprehension allows you to handle unexpected variations in exam questions that might not match exactly what you practiced.
Time management is equally important. The exam gives you two hours to complete a set of tasks across multiple clusters, and spending too long on a single question can cost you points elsewhere. Practice working quickly in terminal environments, use kubectl aliases and autocomplete to speed up your typing, and learn to recognize when a question is taking too long so you can move on and return later. Many candidates have the knowledge required to pass but run out of time because they have not developed the speed that comes from repeated practice.
Beyond the exam itself, the knowledge you gain while preparing for the Certified Kubernetes Administrator certification is genuinely valuable in professional settings. Kubernetes has become the standard platform for deploying containerized applications at scale, and administrators who can manage it confidently are in high demand across industries. Every lab session, every troubleshooting exercise, and every YAML file you write brings you closer to both the certification and the practical expertise that makes it meaningful. Approach your preparation with patience and persistence, and the results will follow.
- Category: All Certifications
