CKS — the exam

The CKS — Certified Kubernetes Security Specialist — sits at the top of this course's five-exam ladder, and it's the only one of the five with a hard prerequisite: you cannot even register without an active, non-expired CKA already in hand. It's performance-based, roughly two hours, dropped onto live clusters with a list of hardening and incident-response tasks graded purely on the cluster state you leave behind — no multiple choice, no credit for describing the right answer instead of typing it. Where the CKA asks whether you can operate a cluster and the CKAD asks whether you can ship an application onto one, the CKS asks a meaner question: can you keep a cluster safe once somebody is actively trying to break it? This page is the CKS hub for this course — the prerequisite explained clearly, the CNCF's official six-domain breakdown from curriculum v1.34, worked examples for the two domains people most often underprepare, and where to go next inside this course to actually drill it.

What the CKS actually tests, and why it's the hardest badge on this ladder

☺ Like you're 10: It's a hands-on test on real clusters where you fix real security holes — and it's the hardest of the five because you have to already hold a different badge first.

The CKS is a performance-based exam from the CNCF and The Linux Foundation, in the same family as the CKA and CKAD. You get a remote desktop, several live clusters, and a list of tasks: restrict a namespace with a NetworkPolicy, fix an over-permissive Role, make a Pod run unprivileged with a seccomp profile, find the image with the critical CVE, turn on audit logging with the right policy, read a runtime alert and stop the workload that caused it. There is nothing to memorize in the multiple-choice sense — the grading script inspects the resulting objects after your session ends, and an elegant approach earns nothing extra over a correct one.

Its centre of gravity is different from both exams below it. The CKA is about operating the cluster; the CKAD is about authoring workloads inside a namespace someone else administers. CKS assumes you can already do both, then asks whether you can defend the result. Nearly every CKS task presumes fluency you were already tested on: switching contexts without hesitation, editing a static Pod manifest on a control-plane node, restarting a component and reading its logs. The exam clock does not budget time for re-learning kubectl.

Who should sit it

• Cluster operators and SREs who already hold a CKA and own the guardrails a cluster runs behind — RBAC, admission, network policy, the audit trail.
• Platform and security engineers who need the Kubernetes-specific mechanics behind supply-chain and runtime controls they're already responsible for in the abstract.
• Anyone completing the ladder — CKS is one of the five certifications required for Kubestronaut, alongside KCNA, KCSA, CKA and CKAD.
• Consultants and contractors for whom a hardening credential is often a procurement checkbox before they're allowed near a production cluster.

What it deliberately does not test

Not application authoring — Deployments, probes, ConfigMaps and the rest of the object model a developer touches daily belong to CKAD, and CKS assumes you already know it well enough not to be slowed down by it. Not first-time cluster bootstrapping either — kubeadm, node lifecycle and the base RBAC model are the CKA's territory, covered in this course's five-part Exam Blueprint, and CKS builds directly on top of it rather than re-testing it. What's left, once you subtract both, is exactly the six domains below: everything between "the cluster works" and "the cluster is safe."

The one hard prerequisite: an active, non-expired CKA

☺ Like you're 10: You're not allowed to even sign up for this test unless you've already passed the other one, and it has to still be valid — not expired.

This is the detail that catches people out, so it's worth being blunt about it: the CKS is the only certification in the Kubernetes family with a formal, enforced gate. Not "recommended," not "helps" — checked at registration. You must hold a current CKA whose validity window has not lapsed. If yours has expired, or is about to, the practical fix is to renew or re-sit the CKA first — this course's CKA Study Plan is the place to start that clock again — and then book the CKS once it's current. Plenty of candidates plan the two together deliberately: pass the CKA, and while the material is still fresh, spend the next few months on the hardening layer before the CKA's two-year validity has any chance of becoming a problem.

The reasoning behind the gate is worth internalizing rather than resenting: CKS tasks routinely hand you a broken cluster and expect the CKA-level operational moves — editing a static manifest, restarting kube-apiserver, reading its logs for a syntax error — as a precondition to the security work, not as something the exam re-teaches you along the way.

The official CKS domains — CNCF curriculum v1.34

☺ Like you're 10: The test is split into six parts, and they're not equal — half the marks live in just three of them.

Transcribed from the CNCF's published CKS Exam Curriculum, version 1.34: six domains, weights summing to exactly 15 + 15 + 10 + 20 + 20 + 20 = 100%. If a study guide you're reading doesn't add up to exactly 100, it's out of date or misquoting. Bars below are sorted by weight; the domain sections that follow keep the curriculum's own order and wording.

