You have reached the end of the technical journey. Across eleven modules you have built, broken, fixed, secured and scaled the Rutas Norte platform: from that first stand-alone Pod to a production cluster with Ingress, TLS, network policies, persistent storage, full observability and canary deployments governed by GitOps. That knowledge is exactly what the CKA (Certified Kubernetes Administrator) certification measures. The only thing standing between you and the certificate is the format: a hands-on exam, in a terminal, against the clock, with a timer that does not forgive hesitation.

This lesson turns the course you have just completed into a study plan for the CKA. You will see what it certifies precisely, what the exam looks like from the inside, which domains it covers and with what weight, and —most importantly— a table mapping every official curriculum objective to the lesson in this course where you studied it. From there you get a six-week plan and a battery of eight exam-style tasks solved with the exact command and its target time.

Essential notice. The specific exam details (price, exact duration, number of attempts included, pass mark and domain weighting) change over time. Everything you read here is indicative and reflects the moment this lesson was written. Before you enrol, always check the current official curriculum on the Linux Foundation / CNCF website (training.linuxfoundation.org and cncf.io/certification/cka). The certification programme reviews its objectives with each Kubernetes release.

1. What the CKA certifies and who it is for
2. The exam format from the inside
3. The curriculum domains and their indicative weights
4. Full map: every CKA objective and its lesson in this course
5. CKA-specific skills worth practising separately
6. A six-week study plan
7. Official resources and the practice simulator
8. Eight CKA-style tasks solved against the clock

The CKA certifies that you know how to administer and operate a Kubernetes cluster. It is not a certification about container theory or about application development: it is the certification of the profile that keeps the cluster alive.

In an organisation like Rutas Norte, the person holding a CKA is the one responsible for:

• CKA: administering the cluster. Nodes, control plane, etcd, RBAC, networking, storage and diagnosis.
• CKAD: developing on the cluster; application manifests and speed with kubectl (lesson 12-02).
• CKS: securing the cluster; hardening, policies and detection (lesson 12-03). Requires a valid CKA.

The CKA is the natural entry point if your work is platform, SRE or infrastructure.

There are no formal prerequisites: anyone can enrol. The real requirements are practical: being comfortable with the Linux command line (systemctl, journalctl, file permissions, vim), understanding containers, and having worked on a real cluster —the mileage this course has given you.

It is also worth knowing what does not come up. There are no multiple-choice questions: everything is hands-on. Helm, Kustomize and Argo CD are not covered in depth, nor are the managed providers (EKS/AKS/GKE), nor Prometheus or Grafana as products —kubectl top and the metrics-server are—, nor application development. The exam focuses on pure Kubernetes.

This is the section most people underestimate. Knowing Kubernetes and passing the CKA are different things, and the difference lives right here.

Again: all these figures are indicative. Verify the current curriculum and conditions on the official website before paying for your enrolment.

This is trap number one in the exam, and the one that gives away the most points to the careless.

The exam does not give you one cluster: it gives you several, each with a different context name. Every task starts by telling you which context to work in, with a command you can copy and paste:

If you solve the task perfectly on the wrong cluster, your score is zero. There are no partial marks for good intentions.

Commands you need at your fingertips, automatically:

Mandatory habit: the first command of every task is the use-context you were given. No exceptions, not even when "it is the same one as before".

Each task carries a weight in points shown in the statement (for example, "Task weight: 7 %"). They all add up to 100.

What matters:

• Partial marks exist. If a task asks you to create a Deployment with 3 replicas, expose it with a Service and add a probe, and you only do the first two things, you take part of the points. Never leave a task blank.
• Grading is automatic and based on the final state of the cluster. Nobody looks at how you did it. If the object exists with the requested configuration, it scores; it makes no difference whether you created it with kubectl create, from a YAML file or by editing it by hand.
• That means the imperative route is just as valid as the declarative one, and far quicker.

During the exam you may open one additional browser tab to consult:

• https://kubernetes.io/docs/ (including the API reference and the blog)
• The documentation of the official subprojects linked from there (for example kubernetes.io/docs/reference/kubectl/)

