Skip to main content
CNCF 🇺🇸 · 5 min read

How to Pass CKS (Certified Kubernetes Security Specialist) in 2026: Complete Study Guide

CKS is the hardest Kubernetes certification — requires an active CKA and tests hands-on security hardening under time pressure. This guide covers all 6 domains, essential tools (Falco, OPA Gatekeeper, Trivy, AppArmor), and a 10-week study plan built on top of CKA knowledge.

The Certified Kubernetes Security Specialist (CKS) is the most demanding of the three CNCF Kubernetes certifications. Unlike the CKA and CKAD, CKS requires you to hold an active CKA before you can register — and its content assumes you are already comfortable with cluster administration. The exam does not test whether you can run a cluster; it tests whether you can harden one against real attack vectors, using tools like Falco, OPA Gatekeeper, Trivy, AppArmor, and Kubernetes native security primitives. If you underestimate it, you will fail with a solid Kubernetes background. This guide covers everything you need to approach CKS systematically.

Why CKS Is the Hardest Kubernetes Certification

Three factors combine to make CKS significantly harder than CKA:

  • Security hardening under time pressure. CKS tasks require you to configure AppArmor profiles, write Falco rules, apply OPA Gatekeeper constraints, and tune audit logging — all in a live cluster with a 2-hour timer. These are not things you can wing.
  • New tooling that has no equivalent in CKA. Falco, Trivy, Cosign, OPA Gatekeeper, and seccomp profiles are CKS-specific. Candidates who pass CKA and immediately attempt CKS without studying this tooling will fail the supply chain and runtime security tasks.
  • The configuration details are unforgiving. A Falco rule in the wrong file is silently ignored. An AppArmor profile not loaded on the target node causes a pod to fail with an error. An OPA Gatekeeper constraint with enforcementAction: audit instead of deny will not block anything. The exam checks outcomes, not effort.

What CKA Knowledge Transfers to CKS

If you have a current CKA, you bring significant relevant knowledge into CKS. These skills transfer directly:

  • RBAC — CKS goes deeper on RBAC hardening (least privilege, service account restrictions, role aggregation)
  • NetworkPolicy — CKS uses it more aggressively for segmentation and egress control
  • Static pod manifests at /etc/kubernetes/manifests/ — CKS tasks modify kube-apiserver flags here
  • kubectl proficiency — all the same command patterns apply
  • Troubleshooting sequence — same node → control plane → kubelet order

What is new in CKS: supply chain security tools (Trivy, Cosign), runtime threat detection (Falco), policy enforcement (OPA Gatekeeper), Pod Security Standards, seccomp and AppArmor profiles, and Kubernetes audit logging.

The 6 CKS Domains

Domain 1: Cluster Setup (15%)

Focuses on securing the cluster's network perimeter and API access. Key topics and tools:

  • NetworkPolicy — default-deny all ingress/egress; then explicitly allow only what is needed
  • Ingress with TLS — TLS termination at Ingress, certificate management
  • CIS Benchmark hardening — kube-apiserver flags: --anonymous-auth=false, --authorization-mode=RBAC,Node, --audit-log-path, --encryption-provider-config
  • Secrets encryption at rest — EncryptionConfiguration resource; AES-CBC or AES-GCM providers

Domain 2: Cluster Hardening (15%)

Focuses on RBAC and service account controls. Key topics:

  • RBAC — principle of least privilege; audit existing ClusterRoleBindings; remove cluster-admin where not needed
  • Service account tokens — disable auto-mounting with automountServiceAccountToken: false at pod or ServiceAccount level; use projected volumes with expiry instead of long-lived tokens
  • API server access controls — NodeRestriction admission plugin; disabling insecure port

Domain 3: System Hardening (10%)

Focuses on OS-level security primitives. Key topics:

  • AppArmor — load profiles with apparmor_parser; apply to pods via annotations; verify with aa-status
  • seccompRuntimeDefault for standard syscall filtering; Localhost for custom profiles; applied via securityContext.seccompProfile
  • Reduce attack surface — disable unnecessary kernel modules; remove unused packages; restrict host path mounts

