CKS — Certified Kubernetes Security Specialist

CKA proved you can run a cluster. The Certified Kubernetes Security Specialist asks whether you can be trusted to run one that somebody is actively trying to break into — and it will not even let you register without a currently valid CKA already in hand. This page is the natural next stop after CKA: the exact format, the six official domains and their weights, an honest accounting of how much of this course's existing security material already prepares you and how much is a genuine gap, and how to study for an exam that grades cluster hardening, admission control, and runtime detection instead of day-to-day cluster operation.

What the CKS actually tests, and who it's for

☺ Like you're 10: It's the test for the person who has to assume someone's already trying to break into the cluster, not just the person keeping it running.

The CKS is administered by The Linux Foundation on behalf of the CNCF, sits above CKA and CKAD in the practitioner tier of the CNCF Kubernetes ladder, and certifies exactly one thing: can you secure a Kubernetes cluster across its whole lifecycle — how it's built, what's allowed to run on it, and what happens the moment something on it starts behaving badly. It does not retest cluster operation. It assumes you already have that muscle memory from CKA and spends its entire two hours on top of it: restricting who can reach the API server, minimizing what a compromised container can actually do, verifying supply-chain integrity before a workload ever ships, and catching malicious behavior once something is already running.

That framing decides who should sit it. It targets people who already operate clusters and are moving toward owning their security posture specifically — a DevOps engineer stepping into platform-security work, a cluster administrator who keeps getting asked "but is it actually locked down," a security engineer embedding into a platform team who needs Kubernetes-native fluency rather than general appsec knowledge. It is a poor fit for anyone who hasn't already internalized CKA-level cluster operation, and the exam's own registration rules enforce that rather than just recommending it.

The format, in full

☺ Like you're 10: Same style as the CKA — real clusters, a terminal, a clock — but the "open book" tab covers a lot less of what you'll actually be asked to do.

Every fact below is what The Linux Foundation and CNCF generally publish and what candidates consistently report as of this writing. As with every certification profile on this site, treat it as a reliable planning baseline, not a locked contract — the warning box further down explains exactly what to verify before you register.

↗ Linux Foundation official CKS page

The six domains and their weights

☺ Like you're 10: Six topics, and together they cover the whole path a piece of software takes — from the image being built to the moment it's caught misbehaving in production.

The CNCF publishes a versioned curriculum for the CKS with six domains that sum to exactly 100%. Unlike the CKA's curriculum, where one domain (Troubleshooting) dominates at 30%, the CKS spreads its weight more evenly across three domains tied at 20% apiece — a sign that no single skill carries the exam and genuine breadth across build, ship, and run is the actual ask.

Two domains reward a closer look because they're where most of the genuinely new material lives for someone coming from CKA. Minimize Microservice Vulnerabilities (20%) covers Pod Security Admission and its restricted/baseline/privileged levels, managing Kubernetes Secrets properly, sandboxed container runtimes like gVisor or Kata for genuinely untrusted multi-tenant workloads, and mTLS between Pods. Supply Chain Security (20%) covers minimizing base-image footprint, allow-listing trusted registries, signing and verifying images before they're permitted to run, and static analysis of manifests and images before they ever reach a cluster — the domain Supply-Chain Security & SBOM already prepares you for better than any other single domain on this exam.

What this course already covers — and the real gap

☺ Like you're 10: You already know a fair bit of the "why we do this" half. The CKS adds the "here's the exact Kubernetes-native command" half on top.

This course's security material was written vendor-neutral or AWS-specific, not Kubernetes-native — so the underlying concepts transfer more than the exact tooling does. Being specific about exactly where that line falls matters, since the CKS grades a live cluster, not whether the concept sounds familiar.

The honest summary: Supply Chain Security is close to a genuine head start, Minimize Microservice Vulnerabilities is a partial one, and Cluster Setup, Cluster Hardening, System Hardening, and Monitoring/Runtime Security are close to a cold start in terms of the exact Kubernetes-native tooling — even where the underlying idea is familiar. The snippet below is a taste of exactly that gap: real syntax for the tools this exam assumes you can already drive.

# Pod Security Admission — label a namespace at the "restricted" level,
# the modern, built-in replacement for the deprecated PodSecurityPolicy
kubectl label namespace payments \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

# kube-bench — CIS benchmark scoring, straight out of the CKS exam environment
kube-bench run --targets node,policies | grep -E '\[FAIL\]'

