CKS exam preparation: the six domains and the tools in the exam environment

CKS in numbers

The exam is 15-20 performance-based tasks in 120 minutes. The pass mark is 67%, the list price is $445 and the certification is valid for 2 years. Results arrive by email within 24 hours. Like CKA, each task names a host to ssh to, and the base node must not be rebooted.

What the official pages say about tools

Three official sources describe the environment, and none of them is a complete tool list. The candidate instructions list what every SSH host has. The resources-allowed page lists the documentation you may open, which hints at the projects tasks can involve. The curriculum PDF names tools inside its competencies. Anything beyond these three is someone’s guess, however confidently it is written.

Cluster setup and cluster hardening

Cluster Setup (15%) is about the perimeter of the cluster: NetworkPolicies to restrict access, reviewing component configuration against the CIS benchmark, Ingress with TLS, protecting node metadata and endpoints, and verifying platform binaries before you deploy them. Cluster Hardening (15%) is about access inside it: RBAC with least privilege, careful use of ServiceAccounts, restricting access to the API, and upgrading Kubernetes to avoid known vulnerabilities.

• Write a default-deny NetworkPolicy and the allow rules a workload needs, then prove both with a test Pod.
• Compare kubelet and API server flags with a benchmark recommendation and fix what differs.
• Verify a binary against its published checksum before installing it.
• Disable automounting of ServiceAccount tokens where a Pod does not need the API, and scope Roles narrowly.

System hardening

System Hardening is the smallest domain at 10%, but it is where kernel features appear. The curriculum asks you to minimise the host OS footprint, use least-privilege identity and access management, minimise external network access, and appropriately use kernel hardening tools such as AppArmor and seccomp. In practice that means loading an AppArmor profile on a node and referencing it from a Pod, and applying a seccomp profile through the Pod or container securityContext.

• AppArmor: check that the profile is loaded on the node where the Pod runs, then reference it in the securityContext.
• seccomp: the RuntimeDefault profile and a custom profile placed in the kubelet’s seccomp directory.
• Reduce what runs on the node: unneeded services, packages and open ports.

Microservice vulnerabilities and supply chain security

Minimize Microservice Vulnerabilities (20%) covers Pod Security Standards, managing Secrets, isolation such as multi-tenancy and sandboxed containers, and Pod-to-Pod encryption with Cilium or Istio. Supply Chain Security (20%) covers minimal base images, understanding the supply chain (SBOM, CI/CD, artifact repositories), securing it with permitted registries and signed artifacts, and static analysis of workloads and images, with Kubesec and KubeLinter named as examples.

• Enforce a Pod Security Standard on a namespace with Pod Security Admission labels, and fix a Pod that violates it.
• Encrypt Secrets at rest with an EncryptionConfiguration and confirm the stored value is no longer plain.
• Run a workload with a RuntimeClass for a sandboxed runtime when a task asks for isolation.
• Restrict images to a permitted registry with an admission control and generate an SBOM for an image.

Monitoring, logging and runtime security

This domain is 20%. The curriculum asks you to perform behavioural analytics to detect malicious activity, detect threats across infrastructure, applications, networks, data and users, investigate phases of an attack, keep containers immutable at runtime, and use Kubernetes audit logs to monitor access. Falco's documentation is on the allowed list, which tells you behavioural detection is in scope; audit logging is configured on the API server itself.

• Write or adjust a rule for a runtime detection tool and find the event it produces.
• Enable an audit policy on the API server, then read the log to answer who changed what.
• Make a container immutable: a read-only root filesystem, no privilege escalation, no shell where possible.

A six-week CKS plan after CKA

The plan assumes you passed CKA recently and still have the kubectl speed. It spends most time on the three large domains and uses the two included simulator sessions in the last two weeks. Keep a cluster on the exam’s minor version so admission plugins and API fields behave as they will on the day.

Exam-day habits that matter more on CKS

Security tasks often change components that other things depend on, and a broken API server costs you every remaining task. Before editing a static Pod manifest, copy it. After editing, watch the component come back before moving on. Verify every control by testing it: a NetworkPolicy that you have not probed, or an AppArmor profile you have not seen enforced, is a guess.

1. 1Back up any file under /etc/kubernetes before editing it.
2. 2After a control plane change, wait until kubectl answers again before continuing.
3. 3Test each control with a request that should fail and one that should succeed.
4. 4Return to the base node after each task, as the instructions require.

Editing control-plane files safely

Several CKS domains end with a change to a control-plane component: an API server flag for audit logging or admission, an encryption configuration, a kubelet setting. On a kubeadm cluster the API server runs as a static Pod defined in /etc/kubernetes/manifests, and the kubelet recreates it whenever that file changes. A typo there takes the API server down, and every later task that needs kubectl waits for you to fix it. A fixed routine keeps that risk small.

1. 1Copy the manifest to a backup location outside /etc/kubernetes/manifests before editing; the kubelet tries to run manifest files it finds in that directory.
2. 2Make one change at a time, and add any file the flag refers to, such as an audit policy, plus the matching volume and volumeMount.
3. 3Wait for the API server to return, checking with kubectl get nodes or the container runtime on the node.
4. 4If it does not come back within a minute or two, read its logs under /var/log/pods or with the container runtime, then fix or restore the backup.
5. 5Confirm the change took effect, for example that audit entries are being written, before you move on.