You may not use general search engines, forums, your own notes, other websites or AI tools. It is proctored.

This changes your study strategy completely: you do not need to memorise YAML. You need to know where each example lives and adapt it in seconds. A PersistentVolume manifest, a NetworkPolicy or an Ingress with TLS are long to type and easy to copy.

Pages worth having mentally located (covered in more detail in lesson 12-04):

• The terminal lives in a browser. Copy and paste works, but with its own shortcuts (usually Ctrl+Shift+C / Ctrl+Shift+V on Linux). Practise it.
• The available editor is vim (and nano). If you cannot handle vim with at least basic fluency, give it a couple of hours before the exam.
• You have sudo access to the nodes over ssh when a task requires it (to fix the kubelet, for instance).
• There is a notepad in the exam interface for jotting things down; use it to keep your list of pending tasks.

The official CKA curriculum is organised into five domains. This is the split published at the time of writing this lesson; verify it on the official website, because the programme is reviewed periodically.

Look closely at that split: troubleshooting is the heaviest domain, almost a third of the exam. It is not a topic you study by reading: you train it by breaking things and fixing them. It is exactly what you did in module 7 (07-06) and module 11 (11-06).

With two hours and ~17 tasks, the average is around 7 minutes per task, but the real distribution is very uneven:

Leave the final 10 minutes unallocated, for review. It is the best possible use of those minutes.

This is the section that turns the course into a study plan. Every curriculum objective is linked to the lesson where you worked on it. Revising for the CKA is, literally, rereading these lessons and redoing their exercises on a real cluster.

The course has given you the knowledge, but there are seven procedures that are almost certain to appear in the exam and that you need memorised like a choreography. Go over them until they come out without thinking.

On the control node:

On the worker node:

If the token has expired (it lasts 24 h), regenerate it from the control node:

Check: kubectl get nodes -o wide must show every node as Ready.

The canonical procedure (always: control plane first, then the workers, one at a time).

Classic traps: forgetting --ignore-daemonsets on the drain (it always fails, because there are CNI and kube-proxy DaemonSets); using upgrade apply on a worker; forgetting the final uncordon.

This is the task worth the most points and the one most people get wrong. Memorise it.

Backup:

Verify the backup:

Restore:

The bits people forget:

• The etcd certificates live in /etc/kubernetes/pki/etcd/, not in /etc/kubernetes/pki/.
• If the task statement gives you different certificate paths, use theirs.
• You must restore into a new directory, not over the existing one.
• What you change is the hostPath volume, not just the container's --data-dir argument. Change both if the manifest has them out of sync.

After renewing you have to restart the control plane static pods —by temporarily moving the manifests out of /etc/kubernetes/manifests/ or restarting the kubelet— and regenerate ~/.kube/config if the admin certificate has changed.

You may also be asked to approve a CSR for a new user:

The CertificateSigningRequest manifest (group certificates.k8s.io/v1, with the request field in base64, signerName: kubernetes.io/kube-apiserver-client and usages: ["client auth"]) is copied from the documentation by searching for "certificate signing requests": it is quicker and safer than typing it out.

This is the star scenario of the troubleshooting domain. The mental sequence is always the same:

Typical causes they will plant on you, and their symptoms:

Golden rule: static pods are not managed with kubectl. They are managed by editing files in /etc/kubernetes/manifests/, and the kubelet reacts within seconds.

It shows up in practically every exam. These four commands solve 90 % of the cases:

And the check you must always leave done:

This plan assumes between 8 and 10 hours a week and that you have already done the course. The rule that governs it: for every hour of reading, two hours of keyboard.

How to use it. Week 6 is not for learning anything new: it is for measuring, correcting and resting. Leave the last day to prepare the physical exam environment (see 12-04) and do not touch new topics in the final 48 hours.

Enrolment usually includes access to an exam simulator (typically two sessions of around 36 hours each, in an environment equivalent to the real one). Tips on using it:

