CKS Certified Kubernetes Security Specialist: hardest k8s cert explained

Thomas, a CKA holder working at a managed Kubernetes provider, scheduled his CKS exam four weeks after passing the CKA. He spent the first week reading documentation for Falco, OPA Gatekeeper, and Trivy — tools he'd never used in a production environment. On his first killer.sh simulation session, he scored 31 out of 100. The problem wasn't that he couldn't configure Kubernetes. The problem was that the CKS tests a stack of security tools with their own syntax, their own file formats, and their own failure modes — and none of them are familiar to Kubernetes administrators who've worked primarily on managed cloud services. He postponed his exam, built a three-node VirtualBox cluster, installed every required tool, and spent four additional weeks practicing at the node level. He passed with 75%.

The CKS has a hard prerequisite no other Kubernetes certification requires: your CKA must be active before you can even register. This isn't an arbitrary restriction — the CKS assumes you can already build and administer a Kubernetes cluster and layers security hardening, runtime threat detection, and supply chain security on top of that foundation. Without the CKA prerequisite, most of the CKS content would be inaccessible. With it, the content is merely very hard.

---

The 6 CKS domains and their weights

Domain	Weight
Cluster Setup	10%
Cluster Hardening	15%
System Hardening	15%
Minimize Microservice Vulnerabilities	20%
Supply Chain Security	20%
Monitoring, Logging and Runtime Security	20%

The distribution is more even than CKA or CKAD, which means there's no single domain you can afford to neglect. The bottom three domains (Microservice Vulnerabilities, Supply Chain Security, and Runtime Security) together represent 60% of the exam, and they cover tools that most Kubernetes practitioners haven't used until they specifically prepare for CKS.

---

Why CKS is harder than CKA

The CKA difficulty comes from breadth — you need to know how to do many things across the full cluster lifecycle. The CKS difficulty comes from tool-specific depth and the requirement to apply security concepts under time pressure with tools you may have never used before.

The tools the CKS requires you to know and use in a live terminal:

Tool	Domain	What You Do With It
Falco	Runtime Security	Interpret and modify rules, analyze audit events
Trivy	Supply Chain Security	Scan images for vulnerabilities, interpret CVSS output
OPA Gatekeeper	Microservice Vulnerabilities	Apply admission control constraints
AppArmor	System Hardening	Load profiles, apply to pod specs
seccomp	System Hardening	Apply seccomp profiles to pods
kube-bench	Cluster Hardening	Run CIS benchmark scans, interpret results
ImagePolicyWebhook	Supply Chain Security	Configure admission webhook for image scanning
NetworkPolicy	Cluster Setup	Write policies restricting pod-to-pod and external traffic
Pod Security Admission	Cluster Hardening	Configure baseline/restricted/privileged standards
Audit logs	Monitoring	Configure audit policy, interpret audit log output

Learning to use these tools at exam speed requires dedicated practice beyond reading documentation. Each tool has its own configuration format, and the CKS tests whether you can configure them quickly in a live cluster.

---

Domain 1 and 2: cluster setup and hardening

Cluster setup and hardening cover the configuration of a secure Kubernetes cluster rather than the creation of one. CKS candidates are expected to already know how to build a cluster (CKA prerequisite).

Cluster setup tasks

• Network policies: Writing NetworkPolicy resources that restrict pod-to-pod communication and external egress. The exam tests both simple and multi-rule policies. Writing a policy that allows ingress only from pods with a specific label while denying all other ingress is a common task type.
• Dashboard security: Configuring the Kubernetes Dashboard with secure settings — restricting access, ensuring it's not exposed to the internet, applying appropriate RBAC.
• Ingress with TLS: Configuring Ingress resources with TLS termination using Kubernetes Secrets.
• Node metadata protection: Configuring network policies to prevent pods from accessing cloud provider metadata endpoints (e.g., 169.254.169.254).

Cluster hardening tasks

• RBAC least privilege: Reviewing and restricting RBAC permissions to least privilege
• Service account restrictions: Disabling auto-mounting of service account tokens in pods that don't need API access (automountServiceAccountToken: false)
• Upgrade frequency: Understanding why regular Kubernetes version upgrades are security-relevant
• Restricting API server access: Configuring anonymous access settings, TLS certificates, and API server flags like --anonymous-auth=false and --profiling=false

---

Domain 3: system hardening

System hardening moves below the Kubernetes level to the underlying Linux nodes.

AppArmor profile syntax for containers

AppArmor — a Linux kernel security module that restricts what system calls and file system access a process can perform, using profiles loaded into the kernel.

On the CKS, you're expected to:

1. Load an existing AppArmor profile on a node using apparmor_parser
2. Apply that profile to a specific container in a pod

# Applying an AppArmor profile to a container
apiVersion: v1
kind: Pod
metadata:
  annotations:
    container.apparmor.security.beta.kubernetes.io/my-container: localhost/my-profile