Domain 4: Minimize Microservice Vulnerabilities (20%)

Focuses on pod-level security controls and policy enforcement. Key topics:

  • Pod Security Standards (PSS) — three levels: Privileged / Baseline / Restricted; applied as namespace labels
  • OPA Gatekeeper — ConstraintTemplate with Rego policy; Constraint objects that enforce the template; enforcementAction: deny to block vs audit to log
  • SecurityContextrunAsNonRoot, readOnlyRootFilesystem, capabilities.drop: ["ALL"], allowPrivilegeEscalation: false
  • Secrets — prefer projected volumes over environment variables; rotate regularly

Domain 5: Supply Chain Security (20%)

Focuses on securing the container image pipeline. Key topics:

  • Trivy — scan images for CVEs: trivy image --severity CRITICAL,HIGH image:tag; scan filesystems; integrate into CI/CD
  • Cosign — sign images: cosign sign --key cosign.key image:tag; verify signatures: cosign verify --key cosign.pub image:tag
  • ImagePolicyWebhook — enforce image policies at admission time; require signed or scanned images
  • Dockerfile security — use non-root USER; multi-stage builds; minimal base images

Domain 6: Monitoring, Logging, and Runtime Security (20%)

Focuses on detecting threats in running clusters. Key topics:

  • Falco — real-time syscall-based threat detection; custom rules; alert on privileged containers, shell spawns, file access
  • Kubernetes audit logging — audit policy levels (None/Metadata/Request/RequestResponse); kube-apiserver flags; reading audit log output
  • Behavioral anomaly detection — detecting container escapes, privilege escalation, unexpected network connections

10-Week CKS Study Plan

Weeks Focus Activities
1–2 Refresh CKA + RBAC deep dive Re-do CKA practice tasks; RBAC least privilege labs; NetworkPolicy default-deny exercises
3–4 Cluster hardening + Pod Security kube-apiserver flags; service account token settings; Pod Security Standards enforcement; SecurityContext all fields
5–6 System hardening + OPA Gatekeeper AppArmor profile loading and annotation; seccomp RuntimeDefault/Localhost; OPA Gatekeeper ConstraintTemplate writing in Rego
7–8 Supply chain + runtime security Trivy scanning commands; Cosign sign/verify; Falco rule syntax; custom Falco rules; audit log policy writing
9–10 Full practice + killer.sh Two full killer.sh sessions; timed task practice; review all error patterns from failed tasks

killer.sh Strategy

Your CKS exam purchase includes two killer.sh simulator sessions. The killer.sh CKS simulator is intentionally harder than the actual exam — tasks are more complex, more numerous, and the time pressure is more severe. Do not be discouraged if you score 50-60% on your first attempt. The simulator's value is in exposing your weakest areas before you sit the real exam.

  • Session 1 — Take it after completing weeks 7-8. Do not look at solutions until you have attempted every task. After finishing, read every solution explanation carefully, especially for tasks you did not complete.
  • Session 2 — Take it during week 10, as a final timed rehearsal. Focus on the categories where you lost the most points in session 1.

Top Resources

  • Killer Shell CKS course (included with exam purchase)
  • Kubernetes documentation — kubernetes.io is the only reference allowed in the exam
  • Falco documentation — falco.org for rule syntax reference
  • OPA Gatekeeper library — github.com/open-policy-agent/gatekeeper-library for ConstraintTemplate examples
  • Kim Wuestkamp's CKS course (Udemy) — comprehensive lab environment
Important: CKA Must Be Active

Your CKA must be valid (not expired) at the time you register for CKS. CKA certifications are valid for 3 years. If your CKA is expired, you must renew it before purchasing CKS. Check your certification expiry at training.linuxfoundation.org before registering.

Comments

Sign in to leave a comment.

No comments yet. Be the first!

Comments are reviewed before publication.