• Do not burn it early. Use it once you already feel reasonably prepared, in week 6.
• Its difficulty is usually higher than the real exam. If you score 60 % there, you are in good shape.
• What is valuable is not the score but the solutions: read them all, including the tasks you got right, because there is almost always a quicker way.

You do not need to pay for anything. With kind you get a cluster with one control node and two workers in under a minute (revisit 10-01):

That said, to practise kubeadm, etcd and the broken control plane you need real machines (VMs with Multipass, Vagrant or similar): kind runs the control plane inside containers and faithfully reproduces neither systemctl nor the host's static pods.

Practise these eight as if they were the exam: timer running, only kubernetes.io open. The scenarios are from Rutas Norte.

Context: kubectl config use-context rutas-norte-dev

In the rutas-norte-dev namespace, create a Deployment called web-store with the image nginx:1.27-alpine and 3 replicas. Expose it with a ClusterIP Service called web-store-svc on port 80.

Check:

The trap: if endpoints comes back empty, the selector does not match. kubectl expose inherits it correctly; writing it by hand is where it breaks.

Context: kubectl config use-context rutas-norte-pro

Take an etcd backup into /opt/etcd-rutas-norte.db. Then restore the previous backup /opt/previous-snapshot.db into the directory /var/lib/etcd-restore. The certificates are in /etc/kubernetes/pki/etcd/.

In the manifest, the volume ends up like this:

Check:

The trap: snapshot save does not need sudo if your user can read the certificates, but restore writes into /var/lib, so it does. And you must change the volume's hostPath, not just the container's --data-dir.

Context: kubectl config use-context rutas-norte-pro

Node node-2 is due for maintenance. Empty it of workloads without removing the DaemonSets, and make sure no new pods are scheduled onto it.

Check:

The trap: drain already does a cordon. If it fails because of a stand-alone pod with no controller, add --force.

Context: kubectl config use-context rutas-norte-pro

Create the ServiceAccount support in rutas-norte-pro. Grant it permission to view pods and read their logs in that namespace, and nothing else. Verify the result.

Check:

The trap: pods/log is a separate subresource. Without it, kubectl logs fails even though you can list pods.

Context: kubectl config use-context rutas-norte-pre

Create a PersistentVolume pv-reports of 2Gi, mode ReadWriteOnce, hostPath at /mnt/reports, with storageClassName: manual. Create a 1Gi PVC pvc-reports that consumes it, and a Pod occupancy-reports with image busybox:1.36 that mounts it at /data and runs sleep 3600.

Check:

The trap: if storageClassName does not match exactly between PV and PVC, the PVC stays Pending forever. And the PV is cluster-scoped: it takes no namespace.

Context: kubectl config use-context rutas-norte-pro

Node node-3 shows up as NotReady. Investigate and bring it back to Ready without reinstalling anything.

Typical diagnostic output:

The trap: enable as well as start. If you only do start, the grader may reboot the node and you will fail again. If the kubelet starts but dies, look at journalctl: it is usually a wrong path in /var/lib/kubelet/config.yaml or an invalid kubeconfig.

Context: kubectl config use-context rutas-norte-pro

In rutas-norte-pro, bookings-postgres must only accept inbound traffic on port 5432 from pods labelled app=bookings-api in the same namespace. Everything else, denied.

Check:

The trap: declaring policyTypes: [Ingress] is what makes the policy deny everything not explicitly allowed. If you omit it and there are no egress rules, the behaviour is not what you expect. And the CNI must support NetworkPolicies (Calico does; the default CNI in kind does not).

Context: kubectl config use-context rutas-norte-pro

Upgrade the worker node node-1 from version 1.30.4 to 1.31.1. The control plane is already on 1.31.1.

Check:

The trap: on workers it is kubeadm upgrade node, never upgrade apply. And if the package repository is pinned to minor 1.30, you first have to change the pkgs.k8s.io repository URL to v1.31, or apt will not see the new version.