Domain by domain: what you actually have to produce

☺ Like you're 10: Here's the real substance for each part of the test — the files you'd actually have to write, not just the topic names.

The gap between "I've read about this" and "I can do this in six minutes on a live cluster" is where the CKS lives. This course already has dedicated pages for most of the mechanics below — the sections here focus on what's specific to how the exam frames each domain, with links out for the full depth.

Cluster Setup & Cluster Hardening — the platform's own bones (15% + 15%)

Cluster Setup is mostly NetworkPolicy and CIS compliance. Know that policies are additive and deny-by-default the moment a Pod is selected by any policy, and that an empty podSelector: {} means "every Pod in this namespace" — this course's Networking & the CNI and Security: Defense in Depth cover the mechanics and the classic default-deny-then-one-allow-rule pattern in full, so it isn't repeated here. Add kube-bench for CIS benchmark checks against etcd, the kubelet and the API server; the notorious findings are kubelet anonymous auth left on, --profiling=false missing, and etcd running without client-certificate auth. Ingress TLS is a kubernetes.io/tls Secret referenced from a tls: block — see ingress-nginx and cert-manager. Protecting node metadata means blocking Pod egress to the cloud metadata endpoint (commonly 169.254.169.254) so a compromised Pod can't lift the node's cloud credentials — and verifying platform binaries means checking published checksums before you ever run an unfamiliar kubectl or kubelet build.

Cluster Hardening is RBAC and ServiceAccounts examined from the attacker's side. This course's RBAC & Admission Control covers Roles, ClusterRoles and the admission pipeline in depth; the exam-specific twist is the ServiceAccount competency's exact wording — disable the defaults. Set automountServiceAccountToken: false on any Pod that never calls the API server, because a mounted token sitting in the container filesystem is a credential waiting to be read off disk. Restricting API access means no anonymous auth, no wildcard RoleBindings, and nothing bound to system:masters that doesn't need to be there. Upgrading to avoid CVEs is kubeadm upgrade plan / apply then a careful drain-and-upgrade per node — the same operational muscle the CKA blueprint already drilled, re-examined here as vulnerability management rather than routine maintenance.

System Hardening — the layer underneath the kubelet (10%)

The smallest domain by weight, and the one candidates most often treat as an afterthought. Minimizing the host OS footprint means fewer packages, fewer running services, fewer open ports on every node — a smaller thing for an attacker who does land on a node to work with. Least-privilege IAM applies the same principle to the node's own cloud identity: a node role that can read from one bucket shouldn't also be able to write to every bucket in the account. Minimizing external network access is node-level egress control, the same instinct as node-metadata protection above but applied broadly. And the two kernel tools the curriculum names explicitly — seccomp and AppArmor — restrict which syscalls and file paths a container can touch even if something inside it is compromised; see the worked seccompProfile field in the next section, and DevSecOps's Kubernetes Security Deep Dive for the full defense-in-depth layering these controls sit inside.

Minimizing microservice vulnerabilities — a namespace and a restricted Pod (20%)

PodSecurityPolicy is gone; its replacement is Pod Security Admission — three labels on a Namespace, three standards (privileged, baseline, restricted), and three modes (enforce rejects, audit writes to the audit log, warn messages the user at apply time). This course's RBAC & Admission Control covers PSA's place in the admission pipeline; here's the artifact you should be able to produce from memory — a namespace enforcing restricted, and a Pod that actually satisfies it:

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted   # catches near-misses before they're rejected
---
apiVersion: v1
kind: Pod
metadata:
  name: ledger-api
  namespace: payments
spec:
  automountServiceAccountToken: false        # ServiceAccounts: disable the default
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    seccompProfile:
      type: RuntimeDefault                   # System Hardening's seccomp competency, in practice
  containers:
    - name: api
      image: registry.internal/ledger-api@sha256:9f2c...   # digest, not a mutable tag
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        privileged: false
        capabilities:
          drop: ["ALL"]

Every field above is something restricted rejects if it's missing — apply this to a namespace labeled enforce: restricted without one of them and read the rejection message; it names exactly what's wrong. Beyond PSA, this domain also covers Secrets management — remember a Kubernetes Secret is base64, not encryption, so the real controls are etcd encryption at rest and tight RBAC on the secrets resource, covered further in the sibling Platform Engineering course's Secrets & Workload Identity page — isolation techniques, where a sandboxed runtime like gVisor or Kata is selected per-Pod with a RuntimeClass for genuinely untrusted workloads, and pod-to-pod encryption via Cilium's transparent encryption or Istio mTLS in STRICT mode.

