CKS Study Guide 2026: Pass Certified Kubernetes Security Specialist

The CKS is where Kubernetes careers level up. It is the cert that tells employers you do not just run clusters — you secure them against real-world threats. This guide gives you the 5-week plan, the exact tools, and the exam-day decisions that move a prepared candidate from nervous to confident on test day.

Why CKS Is the CNCF's Hardest — and Most Valuable — Cert

Kubernetes security incidents are expensive. The 2024 CNCF survey found that runtime threats, misconfigured RBAC, and vulnerable container images were the top three root causes of production security events in cloud-native environments. Organisations are willing to pay a premium for engineers who can close those gaps at the cluster level, not just at the application level.

The CKS is the only vendor-neutral, performance-based certification focused entirely on securing a running Kubernetes cluster. It sits above CKA on the CNCF certification ladder and requires you to hold an active CKA as a prerequisite — a signal that you already understand cluster administration before you touch the security layer. The result is a credential that hiring managers at cloud-native shops treat as a genuine differentiator, not a box-tick.

In 2026, certified CKS holders in the US are tracking $140,000–$185,000 in total compensation depending on seniority and region. That is typically 15–25% above an equivalent engineer holding only a CKA. The exam costs $445 with one free retake and two killer.sh simulator attempts included, making it one of the strongest ROI certs in the cloud-native space.

To see how CKS compares to the rest of the Kubernetes cert family, read our Kubernetes Certifications Guide. To understand the CKA → CKS progression in detail, see our CKA Study Guide.

Prerequisite & Exam Format

The CKA Prerequisite

An active, unexpired CKA is a hard prerequisite for the CKS. Linux Foundation enforces this at registration. If your CKA has lapsed or you have not taken it, you cannot book the CKS — no exceptions. The CKA is valid for two years from the date of passing; check your certificate expiry in the Linux Foundation portal before you plan your CKS study schedule.

Exam Format

The CKS is a 2-hour, performance-based exam delivered via PSI's online proctoring platform. You work directly on real Kubernetes clusters in a remote Linux terminal — there are no multiple-choice questions. Expect approximately 15–16 tasks across the six security domains, each carrying a listed weight (typically 4–13%).

The pass mark is 67%. That is 2 percentage points higher than the CKA's 66%, and the domain content is harder. Linux Foundation publishes per-task weights at the start of each item, so you can make strategic skip decisions in real time.

The exam runs on Kubernetes v1.30+ in 2026. Verify the exact version on the official exam handbook before booking, as Linux Foundation updates the curriculum each K8s release cycle. You get one allowed browser tab pointed at kubernetes.io/docs, kubernetes.io/blog, and github.com/kubernetes. No local notes. No second monitor. Room setup matters — a proctor will fail you for environment violations before you type a single command.

Included with your $445 registration: one free retake within 12 months and two killer.sh simulator attempts. Killer.sh runs 15–20% harder than the real exam, so treat it as a calibration tool, not a pass/fail signal.

The 6 CKS Domains, Weighted

Study time allocation should mirror domain weight. Here are all six domains with the 2026 curriculum percentages and the most-tested subtopics inside each.

1. Cluster Setup — 10%

Covers CIS Kubernetes Benchmark hardening with kube-bench, network policies for a default-deny posture, TLS configuration for API server ingress, GUI (dashboard) access controls, and verifying platform binaries with SHA checksums. Smallest domain by weight but a frequent source of easy points: the tasks tend to be formulaic once you have practised the exact command syntax.

2. Cluster Hardening — 15%

RBAC least-privilege design (Roles, ClusterRoles, RoleBindings, ServiceAccounts), restricting API server access, upgrading Kubernetes to the latest supported version, and disabling anonymous authentication. Overlaps heavily with the CKA curriculum, which is why holding a fresh CKA is such an advantage — your RBAC muscle memory carries over.

3. System Hardening — 15%

OS-level attack surface reduction: minimising host OS footprint, limiting container syscall profiles with seccomp (runtime/default and custom profiles), enforcing mandatory access control with AppArmor (loading profiles, annotating pods), and restricting kernel capabilities with securityContext.capabilities.drop. Expect at least one task requiring you to apply an AppArmor profile to a running pod without restarting the entire deployment.

4. Minimize Microservice Vulnerabilities — 20%