1. Practise on a real cluster, do not just read. You pass the CKA with your hands.
2. Time yourself from day one. Knowing how to do something in 15 minutes is useless if the target is 6.
3. Master kubectl explain. kubectl explain pod.spec.containers.livenessProbe --recursive saves you opening the browser.
4. Hold the documentation in your head as a map. Do not memorise YAML: memorise which page it is on.
5. Learn to read events. kubectl describe pod and kubectl get events --sort-by=.lastTimestamp solve half the troubleshooting domain.
6. Get comfortable with sudo. Many administration tasks happen on the node, not in kubectl.
7. Simulate the exam environment. Same browser, same terminal, same keyboard. It reduces friction on the day.

Take the current official CKA curriculum (download it from the cncf/curriculum repository) and, for each objective, note three things in a table of your own: the lesson in this course that covers it, your confidence level from 1 to 5, and whether you could solve it without documentation. Sort the table by ascending confidence: that order is your revision plan.

On a three-node cluster built with kubeadm (or VMs), solve the following in 30 straight minutes with no breaks:

1. Back up etcd into /opt/backup.db and verify it with snapshot status.
2. Drain node-1, upgrade its kubelet to the next patch version, and return it to service.
3. Create the ServiceAccount auditor with read-only permissions on pods and services across all namespaces, and prove it with auth can-i.

Deliberately cause these three failures, one at a time, and fix each one while timing yourself:

1. Change the --secure-port in /etc/kubernetes/manifests/kube-apiserver.yaml to 6444.
2. Rename /etc/kubernetes/pki/etcd/server.key to server.key.bak.
3. Change staticPodPath in /var/lib/kubelet/config.yaml to /etc/kubernetes/pod-manifests.

Target: diagnose and fix each one in under 6 minutes.

Solution to Exercise 1

There is no single solution, but your table should look something like this (extract); the deciding criterion is the last column:

Anything with confidence ≤ 3 and "No" in the last column goes into weeks 4 and 5 of the plan. The usual trap is scoring yourself high on things you understand but have never executed: if you have not done it with your hands this week, confidence is 3 at most.

Solution to Exercise 2

etcd block (target 8 min):

Node block (target 15 min):

For a patch-only change (1.30.4 → 1.30.5) upgrading the kubelet is enough; a minor version change would also require sudo kubeadm upgrade node.

RBAC block (target 7 min): because it says "all namespaces", it requires ClusterRole + ClusterRoleBinding:

The classic mistake is using Role+RoleBinding: that would only cover one namespace. The second mistake is a ClusterRole with a RoleBinding, which restricts the permissions to one specific namespace —useful in other cases, but not what was asked.

Solution to Exercise 3

The diagnostic sequence is always the same, and it is worth putting on autopilot:

The key difference this exercise burns in: the manifests in /etc/kubernetes/manifests/ are reread by the kubelet on its own, within seconds; /var/lib/kubelet/config.yaml does require sudo systemctl restart kubelet to take effect.

The CKA does not measure whether you know Kubernetes in the abstract: it measures whether you can operate a cluster with your hands and in a hurry. After eleven modules building Rutas Norte, you already have the knowledge; what this lesson has given you is the translation of that knowledge into the language of the exam.

The points to take away:

• The CKA certifies the administration profile: nodes, control plane, etcd, networking, storage, RBAC and, above all, diagnosis (the heaviest domain, around 30 %).
• The exam is hands-on, timed and spread over several clusters. use-context is the first command of every task, without exception.
• There are partial marks: never leave a task empty.
• You may consult the official documentation and nothing else. Study where everything is; do not memorise YAML.
• The table in section 4 turns this course into your study plan: every official objective has its lesson.
• Seven procedures must be on autopilot: kubeadm, upgrade, etcd, certificates, drain, broken control plane and RBAC.
• Always check the current official curriculum on the Linux Foundation / CNCF website before enrolling: weights, duration and conditions change.

In the next lesson we change profile. If the CKA is the certification for whoever keeps the cluster running, the CKAD is the one for whoever builds on top of it: less etcd and more application manifests, less administration and far more speed with kubectl. We will look at how they differ, which domains they cover and how to train the skill that decides that exam: doing many correct things in very little time.