CKS — Kubernetes Security Specialist

The certifications hub already puts the CKS side by side with the CDP and the AWS Security Specialty exam on one comparison table. This page is what that table can't hold: the full six-domain weighted breakdown, exactly what each domain actually asks you to do on a live cluster, and — because it's the single most consequential fact about this exam — a straight explanation of the hard prerequisite that makes CKS unlike every other certification on this site. You cannot book it, let alone pass it, without an active CKA already in hand.

What the CKS actually is, and the door it won't open without a key

☺ Like you're 10: It's the security sequel to a cluster-admin exam — and you don't get a ticket to see it until you've already sat through, and passed, the first movie.

The Certified Kubernetes Security Specialist is run by the Linux Foundation under the CNCF's certification program — the same body behind the CKA and CKAD. It targets engineers who already operate Kubernetes clusters and now own, or want to own, the security half of that job: hardening the cluster itself, minimizing what a running workload can do if something inside it turns hostile, securing the supply chain that feeds images into the cluster, and building the monitoring that catches whatever gets through anyway. It is entirely performance-based — real command-line tasks against real, live clusters, with no multiple-choice question anywhere in the exam — which puts it in the same assessment family as the CKA and CKAD rather than a knowledge exam like AWS's.

What sets it apart from every other certification covered on this site is the prerequisite. A candidate must hold an active, non-expired CKA certification on the date they sit the CKS exam. This is the only CNCF certification with a formal gate of this kind — KCNA, KCSA, CKAD, and the CKA itself all have no certification prerequisite. The practical effect is that CKS readiness isn't just a study plan; it's a study plan with a hard dependency graph. You cannot shortcut it by being confident, and you cannot buy your way past it — the exam simply cannot be scheduled without a currently valid CKA on file.

Format, cost, and exam-day logistics

☺ Like you're 10: Same shape as the CKA — a real clock, a real terminal, real clusters — just pointed at security tasks instead of admin ones.

The mechanics mirror the CKA closely enough that CKA muscle memory transfers directly: same proctoring model, same terminal-in-a-browser environment, same emphasis on verifying your own work rather than trusting you got it right. What's different is entirely the content of the tasks, not the format they arrive in.

↗ Linux Foundation official CKS page

The six domains, weighted

☺ Like you're 10: Six topics, and unlike the CKA's one giant slice, three of them are tied for the biggest piece of the pie.

These are the six domains and weights as published in the CNCF's CKS exam curriculum. They sum to exactly 100% — 10 + 15 + 15 + 20 + 20 + 20 — and the shape is worth noticing before the content: where the CKA concentrates 30% of its weight on a single domain (Troubleshooting), CKS spreads its heaviest weight across three separate domains tied at 20% each. There is no single dominant topic to over-invest in; the exam expects reasonably even coverage across the whole list.

Listed in official curriculum order, that's Cluster Setup, then Cluster Hardening, then System Hardening, then Minimize Microservice Vulnerabilities, then Supply Chain Security, then Monitoring, Logging and Runtime Security. Regroup those same six domains by when in a cluster's life each one actually applies, though, and a cleaner pattern falls out — one this course's own structure already tracks closely.

Domain by domain: what's actually tested, and where to study it here

☺ Like you're 10: Here's the real work behind each of those six percentages, and the exact page on this site that teaches it.

Cluster Setup — 10%

The smallest domain, and mostly about the cluster's edges rather than its interior. Published competencies cluster around: using network security policies to restrict access at the cluster level; running the CIS Kubernetes Benchmark against the control plane and node configuration; setting up Ingress objects with security controls in place; protecting node metadata and endpoints from being reached by something that shouldn't reach them; minimizing use of, and access to, GUI elements like the Kubernetes Dashboard; and verifying platform binaries before they're ever deployed.

That "minimize GUI access" bullet isn't hypothetical caution — in February 2018, researchers at RedLock found Tesla running an exposed, unauthenticated Kubernetes Dashboard that let attackers reach cloud credentials and run cryptocurrency-mining pods inside Tesla's own cluster. An exposed dashboard is a real, previously-exploited attack surface, not an exam-only concern. The CIS Benchmark check is mechanical and worth running on any cluster you touch:

# kube-bench (Aqua Security) checks raw node config against the CIS Kubernetes Benchmark —
# kubelet flags, file permissions on manifests and certs, etcd's listen address, and more.
kube-bench run --targets=master,node

# a failing check reads like this, with the exact remediation spelled out:
# [FAIL] 1.2.20 Ensure that the --profiling argument is set to false (Automated)
#   Remediation: Edit the API server pod specification file and set --profiling=false

Study here: the "Continuous verification" section of Kubernetes Security Deep Dive covers kube-bench directly; the NetworkPolicy design section on the same page covers cluster-level access restriction. Cloud security posture covers the metadata-endpoint and IAM concerns that sit just outside the cluster boundary. For verifying binaries and images before they deploy, see the signing coverage in Sigstore & cosign.

Cluster Hardening — 15%

Everything here is about the control plane's own front door: restricting access to the Kubernetes API server, using RBAC to minimize what any identity can do once it's authenticated, exercising real caution with service accounts rather than letting every pod inherit the namespace default, and keeping the Kubernetes version itself current against published CVEs.