The widest "defence in depth" domain. Key topics: Pod Security Standards (Privileged / Baseline / Restricted) and Pod Security Admission controller configuration, OPA Gatekeeper or Kyverno policies for admission control, management of Secrets (encryption at rest, avoid env-var exposure), container sandboxing with gVisor (runsc) or Kata Containers, and multi-tenancy patterns. This domain rewards candidates who understand why a control exists, not just how to apply it.

5. Supply Chain Security — 20%

Image security from build to runtime: minimise base image attack surface, scan images with Trivy for CVEs and misconfigurations, enforce admission policies that block images from untrusted registries, sign and verify images with Cosign / Notary, and secure the image build pipeline (Dockerfile best practices: non-root user, minimal layers, no secrets baked in). Tied with Microservice Vulnerabilities as the heaviest domain.

6. Monitoring, Logging, and Runtime Security — 20%

Behavioural threat detection at runtime using Falco (writing custom rules, interpreting alerts), Kubernetes audit logging (configuring audit policy files, identifying suspicious API calls), immutable container filesystems, and using kubectl exec forensics responsibly. Falco is the centrepiece of this domain — you will almost certainly be asked to write or modify a Falco rule.

5-Week Study Plan

Five weeks at 12–15 hours per week. Engineers who cleared CKA recently can compress to 4 weeks. Those who have been away from K8s hands-on work for more than 6 months should budget 6–7 weeks.

Week 1: Cluster Setup & Cluster Hardening (Domains 1–2)

Start by rebuilding your lab cluster from the CKA days — a two-node kind or kubeadm cluster works well. Run kube-bench against it and read every FAIL line. Fix the low-hanging failures manually so you understand what each control does. Practice RBAC from scratch: ServiceAccount → Role → RoleBinding → verify with kubectl auth can-i --as=system:serviceaccount:<ns>:<sa>. Disable anonymous access to the API server and verify with curl. By end of week you should be able to score a clean kube-bench run from memory.

Week 2: System Hardening (Domain 3)

AppArmor and seccomp are the highest-friction topics for candidates with a pure Kubernetes background (as opposed to a Linux/sysadmin background). Spend two days on AppArmor alone: load a custom profile with apparmor_parser, verify it is loaded with aa-status, and annotate a pod to enforce it. Then do seccomp: apply runtime/default to a pod via securityContext.seccompProfile, then create a custom JSON profile and mount it. Finally, practice securityContext.capabilities.drop: ["ALL"] and only adding back the minimum required capability. These three controls appear together frequently on the real exam as a single task.

Week 3: Microservice Vulnerabilities (Domain 4)

Pod Security Standards are the foundation. Configure a namespace with pod-security.kubernetes.io/enforce: restricted and observe what breaks. Fix the broken pods by adding the required securityContext fields. Then move to OPA Gatekeeper or Kyverno: deploy one of them, write a policy that blocks images without a digest, and test it with a non-compliant pod. Practice Secrets encryption at rest by configuring an EncryptionConfiguration resource on the API server. Finish with a gVisor lab: install runsc, create a RuntimeClass, and run a pod with it.

Week 4: Supply Chain Security (Domain 5)

Image scanning is the core skill. Practice trivy image <image> --severity HIGH,CRITICAL, understand the output, and write an admission policy that blocks images with critical CVEs. Write a Dockerfile that follows best practices: non-root USER, no secrets in ENV/ARG, multi-stage build to minimise layer count. Practice image signing with cosign sign and verification with cosign verify. Set up an ImagePolicyWebhook (or equivalent Kyverno policy) that enforces registry allowlists. By end of week you should be able to build, scan, sign, and enforce a secure image pipeline from memory. Supplement with the Kubernetes security best practices post for reinforcement.

Week 5: Runtime Security + Killer.sh + Weak-Area Polish (Domain 6)

Falco deserves three dedicated days. Install it in your cluster, read the default rules file, and then write custom rules for realistic scenarios: "alert when a shell is spawned inside a container," "alert when /etc/passwd is read." Practice editing /etc/falco/falco_rules.local.yaml and reloading without a full restart. Then configure an API server audit policy: write a Policy object that logs Secrets access at the Request level and filters noise from system components. On day 4, burn your first killer.sh attempt under real exam conditions — 2 hours, single monitor, no notes. Score honestly; the simulator runs harder than the real exam. Spend day 5 patching the three weakest areas you identified. Save your second killer.sh attempt for 48 hours before your actual exam date.