Supply chain security — from base image to a gate that actually checks (20%)

Walk this domain as a pipeline. Start from a minimal base image (distroless or scratch) to shrink what a scanner even has to look at. Generate an SBOM and scan for CVEs — the sibling DevSecOps course's Trivy guide covers both in depth. Statically analyse the manifest itself with Kubesec or KubeLinter, looking for the same missing fields the worked Pod above already sets. Sign the artifact with cosign before it ever reaches a permitted registry:

# sign keylessly, tying the signature to a specific CI identity
cosign sign registry.internal/ledger-api@sha256:9f2c...

# verify — pin the identity; a wildcard '.*' accepts anyone's signature
cosign verify --certificate-identity-regexp '^https://github\.com/acme/.+' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  registry.internal/ledger-api@sha256:9f2c...

None of that matters if the cluster doesn't enforce it — the last mile is an admission-time gate, and the curriculum expects you to recognize the shape even if it doesn't demand a full policy engine's syntax from memory. At a light level, a permitted-registry-plus-signature gate looks like this:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: supply-chain-gate
spec:
  validationFailureAction: Enforce
  rules:
    - name: only-permitted-registry
      match: { any: [{ resources: { kinds: [Pod] } }] }
      validate:
        message: "Images must come from registry.internal"
        pattern:
          spec: { containers: [{ image: "registry.internal/*" }] }
    - name: images-must-be-signed
      match: { any: [{ resources: { kinds: [Pod] } }] }
      verifyImages:
        - imageReferences: ["registry.internal/*"]
          attestors: [{ entries: [{ keyless: { issuer: "https://token.actions.githubusercontent.com" } }] }]

Treat that as the shape to recognize, not a syntax to have memorized cold — this course keeps admission-controller depth deliberately light, since it isn't itself on the CKS curriculum's tool list by name. The sibling Golden Astronaut course covers Kyverno and OPA Gatekeeper as full project certifications in their own right, and DevSecOps's Kyverno guide goes considerably deeper into rule authoring if you want hands-on practice before exam day.

Monitoring, logging and runtime security — catching what got through (20%)

Prevention fails eventually, so the last fifth of the exam is detection. Behavioral analytics and attack-phase identification mean reading an alert and being able to say which stage of an intrusion you're looking at — reconnaissance, initial access, privilege escalation, exfiltration — rather than just "something's wrong." Container immutability at runtime is largely a restatement of the worked Pod above: readOnlyRootFilesystem: true, no shell or package manager baked into the image, deploy by digest rather than a mutable tag, and treat any container modified in place as compromised — replace it, don't patch it live. Kubernetes audit logs round the domain out: an audit Policy resource wired into the API server via --audit-policy-file, with four levels (None, Metadata, Request, RequestResponse) evaluated first-match-wins — which is exactly what lets you log Secrets access at Metadata only, while capturing full RBAC changes:

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages: ["RequestReceived"]
rules:
  - level: Metadata          # who touched it, never the payload
    resources: [{ group: "", resources: ["secrets", "configmaps"] }]
  - level: RequestResponse   # RBAC changes are the classic escalation path — keep the whole object
    resources: [{ group: "rbac.authorization.k8s.io", resources: ["roles", "rolebindings"] }]
  - level: Metadata           # everything else in the cluster

Behavioral detection tooling like Falco sits on top of this, watching syscalls in real time rather than the API server's request log — see the sibling DevSecOps course's Falco guide for rule authoring, and Kubernetes Security Deep Dive's "continuous verification" section for how benchmarks, drift detection and this runtime backstop fit together as one layered system.

Exam logistics — confirm every number before you book

☺ Like you're 10: Here's roughly how test day works — but the exact rules and prices change, so check the official page before you pay for anything.

What follows reflects the exam as commonly documented at the time of writing. It is orientation, not a contract, and where it disagrees with the official page, the official page is right and this one is stale.

How to prepare using this course

☺ Like you're 10: There's already a page here for almost everything on the test — this is the short list of where to start.

Read How to Study for a CNCF Exam first for the general method, then work this exam's own pages: CKS Study Plan for a full week-by-week schedule sized to the domain weights above, CKS Practice Tasks for graded reps, and Mock Exam · Set 1 and Set 2 for full timed runs. Capstone Part 5 — Security & RBAC is where the worked Pod above stops being something you read and starts being something you write against a real cluster, and Drill — Harden an RBAC Configuration drills the Cluster Hardening domain specifically. Keep a running list of anything that trips you up in Field Notes, and use the glossary whenever a term above doesn't fully click.