CKS — the Kubernetes security exam, and the CKA prerequisite trap

CKS is the hardest of the three CNCF Kubernetes exams and the only one with a prerequisite. Weightings and prerequisite rules change, so check the Linux Foundation’s exam page before you book.

A bundle with Kubernetes Security Essentials runs to $645.

The shape of the curriculum

Notice how the weight is distributed. The three largest domains are all about what happens around the cluster: what you deploy into it, where those images came from, and what they do at runtime. Only 40% is the cluster itself.

That reflects where Kubernetes security incidents come from. Very few of them start with someone attacking the API server directly.

The prerequisite, stated precisely

The Linux Foundation’s wording is:

Certified Kubernetes Security Specialist (CKS) candidates must have taken and passed the Certified Kubernetes Administrator (CKA) exam prior to attempting the CKS exam.

Read that carefully, because a lot of secondhand guidance states a stricter rule than the documentation does.

The published wording requires that you have taken and passed CKA before attempting CKS. Nothing in the text says the CKA must still be unexpired on the day you sit CKS. We’ve seen both readings asserted confidently online.

Don’t plan around our reading of it. If your CKA is close to expiry and you’re booking CKS, check with the Linux Foundation directly before you pay. It’s a cheap email that avoids an expensive scheduling problem, and the public documentation doesn’t settle the question either way.

The three big domains

Supply chain security (20%) is the one most CKA-holders have never touched. Image scanning, image signing and verification, admission control that rejects unsigned or vulnerable images, minimising base images, and knowing what an SBOM is for. If you’ve never configured an admission policy that blocks a deployment, start here.

Minimize microservice vulnerabilities (20%) is security contexts, pod security standards, network policies that default-deny properly, secrets handling, and sandboxed runtimes. The default-deny NetworkPolicy is a rite of passage: write one, watch everything break, then allow back exactly what’s needed.

That exercise wants a cluster you can wreck without consequence, which is what the CKS track on CertLabs is for. It’s our own platform, and the labs reset between attempts, so breaking cluster networking costs you nothing.

Monitoring, logging and runtime security (20%) is behavioural detection, Falco or equivalent, plus audit logging. Configure the API server audit policy by hand at least once. It’s a fiddly file, and the exam is a bad place to meet it for the first time.

Cluster and system hardening

Between them these are 25%: API server flags, RBAC that’s genuinely least-privilege, kubelet configuration, service account tokens, and reducing the host attack surface. CIS benchmark tooling shows up here, and knowing how to run a benchmark and interpret its output is worth the hour it takes to learn.

RBAC deserves specific attention. Most clusters we audit have RBAC that’s technically configured and functionally cluster-admin for half the workloads. The exam will ask you to build the tight version.

Sit it soon after CKA

The two exams share a terminal, a time limit and a documentation-navigation skill, and that muscle memory is worth real marks. Leave two years between them and you’ll be rebuilding it from scratch.

And as with CKA: two hours goes fast. Practise against a clock.