Must-Know Security Tools

The CKS is a tools exam as much as a concepts exam. Know each of these from the command line without referring to the docs.

kube-bench

Runs the CIS Kubernetes Benchmark checks against your cluster components. Install it on a node, run kube-bench run --targets=master or --targets=node, and read the FAIL output. Each finding maps to a specific kubelet or API server flag you can add to the component manifest or service config. The exam may ask you to fix a specific failing check rather than run kube-bench itself — but knowing the tool tells you which flag to set.

Falco

The runtime security engine that watches syscalls and Kubernetes API events against a rule set. Key files: /etc/falco/falco.yaml (output channels, engine config), /etc/falco/falco_rules.yaml (built-in rules, do not edit), /etc/falco/falco_rules.local.yaml (your custom rules, this is where exam edits go). A Falco rule has four required fields: rule, desc, condition, output, and one optional priority. Practice writing conditions using Falco's filter language (evt.type, container.id, fd.name, proc.name).

Trivy

Image and config scanner by Aqua Security. For the exam: trivy image <image>:<tag> (basic scan), trivy image --severity CRITICAL <image> (filter by severity), trivy fs /path (filesystem scan), trivy k8s --report summary cluster (cluster-wide scan). Know how to interpret CVE output and which fields (CVE ID, severity, fixed version) are relevant to an admission decision.

AppArmor

Linux mandatory access control system that confines processes to a declared profile. Exam workflow: write or receive a profile, load it with apparmor_parser -r -W /path/to/profile, verify it is loaded with aa-status | grep <profile-name>, annotate the pod spec with container.apparmor.security.beta.kubernetes.io/<container-name>: localhost/<profile-name>. Know the difference between enforce and complain mode.

seccomp

Linux syscall filter mechanism. Two exam patterns: (1) apply the runtime default profile via securityContext.seccompProfile.type: RuntimeDefault — this blocks ~100 syscalls with zero configuration; (2) apply a custom JSON profile mounted as a hostPath volume and referenced via type: Localhost, localhostProfile: profiles/my-profile.json. The custom profile JSON structure: {"defaultAction":"SCMP_ACT_ERRNO","syscalls":[...]}.

OPA Gatekeeper / Kyverno

Admission controllers that enforce policy-as-code. OPA Gatekeeper uses Rego-based ConstraintTemplates + Constraints. Kyverno uses YAML ClusterPolicies. For the exam, know how to deploy the chosen engine, write a simple deny policy (e.g., block privileged containers, enforce image digest), and verify it blocks a non-compliant pod with a clear rejection message. Kyverno's syntax is more K8s-native and easier to write under time pressure; OPA Gatekeeper is more powerful for complex Rego logic.

NetworkPolicy (default-deny)

The foundational network security primitive in Kubernetes. A complete default-deny posture requires two policies in every namespace: one that selects all pods and denies all ingress, and one that selects all pods and denies all egress. Then add targeted allow policies for legitimate traffic. Know the podSelector, namespaceSelector, ipBlock, and ports fields cold — they appear in almost every CKS network task. See our CKS exam tips for more NetworkPolicy patterns.

Exam-Day Strategy

The CKS is won on efficiency, not just knowledge. Here is the playbook for the 2-hour window.

• Set up aliases in the first 60 seconds. alias k=kubectl, complete -F __start_kubectl k, export do='--dry-run=client -o yaml', export now='--grace-period=0 --force'. Add to ~/.vimrc: set nu et ts=2 sw=2 ai. These carry through the whole exam and save minutes over 15+ tasks.
• Switch context before every task. Each task header lists the cluster context. Run kubectl config use-context <context> before typing anything else. Working in the wrong cluster is the silent score-killer.
• Read all tasks first (5 minutes). Note the weight on each. Flag any task that looks like a 20-minute rabbit hole. A 4% task is not worth losing a 12% one to the clock.
• Do not skip the verification step. After every task: k get, k describe, aa-status, trivy image, or whatever confirms your change is live. Takes 10 seconds and catches mistakes before the proctor grades them.
• Cap debugging at 10 minutes per task. If you are stuck, mark it, move on, come back with fresh eyes. A partial answer (correct namespace, correct resource type, wrong flag) may still earn partial credit.
• Save 15 minutes at the end for flagged tasks and a final verification sweep. The last 15 minutes of the CKS are worth more than the first 15 — you have context, you have tools set up, you are not cold-starting.
• Know your Falco reload command cold. systemctl restart falco or kill -1 $(pidof falco) for a hot reload. Writing a correct rule that never takes effect because you forgot to reload is a painful way to drop 8%.