spec:
  containers:
  - name: my-container
    image: nginx

The annotation format is exact and must be memorized: container.apparmor.security.beta.kubernetes.io/<container-name>: localhost/<profile-name>. The profile must be loaded on the node before the pod is scheduled — the CKS tests this loading step specifically.

A minimal AppArmor profile for a container that only needs to read files and make network connections:

#include <tunables/global>

profile my-nginx flags=(attach_disconnected) {
  #include <abstractions/base>
  file,
  network,
  deny /etc/shadow r,
}

seccomp profiles

seccomp — secure computing mode, a Linux kernel feature that restricts which system calls a process can make, reducing the attack surface for container escapes.

The CKS tests applying both the runtime default seccomp profile and custom profiles:

securityContext:
  seccompProfile:
    type: RuntimeDefault

For a custom seccomp profile stored at /var/lib/kubelet/seccomp/profiles/my-profile.json:

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/my-profile.json

---

Domain 4 and 5: microservice vulnerabilities and supply chain security

These two domains are where CKS preparation diverges most from CKA preparation.

OPA Gatekeeper ConstraintTemplate structure

OPA Gatekeeper — an admission controller that enforces policies on Kubernetes resources using Open Policy Agent's Rego policy language. It uses two resource types: ConstraintTemplate (defines a policy schema and logic) and Constraint (applies an instance of a template).

The structure of a ConstraintTemplate:

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          properties:
            labels:
              type: array
              items: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels

        violation[{"msg": msg}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("Missing required labels: %v", [missing])
        }

The ConstraintTemplate defines the policy logic in Rego. A Constraint then instantiates the template with specific parameters:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-owner-label
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    labels: ["owner"]

The CKS expects you to apply existing ConstraintTemplates and create Constraints from them — not write ConstraintTemplates from scratch. Understanding the structure helps you read and modify them.

Trivy image scanning commands

Trivy — an open-source vulnerability scanner that checks container images, file systems, and Git repositories against known CVE databases.

trivy image nginx:1.19
trivy image --severity HIGH,CRITICAL nginx:1.19
trivy image --format json nginx:1.19
trivy image --exit-code 1 --severity CRITICAL nginx:1.19

The --severity CRITICAL,HIGH flag filters output to only show high and critical CVEs — the most common exam task. --exit-code 1 causes Trivy to exit with a non-zero code if vulnerabilities are found, which integrates with CI/CD pipeline failure conditions.

CKS tasks typically ask you to scan a list of images, identify the one with the fewest critical vulnerabilities, and use that image in a deployment. Or they ask you to identify whether a specific CVE is present in a given image version.

Supply chain concepts tested

1. Image provenance: understanding which registries are trusted and how to enforce trusted registries using admission controllers
2. Static analysis: scanning image layers for vulnerabilities with Trivy
3. Admission control: preventing images from untrusted registries from running using ImagePolicyWebhook
4. Signed images: cosign basics for image signing verification (newer exam versions)

---

Domain 6: monitoring, logging and runtime security

Falco rule syntax examples

Falco — a cloud-native runtime security tool that generates alerts when suspicious system calls are detected in running containers. It reads kernel system calls using eBPF or a kernel module and applies rules to generate security events.

- rule: Shell spawned in container
  desc: A shell was spawned inside a container
  condition: spawned_process and container and shell_procs
  output: "Shell spawned (user=%user.name command=%proc.cmdline container=%container.id image=%container.image.repository)"
  priority: WARNING
  tags: [container, shell]

- rule: Write below etc in container
  desc: An attempt to write to /etc inside a container
  condition: >
    open_write and container and fd.name startswith /etc
  output: >
    File below /etc opened for writing (user=%user.name
    command=%proc.cmdline file=%fd.name container=%container.id)
  priority: ERROR

The CKS tests modifying Falco rules in /etc/falco/falco_rules.local.yaml to detect specific behaviors. The condition field uses Falco's filtering syntax (field comparisons, logical operators, macro references). The output field uses template variables like %user.name, %proc.cmdline, and %container.id.

"The Falco section of CKS trips up candidates who've only read the documentation but never actually started a Falco service, triggered an alert, and watched the output. You need to practice this in a real environment, not just understand the concepts." — Kim Wuestkamp, CKS instructor and Kubernetes security researcher

---

2-year validity vs 3 years for CKA/CKAD

CKS certifications are valid for 2 years, compared to 3 years for CKA and CKAD. This shorter validity period is intentional — the Kubernetes security landscape evolves faster than cluster administration, and the Linux Foundation wants CKS holders to demonstrate current knowledge more frequently.

The shorter validity has a compounding implication: the CKA prerequisite requirement means if your CKA expires, you cannot renew your CKS without a valid CKA. CKS holders who let their CKA lapse after the 3-year window while their CKS is still active will find themselves unable to renew the CKS. Maintain both certifications actively if you plan to stay CKS-certified long-term.

