CKS (Kubernetes Security Specialist): prerequisites and a 6-week study plan

CKS — Certified Kubernetes Security Specialist — is the hardest of the three pro-tier Kubernetes exams in my opinion, narrower than CKA and meaner under time pressure. Two hours, hands-on, $445, free retake bundled. PSI Bridge, online only, no test centers. The pass mark is 67%. CNCF doesn't publish official pass rates but the community-polled first-attempt rate hovers around 40–50%, lower than CKA, and that tracks with my experience watching colleagues sit it.

The thing most people miss: you can't just sign up. CNCF requires an active CKA on your account at registration time. Not "you've taken the CKA at some point." Active. If your CKA expired (which it now does after 2 years instead of 3 since the April 1, 2024 policy change), you have to renew it before you can register for CKS. This is a hard gate, not a soft recommendation, and it surprises people every quarter.

The real prerequisites

The official: an active CKA. That's it.

The unofficial:

• Comfort with kubectl such that you don't think about syntax. If you're still googling "kubectl create deployment" you're not ready.
• Linux fundamentals — you'll be SSHing into nodes, reading systemd journals, editing kubelet flags, and debugging seccomp / AppArmor profile failures. If journalctl -u kubelet is unfamiliar, fix that first.
• vim proficiency. Not Vim wizardry. But editing YAML in vim under a 2-hour clock without losing 30 seconds to "wait, how do I save again" is mandatory.
• A working mental model of NetworkPolicy. This is the single biggest stumbling block on the exam. More on that below.
• Some prior contact with Falco, Trivy, AppArmor, seccomp, mTLS via service mesh, and Pod Security Standards. You don't have to be expert at any of them; you have to recognize them.

If you're missing more than two of those, do another month on CKA-style operational drills before tackling CKS. Trying to learn Kubernetes operations and security simultaneously under time pressure is a path to burning the free retake.

What's actually tested

The CNCF curriculum buckets it like this (the percentages shift with each curriculum revision; current as of early 2026):

• Cluster setup and hardening (~15%): CIS benchmarks, kube-bench, restricting external access, disabling anonymous auth, kubelet hardening flags.
• System hardening (~15%): kernel hardening (seccomp, AppArmor), reducing attack surface, IAM minimization on the cloud side.
• Minimize microservice vulnerabilities (~20%): Pod Security Standards (which replaced PSPs in 1.25), ServiceAccount tokens, OPA / Gatekeeper or Kyverno, mTLS.
• Supply chain security (~20%): scanning images with Trivy, signing with cosign, admission controllers that block unsigned images, SBOM basics, minimizing base images.
• Monitoring, logging, runtime security (~20%): Falco rules, behavioral analytics, immutability, audit logging at the API server level.
• Network policy (~10%): default-deny, namespace isolation, egress rules. Listed as a small percentage but in practice every other category touches NetworkPolicy too.

The exam doesn't test how Falco works internally. It tests whether you can write a Falco rule that fires when a shell starts in a container. The exam doesn't test cosign cryptography. It tests whether you can configure an admission controller to reject unsigned images. The work is operational, not academic.

The 6-week plan

This assumes ~10 hours a week with an active CKA already in pocket. Adjust if you have more or less time.

Week 1: NetworkPolicy until you bleed.

Set up a kind cluster locally with Calico or Cilium (the default kindnet doesn't enforce NetworkPolicy, which trips people up). Write a default-deny policy for a namespace. Write an allow-from-namespace policy. Write an egress policy that allows DNS only. Write one that allows traffic from a specific pod label across namespaces. Re-do all of these from memory until you can write them in vim without consulting kubernetes.io. NetworkPolicy YAML is the single highest-volume content area on the exam and the one most people fumble on. Spend more time here than you think you need to.

Week 2: Pod Security Standards, ServiceAccounts, RBAC tightening.

Apply restricted, baseline, and privileged profiles to namespaces. Configure ServiceAccounts with automountServiceAccountToken: false. Build RBAC that follows least-privilege for a deployment that needs to read ConfigMaps in its own namespace and nothing else. Practice diagnosing "this pod can't do X because of RBAC" until the kubectl auth can-i flow is automatic.

Week 3: Supply chain — Trivy, cosign, admission control.

Scan an image with Trivy and interpret the CVE output. Sign an image with cosign. Configure an ImagePolicyWebhook or Kyverno policy that rejects images not signed by your key. Set up an OCI registry locally if you want full reps. The exam will likely give you Trivy installed; you should know its key flags from memory (--severity HIGH,CRITICAL, --ignore-unfixed).

Week 4: Runtime — Falco, AppArmor, seccomp.

Install Falco on a kind cluster. Read the default rules. Write a custom rule. Apply an AppArmor profile to a pod (the exam typically gives you a profile already on the node and asks you to wire it up via annotation — which means knowing the syntax container.apparmor.security.beta.kubernetes.io/<container>: localhost/<profile>). Apply a seccomp profile via securityContext.seccompProfile. Both of these have annotation-based legacy syntax and field-based current syntax; the exam tends to test the current syntax but you should recognize both.

Week 5: Cluster and host hardening.

Run kube-bench, interpret the failures, fix the easy ones (anonymous auth, audit logging, kubelet flags). Configure audit policy on the API server. Restrict etcd access. Disable unnecessary kubelet ports. This is mostly node-level Linux work and it's where engineers without strong sysadmin backgrounds slow down.

Week 6: Killer Shell, full simulations, and rest.

Use both bundled Killer Shell sessions in this week. They are intentionally harder than the real exam; expect to score worse than you'd hope. Use the gaps to study. Take the actual exam in the last 2–3 days of week 6 while the muscle memory is fresh. Don't push it out further — every week you delay, you lose reflex.

Sleep the night before. Don't pull a study all-nighter. Do not change your kubectl aliases the day of the exam.

The stumbling blocks that bite people

NetworkPolicy under time pressure. Already mentioned and worth saying twice. The YAML structure is unforgiving — wrong indentation kills the policy silently and the pod still routes. Practice in vim until you can write a default-deny + selective allow from muscle memory.

Forgetting that NetworkPolicy needs a CNI that enforces it. kindnet doesn't. flannel (default in some setups) doesn't. Calico, Cilium, Weave do. Make sure your practice cluster runs an enforcing CNI or you'll learn the wrong lessons.

Mixing up PSP and Pod Security Standards. PSPs were removed in 1.25 (years ago now, but old training material still references them). The current mechanism is Pod Security Admission with the restricted, baseline, privileged profiles applied via namespace labels. Don't study PSPs.

etcd encryption-at-rest configuration. Tested often. Specifically: editing EncryptionConfiguration, restarting the API server with the right flag, and verifying with etcdctl get that the value is encrypted. Practice this.

The browser tab trap. You're allowed kubernetes.io, falco.org, app-armor.net, and a few others. You cannot rely on searching them under time pressure. Memorize the structure. Use the tab to copy-paste specific snippets, not to learn syntax.

Should you take it?

Take CKS if your job is or will be platform security, security engineering at a Kubernetes shop, or compliance work in regulated industries. Skip it if you're a generalist platform engineer — CKA covers what most generalist roles need, and CKS is overkill that expires in 2 years.

If you're going for it, browse the CKS question bank on CertLabPro or start a timed exam. The conceptual coverage in question banks complements the operational reps you have to do on real clusters. Both are necessary; neither alone is sufficient.