Most-Failed CKS Topics

Based on post-exam community debriefs, these are the traps that bite even prepared candidates.

• AppArmor annotation syntax. The annotation key format is container.apparmor.security.beta.kubernetes.io/<container-name> — the container name, not the pod name. Missing or misspelling the container name means the profile silently does not apply.
• Falco rule condition syntax. The filter language looks easy but has strict field name conventions. evt.type=execve and proc.name!=sh — any typo gives a false-negative rule that logs nothing. Practice writing rules from scratch, not copy-pasting.
• seccomp profile path. Custom profiles must be placed on every node in /var/lib/kubelet/seccomp/ (or the path configured in the kubelet). Forgetting the node-level step means the pod stays in a pending/error state and the task gets zero credit.
• Pod Security Standards — enforce vs warn vs audit. Candidates often set the wrong mode. enforce blocks non-compliant pods outright; audit and warn do not. Read the task description carefully to determine which label to use.
• Trivy output interpretation. The exam may ask you to identify whether a specific image is safe to deploy based on a Trivy scan result. Know the difference between UNKNOWN, LOW, MEDIUM, HIGH, and CRITICAL severities and how to filter with --severity.
• Audit policy levels. The four levels are None, Metadata, Request, and RequestResponse. Confusing Request (logs request body) with RequestResponse (logs both request and response body) is a common exam mistake that results in an audit policy that technically works but captures the wrong data.

Resources & Next Steps

The shortlist that actually works in 2026:

• Killer Shell CKS course (Kim Wuestkamp) — the most comprehensive CKS-specific video course. Covers every domain with live cluster labs.
• killer.sh simulator — two attempts ship with your exam fee. Take the first at the end of week 4, the second 48 hours before exam day.
• Falco documentation — falco.org/docs. Read the rule syntax reference and the syscall filter field list before exam week.
• CIS Kubernetes Benchmark — free PDF from cisecurity.org. Skim it once to understand what kube-bench is actually checking.
• ExamCert CKS practice — our free CKS scenario questions cover all six domains and update with the curriculum each K8s cycle.
• Companion reading — CKS exam tips (pass first attempt), Kubernetes security best practices for CKS, and CKA practice questions 2026 for prerequisite reinforcement.
• What comes next — after CKS, consider the KCSA (Kubernetes and Cloud Native Security Associate) if you want a broader cloud security credential, or focus on specialisation in Falco/OPA to deepen the security engineering track.

Frequently Asked Questions

Do I need CKA before CKS?

Yes. An active CKA certification is a hard prerequisite for the CKS. You must hold a valid, unexpired CKA before Linux Foundation will let you register for the CKS exam. If your CKA has lapsed, you must renew it first. See our CKA Study Guide 2026 to get (back) to CKA-ready.

How hard is the CKS exam?

The CKS is widely regarded as the hardest CNCF certification. It is a 2-hour, performance-based exam with ~15–16 hands-on tasks, a 67% pass mark, and heavy time pressure. Candidates who cleared CKA on their first attempt typically need 4–6 additional weeks of focused security study to pass CKS. The difficulty comes from the breadth of tools (Falco, Trivy, AppArmor, seccomp, OPA, Kyverno) and the precision required — a single wrong annotation or misspelled rule condition costs full task credit.

How much does the CKS cost in 2026?

$445 USD via the Linux Foundation, which includes one free retake within 12 months and two killer.sh simulator attempts. Bundle deals with CKA are sometimes offered at a discount — check the Linux Foundation store before buying separately.

What tools must I know for the CKS exam?

The most critical tools are: kube-bench (CIS benchmark auditing), Falco (runtime threat detection), Trivy (image vulnerability scanning), AppArmor and seccomp (OS-level syscall/profile restriction), OPA Gatekeeper or Kyverno (admission policy), and NetworkPolicy manifests for default-deny posture. Know how to apply and verify each one from the command line without referring to docs.

What Kubernetes version is used on the CKS exam?

K8s v1.30+ in 2026. Linux Foundation updates the curriculum each release cycle, so verify the exact version on the official exam handbook before you book your seat.