# cosign — refuse to run an image unless it was signed by a trusted key
cosign verify --key cosign.pub registry.example.com/payments-api:1.4.2

# Falco — a runtime rule catching a shell spawned where one should never appear
- rule: Shell spawned in payments container
  desc: A shell was launched inside a workload that should never need one
  condition: spawned_process and container.image.repository = "payments-api" and proc.name in (bash, sh)
  output: "Shell in payments container (user=%user.name command=%proc.cmdline container=%container.name)"
  priority: WARNING

How to actually prepare for a hands-on security exam

☺ Like you're 10: Reading about hardening doesn't help — you have to break a cluster's security on purpose, then lock it back down, over and over.

Preparation for the CKS looks like CKA preparation with one extra constraint: the open-book allowance covers less of what's actually tested, so more of the tool-specific syntax genuinely has to live in your hands, not in a browser tab you'll open on the day.

• CIS-benchmark a cluster you built yourself. Run kube-bench against a fresh kubeadm cluster, read every [FAIL] line, and fix it — disabling anonymous auth, tightening file permissions on the kubelet config, rotating certificates — until the scan comes back clean. That single loop covers most of Cluster Setup and Cluster Hardening at once.
• Write NetworkPolicies from a blank file, not a template. Start from default-allow, select a Pod, watch it flip to default-deny, then add back exactly the flows it needs — including the DNS egress rule people forget every time.
• Install Falco and actually trigger it. Run the default ruleset, deliberately do something it should catch — spawn a shell in a running container — then write one custom rule from scratch instead of copying an example. The exam won't hand you a working rule; it'll ask you to write one.
• Practice all three Pod Security Admission levels. Deploy a privileged Pod against a restricted namespace and watch it get rejected, then relax the label to baseline and watch the same Pod succeed. Knowing exactly which fields each level blocks, from memory, is faster than looking it up.
• Sign, verify, then tamper. Sign an image with cosign, verify it succeeds, then push a modified image under the same tag and confirm verification actually fails. Trusting that a signing step works because you ran the command once is a bad habit this exam will find.
• Memorize the syntax the allow-list won't cover. Since kube-bench flags, Falco rule fields, Gatekeeper/Kyverno constraint syntax, and AppArmor/seccomp profile formats mostly sit outside the exam's permitted docs, drill them the same way you'd drill vocabulary — not the way you'd study a concept you can look up.

Exam-day logistics and the narrower open-book allow-list

☺ Like you're 10: Same remote-proctoring setup as the CKA, but with less to lean on once the clock starts — most of what you're asked to do isn't in the one allowed tab.

Delivery mirrors the CKA closely — a remotely proctored secure browser, an ID check and room scan before the timer starts, a clear desk, no second monitor, no phone within reach. The meaningful difference is the open-book allowance itself: it's historically been restricted to kubernetes.io/docs and a short list of related official pages, and unlike the CKA, a large share of what's actually tested — Falco, kube-bench, OPA/Gatekeeper, AppArmor, seccomp, image signing — is tooling whose full documentation typically isn't on that list. Read the current Candidate Handbook for the exact allow-list before you sit; it is the single detail on this page most likely to have shifted since it was written, and it's worth knowing precisely which tools you'll be flying without a manual for.

Where CKS sits on the CNCF ladder, and what's next

☺ Like you're 10: It's the top rung of the hands-on Kubernetes ladder — there's nothing above it on this specific path, only sideways moves from here.

Treat the CNCF's certifications as a small floor plan. KCNA sits at the entry, knowledge-based level below everything else. CKA and CKAD sit side by side at practitioner level — same performance-based style, different half of Kubernetes, cluster versus workloads. The CKS sits above both and requires an active CKA specifically, not CKAD, because the security surface it tests — RBAC, the API server, node hardening, cluster-wide admission control — is cluster-administrator territory, not application-developer territory. There is no further CNCF certification above the CKS on this ladder; from here the honest next moves are sideways, not up.

Two sideways moves are worth naming for a DevOps engineer specifically. If the goal is going deeper into platform security as a discipline rather than collecting another badge, Security & Compliance, Compliance as Code & Policy Enforcement, and Supply-Chain Security & SBOM are where the vendor-neutral versions of these ideas live on this platform, beyond what any single exam curriculum covers. If the goal is broader platform ownership rather than a security specialization specifically, From DevOps to Platform Engineering names the bridge to that path directly. Either way, come back to the certifications hub for how CKS compares against the rest of this course's certification shelf.