Certified Kubernetes Administrator (CKA) #1: The Exam Environment — alias and dry-run, vim/yq setup, time management

If the 21-post CKAD series had you mastering manifest authoring from an app developer’s point of view, the next step is the administrator’s job of installing, operating, and fixing the cluster itself. Among the CNCF Kubernetes certifications, the hands-on exam taken from an operator’s point of view is the Certified Kubernetes Administrator (CKA). This series unpacks every domain you need to pass CKA across 27 posts.

Where CKAD asked “how do you deploy an app,” CKA asks “how does the cluster run, and how do you fix it when it breaks.” You bootstrap the control plane yourself, back up and restore etcd, and trace down why a node went NotReady. So this first post covers not only the exam structure but also the setup that decides how efficiently you use your 2 hours.

What kind of certification is CKA #

CKA validates, hands-on, your ability to install, configure, operate, and troubleshoot a Kubernetes cluster. Where CKAD was the developer’s job of working with apps on top of a cluster, CKA deals with the cluster itself. It checks whether you can finish tasks like these in an empty terminal within the time limit.

• Bootstrap a control plane with kubeadm and join worker nodes
• Upgrade a cluster by one minor version
• Save an etcd snapshot and, in a failure scenario, restore from that snapshot
• Grant least privilege to users and ServiceAccounts with RBAC
• Trace and fix the cause of a NotReady node, a CrashLoop Pod, or an expired certificate

Someone who passes this exam goes beyond knowing how to write manifests — they understand how the cluster’s components mesh and run together and can recover from failures by hand.

Who gets value from it #

CKA, alongside CKAD, is the center of the hands-on certifications, and it’s also a prerequisite for moving on to CKS (the security specialist). The feel for etcd recovery, certificates, RBAC, and troubleshooting you build here carries straight into CKS.

Exam structure #

The surface-level facts about the CKA exam are worth committing to memory.

The decisive difference from CKAD #

In CKAD, most tasks were about creating app resources within a single cluster. CKA has you move across multiple clusters/nodes and drop down to the system level. You SSH into nodes to manage the kubelet with systemctl, fix static Pod manifests in /etc/kubernetes/manifests, and take snapshots with etcdctl. In other words, kubectl alone isn’t enough — you also need a Linux operations feel.

The largest domain is Troubleshooting (30%) #

Of CKA’s five domains, Troubleshooting is the largest at 30%. That means the weight leans toward fixing what’s already broken rather than building something new. So this series dedicates its last four posts (#22–#25) entirely to troubleshooting.

The weight of the exam domains #

The CKA scope is laid out across five domains in the official exam curriculum.

The weights are your guide to splitting study time. Troubleshooting (30%) and Cluster Architecture (25%) together make up 55%, so these two domains decide whether you pass. Troubleshooting in particular builds on knowledge from the other domains, so you’ll only solve it after you’ve firmed up architecture and networking.

Setting up the exam environment #

CKA, like CKAD, is half knowledge and half speed. Doing the following setup the moment the exam starts saves tens of seconds per task.

alias and environment variables #

# kubectl to k
alias k=kubectl

# dry-run + YAML output to do
export do="--dry-run=client -o yaml"

# immediate deletion to now
export now="--force --grace-period=0"

# completion (extends to k as well)
source <(kubectl completion bash)
complete -o default -F __start_kubectl k

vim setup: preventing YAML indentation mishaps #

set expandtab
set tabstop=2
set shiftwidth=2
set number

yq: handling YAML from the command line #

In CKA, you’ll often need to quickly change just a specific field in a manifest or static Pod file. If yq is installed, it’s safer than editing by hand.

# read a specific field
yq '.spec.containers[0].image' pod.yaml

# modify a field (in-place)
yq -i '.spec.replicas = 3' deploy.yaml

System commands for managing nodes and the control plane #

CKA has a lot of tasks that take you inside the nodes. The following commands need to be second nature.

# connect to a node (the hostname given in the exam)
ssh node01

# kubelet status and logs
systemctl status kubelet
journalctl -u kubelet -f

# location of static Pod manifests (control plane components)
ls /etc/kubernetes/manifests/

# etcd snapshot
ETCDCTL_API=3 etcdctl snapshot save /opt/snap.db \
  --cacert=... --cert=... --key=...

Check the context switch first of all #

Each task is only graded if you solve it on the designated cluster/node. Making it a habit to run first the kubectl config use-context ... command given for each question prevents wrong answers. CKA has multiple clusters, so this mistake is especially common.

k config use-context <the context specified in the question>

Study strategy #

1) Break a cluster yourself #

CKA doesn’t improve from reading. The person who built a multi-node cluster with kubeadm themselves, deliberately broke etcd and then restored it, and let a certificate expire is the one who stays steady on exam day. If that’s hard locally, build a practice environment from two or three cloud VMs.

2) Save Troubleshooting for a concentrated final push #

Troubleshooting builds on knowledge from the earlier domains, so firm up architecture, workloads, networking, and storage first, then bring it all together in #22–#25. At 30% it’s the largest weight, so locking in points here is the crux of passing.

3) Partial credit and time management #

CKA is graded per task, and some tasks award partial credit. When you get stuck on one task, flag it and move on, then pile up sure points starting with the high-value tasks your hands know well — that’s how you clear the passing line. Time management is covered in detail in #26.

4) Save mock exams for the back half #

After one loop through this series, you’ll find a full-scale hands-on mock exam in #27. If you need more practice, the CKA scenarios on killercoda or the killer.sh mock environment included with your exam voucher are the trustworthy benchmark.

Registration and the testing environment #

Registration steps #

1. Buy CKA on the Linux Foundation training portal. Waiting for one of the frequent discount events will get you a lower price
2. Make use of the two killer.sh mock exams included with your voucher. The environment is nearly identical to the real exam
3. Book your exam date in the PSI proctoring system
4. Pass the system compatibility check (browser, webcam, network) before the exam

Preparing for the online-proctored exam #

CKA is an online-proctored exam where you connect to a remote terminal to work.

• ID — A passport with English Romanization is safest. The name must match your registration info exactly
• Testing environment — Clear everything off the desk, use only one screen even with dual monitors, and block family and roommates from entering
• System check — Check in 30 minutes before the exam and close all background apps. A stable wired network is recommended

Wrap-up #

What this post locked in:

• CKA is the cluster administrator’s hands-on certification. Installation, configuration, operation, and troubleshooting validated in an empty terminal
• About 15–20 tasks / 2 hours / 66% / $395 (includes one retake) / valid 2 years. Browsing the official docs is allowed during the exam
• Five domains — Cluster Architecture (25%), Workloads and Scheduling (15%), Services and Networking (20%), Storage (10%), Troubleshooting (30%)
• Setup — alias k, do, now, vim indentation, yq, systemctl/journalctl, etcdctl, context switching
• Study strategy — break a cluster and recover it yourself. Save troubleshooting for the end to bring it all together. Save mock exams for the back half

Next — Cluster Architecture 1 #

The environment is set. Now we go into how the cluster runs, starting with the control plane.

In #2 Cluster Architecture 1: Control plane, we’ll look firsthand at what kube-apiserver (the gateway for all communication), etcd (the cluster state store), kube-scheduler (deciding Pod placement), and kube-controller-manager (the reconciliation loop) each do, how they run as static Pods, and what happens to the cluster when a component dies.