Study here: this domain maps almost one-to-one onto two sections of Kubernetes Security Deep Dive — the admission-control walkthrough (what governs a write to the API server before it's ever persisted) and, especially, the six-question structured RBAC review for a cluster carrying dozens of service accounts. That review's habit of flagging wildcard rules, high-risk verbs, and every cluster-admin binding by name is close to the exact discipline a live CKS task rewards.

System Hardening — 15%

One layer further out than the cluster itself: the node's own operating system. Minimizing the host OS footprint, minimizing the IAM roles attached to nodes so a compromised pod can't ride a broad node instance profile to cloud-level access, minimizing external network access to the nodes, and appropriately applying kernel-level hardening — AppArmor and seccomp profiles that restrict which syscalls a container is even allowed to attempt.

Study here: the defense-in-depth section of Kubernetes Security Deep Dive places seccomp and AppArmor explicitly as the "continuous, kernel-enforced" layer alongside NetworkPolicy; Container Runtime Security covers the eBPF-based visibility into exactly what a syscall-level control is actually watching. Cloud security posture covers minimizing IAM at the cloud-account layer, which is the same instinct applied one level up from the node.

Minimize Microservice Vulnerabilities — 20%

This domain is about what a workload is allowed to declare and do, not about the cluster or the host underneath it. Published competencies: setting up appropriate OS-level security domains — Pod Security Standards and security contexts — for workloads; managing Kubernetes secrets properly, including encryption at rest; using container runtime sandboxes like gVisor or Kata Containers for genuinely untrusted, multi-tenant workloads; and implementing pod-to-pod encryption with mutual TLS.

# A sandboxed runtime for a workload you don't fully trust — the pod gets its own
# user-space kernel (gVisor) instead of sharing the host kernel directly.
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
apiVersion: v1
kind: Pod
metadata: { name: untrusted-workload }
spec:
  runtimeClassName: gvisor   # opt this one pod into the sandbox; everything else is unaffected
  containers:
    - name: app
      image: registry.internal/app:1.4.2

Study here: the Pod Security Standards section of Kubernetes Security Deep Dive is the direct match for the "security domains" competency — the Baseline-vs-Restricted comparison table there is close to exam-task shape. Secrets management covers the broader discipline of never letting a credential sit somewhere it could be found, including encryption at rest. For pod-to-pod mTLS specifically, the SPIFFE/SPIRE section of Workload Identity & Pipeline IAM covers the same "identity, not a shared secret" pattern applied to service-to-service authentication.

Supply Chain Security — 20%

This is the domain with the cleanest match on this whole site. Published competencies: minimizing base image footprint, securing the supply chain by allowlisting registries and verifying signatures, running static analysis over user workload manifests and Dockerfiles, and scanning images for known vulnerabilities.

Study here: Container & supply-chain security is this domain, nearly section for section — base-image hygiene maps to minimizing footprint, the scanning section maps directly to the vulnerability-scanning competency, and the signing-and-provenance section maps to the "verify signatures" competency. For the tools themselves: Trivy and Syft & Grype for scanning and SBOM generation, Sigstore & cosign for signing and admission-time verification, and Checkov or tfsec for the static-analysis-of-manifests half of the competency.

Monitoring, Logging and Runtime Security — 20%

The last 20% is everything that happens after a workload is already running and every write-time gate has already said yes. Published competencies: performing behavioral analytics to detect malicious activity, detecting threats across the infrastructure, application, network, and workload layers, ensuring the immutability of containers at runtime, and using Kubernetes audit logs to see what actually happened.

# A minimal Kubernetes audit policy — logs full request/response bodies for
# secrets access (high sensitivity), metadata-only for everything else.
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources: [{ group: "", resources: ["secrets"] }]
  - level: Metadata
    omitStages: ["RequestReceived"]

Study here: Container Runtime Security is this domain's technical core — anomalous process execution, unexpected network connections, and privilege escalation are covered as the exact three signal classes eBPF-based tooling watches for. Falco covers the tool most directly tied to the "behavioral analytics" competency, from rule syntax to alert routing. For the "immutability of containers at runtime" competency, the distroless and read-only-root-filesystem coverage in Container & supply-chain security is the design side of the same idea Falco enforces at runtime — no shell in the image means there's nothing to drift with in the first place. Wazuh covers centralizing the audit logs themselves once they leave the cluster.

Who should sit it, and why "not yet" is the right answer for most people

☺ Like you're 10: This test rewards someone who's already been the person paged at 2am for a broken cluster — not someone learning what a Pod is for the first time.

CKS assumes CKA-level cluster fluency is already muscle memory, precisely because the prerequisite guarantees it. That's what frees up the full two hours for pure security tasks — no time is spent testing whether you can bootstrap a cluster or diagnose a stuck Pod, because the CKA already certified that. The right candidate is a platform or security engineer who already runs Kubernetes in production and now owns, or is being asked to own, its security posture: writing the NetworkPolicies, reviewing the RBAC bindings, deciding which images are allowed to run.

Skip it, or at least delay it, if any of these fit. You don't hold an active CKA — this isn't a soft recommendation, it's a hard scheduling block, and no amount of CKS-specific study substitutes for the missing prerequisite. You're new to Kubernetes generally — start with the CKA itself; CKS punishes exactly the gaps a first-time cluster operator is most likely to have. Your organization doesn't run Kubernetes as a primary workload platform — the AWS Certified Security – Specialty exam (compared against CKS on the certifications hub) or a broader credential like the CISSP will track your actual day job more closely than a Kubernetes-specific credential would.

Where CKS sits among the other credentials on this site

☺ Like you're 10: It's not a standalone badge — it's the second half of a two-part story that starts with a different exam entirely.

Within the CNCF's own ladder, CKS sits directly above the CKA — not beside it, above it, because it cannot be attempted without it. Where the CKA proves you can run a cluster, CKS proves you can secure one you're already qualified to run; treat them as one two-part credential rather than two independent choices, and plan to sit the CKA first with CKS deliberately queued up next, not as an alternative to consider instead. Outside the Kubernetes-specific ladder, the certifications hub lays out how CKS compares to the Certified DevSecOps Professional and the AWS Certified Security – Specialty exam on assessment style and scope; if your work spans more than Kubernetes alone, that three-way comparison is the better starting page.