For active security practitioners, renewing CKS every 2 years is reasonable — the tooling landscape (Falco rules, OPA policies, seccomp profiles) updates enough that a 2-year review cycle keeps knowledge current.

---

The killer.sh CKS simulator: the most important prep resource

The killer.sh CKS simulator, included with your CKS exam purchase (two 36-hour sessions), is widely considered the single most important preparation resource for CKS — even more so than for CKA or CKAD. The reason: CKS tool-specific tasks (writing a Falco rule, loading an AppArmor profile, scanning images with specific Trivy flags) are difficult to generate yourself as practice exercises without a structured environment.

Community consensus on killer.sh CKS: the scenarios are harder than the actual exam, which is by design. Candidates who complete 60-65% of killer.sh CKS tasks report feeling well-prepared for the real exam. If you're completing less than 50%, you need more hands-on practice time before scheduling.

---

Specific preparation challenges and path

Two real-world examples of candidates who struggled with CKS preparation. Thomas, a CKA holder at a managed Kubernetes provider, found the AppArmor and seccomp domains particularly difficult because his work environments used managed Kubernetes (EKS, GKE) where node-level security configuration was abstracted away. He spent four additional weeks building a local 3-node cluster on VirtualBox specifically to practice node-level security configurations. Elena, a security engineer who'd earned CKAD and CKA, found the runtime security domain confusing because Falco's rule syntax is specific — she had to write rules multiple times before the pattern became intuitive.

The most productive preparation path for CKS:

1. Ensure CKA is current and skills are fresh (practice etcd, kubeadm, and networking)
2. Build a dedicated practice cluster (either local VMs or a cloud cluster) — managed Kubernetes services don't expose enough node access for CKS practice
3. Install and configure Falco, OPA Gatekeeper, Trivy, and kube-bench on your practice cluster
4. Use killer.sh's CKS simulator — activate your first session at the midpoint of preparation, not at the end
5. Read the CIS Kubernetes Benchmark sections that kube-bench checks — the benchmark is available free at cisecurity.org
6. Aim for 4-5 weeks of focused preparation after CKA, with a minimum of 2 hours of daily hands-on practice

---

See also: CKAD vs CKA: what each exam tests and which to take first, Building a home Kubernetes lab for CKA exam preparation

References

1. Linux Foundation. (2024). CKS Exam Curriculum. https://github.com/cncf/curriculum/blob/master/CKS_Curriculum.pdf
2. Falco. (2024). Falco Documentation. https://falco.org/docs/
3. Open Policy Agent. (2024). OPA Gatekeeper Documentation. https://open-policy-agent.github.io/gatekeeper/
4. Aqua Security. (2024). Trivy Vulnerability Scanner. https://github.com/aquasecurity/trivy
5. CIS. (2023). CIS Kubernetes Benchmark. https://www.cisecurity.org/benchmark/kubernetes
6. Rice, L., & Hausenblas, M. (2023). Container Security: Fundamental Technology Concepts That Protect Containerized Applications. O'Reilly Media. ISBN: 978-1492056706

Frequently Asked Questions

What are the prerequisites for CKS?

You must hold an active CKA (Certified Kubernetes Administrator) certification before registering for the CKS exam. Your CKA must be valid at the time of CKS registration and throughout the CKS exam attempt. If your CKA expires, you cannot renew your CKS without first renewing the CKA.

What tools does the CKS exam require you to use?

The CKS requires hands-on use of Falco (runtime security rules), Trivy (image vulnerability scanning), OPA Gatekeeper (admission control), AppArmor (Linux security profiles), seccomp profiles, kube-bench (CIS benchmark scanning), and NetworkPolicy resources. Each tool has its own configuration syntax that must be practiced before the exam.

How long is the CKS certification valid?

CKS certifications are valid for 2 years, shorter than the 3-year validity of CKA and CKAD. The shorter validity reflects the faster-evolving Kubernetes security landscape. If your CKA expires before your CKS, you cannot maintain active CKS status without a valid CKA.

Is the CKS harder than the CKA?

Yes, the CKS is consistently rated harder than the CKA by candidates who've taken both. The CKA tests broad cluster administration skills that most Kubernetes engineers practice regularly. The CKS tests specialized security tools (Falco, Trivy, OPA Gatekeeper) and Linux-level security configurations that many practitioners haven't used before specifically preparing for the exam.

How should I prepare for the CKS exam?

After passing CKA, build a dedicated practice cluster where you can install and configure Falco, OPA Gatekeeper, Trivy, and AppArmor — managed Kubernetes services (EKS, GKE, AKS) don't expose enough node access for CKS practice. Use the killer.sh CKS simulator in the final 2 weeks. Plan for 4-8 weeks of CKS-specific preparation after passing CKA.