CKS Study Guide: How to Pass the Certified Kubernetes Security Specialist Exam

The CKS is the hardest of the five Kubernetes certifications. It covers security across the entire Kubernetes lifecycle, from container images at build time to runtime threat detection in production. You get 2 hours, 15 to 20 hands-on tasks, and you need a 67% to pass. You also need a valid CKA before you can even register.

That CKA prerequisite exists for a reason. The CKS assumes you already know everything on the CKA exam. It does not re-teach cluster administration. It layers security on top of it. If your CKA knowledge is rusty, refresh it before starting CKS prep. You will use RBAC, NetworkPolicies, Pod specs, and cluster troubleshooting skills constantly.

This CKS study guide covers every exam domain, the specific tools you need to learn, and a study plan that works for engineers coming off a CKA pass.

What Makes the CKS Different

The CKA and CKAD test you on core Kubernetes operations. The CKS tests you on a different category of knowledge: security tooling, hardening techniques, and threat detection. Much of the CKS material involves tools outside of core Kubernetes.

On the CKA, you work with kubectl, kubeadm, and etcd. On the CKS, you work with those plus Falco, Trivy, AppArmor, Seccomp, OPA/Gatekeeper, audit logging, and more. If you have never touched these tools, budget extra study time. They are not intuitive if you are seeing them for the first time.

The exam is still open book. You can access the Kubernetes docs and the documentation for specific tools listed in the exam resources. But just like the CKA, looking things up eats your clock. Know the tools well enough that you only need the docs for specific syntax.

CKS Exam Domains and Weights

Six domains, more evenly weighted than the CKA.

Domain	Weight	What It Covers
Cluster Setup	10%	Network security policies, CIS benchmarks, Ingress TLS, node metadata protection
Cluster Hardening	15%	RBAC, service accounts, API server restrictions, upgrade management
System Hardening	15%	OS-level security, kernel hardening, IAM roles, network access restriction
Minimize Microservice Vulnerabilities	20%	Security contexts, Pod Security Standards, OPA/Gatekeeper, Secrets management, runtime sandboxing
Supply Chain Security	20%	Image scanning, image policies, Dockerfile best practices, allowlisting registries
Monitoring, Logging & Runtime Security	20%	Audit logging, Falco, behavioral analysis, immutable containers, syscall filtering

The three 20% domains make up 60% of the exam. That is where your study time should concentrate. Cluster Setup at 10% is the smallest chunk, but do not skip it. Easy points are still points.

The Study Plan

This plan assumes you hold a valid CKA and your cluster admin skills are still solid. If you passed the CKA more than 6 months ago, spend the first week reviewing CKA material before starting CKS-specific study.

Week 1: Cluster Hardening and RBAC Review

Start with familiar territory. Cluster Hardening (15%) builds directly on CKA knowledge and lets you ease into CKS topics without learning entirely new tools.

RBAC deep dive:

You used RBAC on the CKA. The CKS expects you to go deeper: identifying overly permissive roles, restricting service account permissions, and applying the principle of least privilege.

# Check what a service account can do
kubectl auth can-i --list --as=system:serviceaccount:default:my-sa

# Check a specific permission
kubectl auth can-i create pods --as=system:serviceaccount:default:my-sa

# Create a restrictive role
kubectl create role pod-viewer --verb=get,list --resource=pods

# Bind it to a service account
kubectl create rolebinding pod-viewer-binding \
  --role=pod-viewer \
  --serviceaccount=default:my-sa

Common CKS tasks: given an overly permissive ClusterRoleBinding, restrict it to a namespace-scoped RoleBinding. Or given a service account with wildcard permissions, narrow it to the minimum required verbs and resources.

Service account hardening:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: restricted-sa
automountServiceAccountToken: false

Disable automatic token mounting for service accounts that do not need API access. The CKS tests this because it is a common security gap. Most Pods do not need to talk to the Kubernetes API, but by default they get a token that lets them.

At the Pod level:

spec:
  serviceAccountName: restricted-sa
  automountServiceAccountToken: false

API server security:

Know the key API server flags that affect security:

• --anonymous-auth=false disables anonymous requests
• --authorization-mode=RBAC,Node ensures RBAC is active
• --enable-admission-plugins controls which admission controllers run
• --audit-policy-file enables audit logging
• --insecure-port=0 disables the insecure HTTP port (should always be 0)

The exam might ask you to modify the API server manifest at /etc/kubernetes/manifests/kube-apiserver.yaml to change these flags. After editing, the kubelet automatically restarts the API server because it is a static Pod.

Keeping clusters updated:

The CKS tests whether you understand why running the latest stable Kubernetes version matters for security. You practiced upgrades on the CKA. The CKS angle is: outdated clusters have known CVEs that attackers can exploit. The fix is regular upgrades using the process you already know from CKA prep.

Weeks 2 to 3: Minimize Microservice Vulnerabilities

This is the first 20% domain. It covers how to lock down workloads at the Pod and container level.

Pod Security Standards and Pod Security Admission:

Kubernetes has three built-in security profiles: Privileged (no restrictions), Baseline (prevents known privilege escalations), and Restricted (heavily locked down). Pod Security Admission enforces these at the namespace level.

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Three modes:

• enforce: Rejects Pods that violate the policy
• audit: Logs violations but allows the Pod
• warn: Shows a warning but allows the Pod

The CKS expects you to apply these labels to namespaces and understand which workloads will be blocked under each profile.

Security Contexts in depth:

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 10000
    runAsGroup: 10000
    fsGroup: 10000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: myapp:1.0
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL

The CKS wants you to know every field here and when to use it:

• runAsNonRoot: Container must run as a non-root user. Fails if the image runs as root.
• allowPrivilegeEscalation: Prevents child processes from gaining more privileges than the parent.
• readOnlyRootFilesystem: Makes the container filesystem read-only. The app writes to mounted volumes instead.
• capabilities: Drop ALL capabilities by default, then add back only what the app needs.
• seccompProfile: RuntimeDefault applies the container runtime's default syscall filter.

OPA Gatekeeper:

OPA (Open Policy Agent) with Gatekeeper is a policy engine that acts as an admission controller. It lets you define rules like "no Pod can run as root" or "all images must come from our internal registry."

You need to understand the architecture: Gatekeeper installs as an admission webhook. You create ConstraintTemplates (the rule logic) and Constraints (where and how to apply the rules).

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

The exam might ask you to create or modify a Constraint, not write ConstraintTemplates from scratch. Know how to read a template, understand the parameters, and apply a constraint to specific resources.

Secrets management:

The CKS expects you to understand that Kubernetes Secrets are base64-encoded, not encrypted, by default. Know how to enable encryption at rest:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-key>
      - identity: {}

This config goes to the API server via the --encryption-provider-config flag. The identity provider at the end means unencrypted Secrets can still be read (for migration). Eventually you remove it so only encrypted Secrets are served.

Runtime sandboxing (gVisor/Kata):

Know that gVisor (runsc) and Kata Containers provide additional isolation by running containers in a sandboxed kernel or lightweight VM. You configure this through RuntimeClasses:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc

Then reference it in the Pod spec:

spec:
  runtimeClassName: gvisor

The exam is unlikely to ask you to install gVisor, but it may ask you to create a RuntimeClass and assign it to a Pod.

Weeks 3 to 4: Supply Chain Security

Another 20% domain. This is about securing what gets deployed to your cluster.

Container image scanning with Trivy:

# Scan an image for vulnerabilities
trivy image nginx:1.25

# Scan and only show HIGH and CRITICAL
trivy image --severity HIGH,CRITICAL nginx:1.25

# Scan a tar archive
trivy image --input image.tar

# Output as JSON
trivy image --format json nginx:1.25

The exam will give you Trivy and ask you to scan images, identify vulnerabilities above a certain severity, and take action (like updating the image or removing the vulnerable workload).

Image allow lists and admission control:

Restricting which registries your cluster pulls from is a common CKS task. You can enforce this through:

1. OPA Gatekeeper constraints that reject Pods with images from unapproved registries
2. Validating admission webhooks
3. Pod Security Policies (deprecated but may still appear in older exam versions)

Example Gatekeeper approach: a Constraint that only allows images from registry.company.com/* and rejects everything else.

Dockerfile security best practices:

The exam might show you a Dockerfile and ask you to identify security issues:

# BAD: Running as root
FROM ubuntu:latest
RUN apt-get update && apt-get install -y curl
COPY app /app
CMD ["/app"]

# BETTER: Multi-stage, non-root, minimal base
FROM golang:1.22 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /app

FROM gcr.io/distroless/static:nonroot
COPY --from=build /app /app
USER 65534
ENTRYPOINT ["/app"]

Key issues to spot:

• Using latest tag (unpinned, could change)
• Running as root (no USER instruction)
• Using a full OS base image when a distroless or scratch image would work
• Not using multi-stage builds (the final image contains build tools)
• Installing unnecessary packages

Static analysis of Kubernetes manifests:

Tools like kubesec scan YAML manifests for security issues:

kubesec scan pod.yaml

Know what kubesec flags: running as root, missing security contexts, using hostPath volumes, mounting the Docker socket, privileged containers.

Weeks 4 to 5: Monitoring, Logging, and Runtime Security

The third 20% domain. This is where you learn to detect and respond to threats in a running cluster.

Audit logging:

Kubernetes audit logging records every request to the API server. The CKS expects you to configure audit policies and understand the four audit levels:

• None: Do not log
• Metadata: Log request metadata (user, timestamp, resource) but not request/response bodies
• Request: Log metadata and request body
• RequestResponse: Log everything

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
  - level: Metadata
    resources:
      - group: ""
        resources: ["pods", "services"]
  - level: None
    resources:
      - group: ""
        resources: ["configmaps"]

This policy logs full request/response for Secrets (sensitive), metadata only for Pods and Services, and nothing for ConfigMaps.

Enable it on the API server with:

--audit-policy-file=/etc/kubernetes/audit-policy.yaml
--audit-log-path=/var/log/kubernetes/audit.log
--audit-log-maxage=30
--audit-log-maxbackup=10

The exam will ask you to create or modify an audit policy and configure the API server to use it. Remember to add the volume mount for the policy file and the log directory in the API server static Pod manifest.

Falco for runtime security:

Falco monitors system calls and alerts on suspicious activity. It is the most important CKS-specific tool and almost certainly appears on the exam.

Falco uses rules to define what is suspicious:

- rule: Terminal shell in container
  desc: Detect a shell spawned in a container
  condition: >
    spawned_process and container and
    proc.name in (bash, sh, zsh)
  output: >
    Shell spawned in container
    (user=%user.name container=%container.name
    shell=%proc.name parent=%proc.pname)
  priority: WARNING

You need to know how to:

• Read and understand Falco rules
• Modify existing rules to change detection behavior
• Check Falco logs for alerts
• Understand the output format

Falco rules live in /etc/falco/falco_rules.yaml (default rules) and /etc/falco/falco_rules.local.yaml (custom overrides). Always modify the local file, never the default.

# Check Falco logs
journalctl -u falco

# Or if running as a container
kubectl logs -n falco <falco-pod-name>

Common scenarios the exam tests:

• Detect when someone exec's into a running container
• Detect when a process reads sensitive files (/etc/shadow, /etc/passwd)
• Detect when a container writes to a binary directory (/bin, /sbin, /usr/bin)
• Modify a Falco rule to adjust the detection scope

Immutable containers:

An immutable container has a read-only root filesystem. If an attacker gains access, they cannot install tools, modify binaries, or write to the filesystem.

spec:
  containers:
    - name: app
      image: myapp:1.0
      securityContext:
        readOnlyRootFilesystem: true
      volumeMounts:
        - name: tmp
          mountPath: /tmp
        - name: cache
          mountPath: /var/cache
  volumes:
    - name: tmp
      emptyDir: {}
    - name: cache
      emptyDir: {}

The pattern: set readOnlyRootFilesystem: true and mount writable emptyDir volumes for the specific paths the application needs to write to (temp files, cache, logs).

Seccomp profiles:

Seccomp restricts which Linux system calls a container can make. The RuntimeDefault profile blocks dangerous syscalls while allowing common ones.

spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault

For custom profiles, you place a JSON profile on the node and reference it:

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

The exam will likely ask you to apply RuntimeDefault to a Pod or namespace. Custom profiles are less common on the exam but know the syntax.

AppArmor:

AppArmor restricts individual programs' capabilities using per-program profiles. On the CKS, you need to know how to apply AppArmor profiles to containers.

metadata:
  annotations:
    container.apparmor.security.beta.kubernetes.io/app: localhost/my-profile

The profile must be loaded on the node where the Pod runs. The exam will typically have the profile pre-loaded and ask you to apply it to a container via the annotation.

Check loaded profiles:

apparmor_status
# or
aa-status

Week 5 to 6: System Hardening and Cluster Setup

System hardening (15%):

This domain covers OS-level security on the nodes.

Reducing the attack surface:

• Disable unnecessary services on nodes
• Remove unnecessary packages
• Close unnecessary ports
• Use a minimal OS (container-optimized OS if on cloud)

Restricting network access:

# List open ports
ss -tlnp

# Identify unnecessary services
systemctl list-units --type=service --state=running

# Disable a service
systemctl disable --now <service-name>

The exam might give you a node with unnecessary services running and ask you to identify and disable them.

Kernel hardening:

Know that you can restrict kernel parameters through sysctl. Some relevant settings:

# Disable IP forwarding (if not needed)
sysctl -w net.ipv4.ip_forward=0

# Ignore ICMP broadcast requests
sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1

Cluster setup (10%):

CIS Kubernetes Benchmark:

The CIS (Center for Internet Security) benchmark is a set of security recommendations for Kubernetes. The exam may ask you to run kube-bench and address findings.

# Run kube-bench
kube-bench run --targets master
kube-bench run --targets node

kube-bench outputs pass/fail results for each CIS recommendation. The exam will ask you to fix specific failures, not run the entire benchmark from scratch.

Ingress with TLS:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: secure-ingress
spec:
  tls:
    - hosts:
        - app.example.com
      secretName: app-tls-secret
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app-service
                port:
                  number: 443

Create the TLS secret:

kubectl create secret tls app-tls-secret \
  --cert=tls.crt \
  --key=tls.key

Protecting node metadata:

On cloud providers, instance metadata endpoints (like 169.254.169.254 on AWS) can be accessed from Pods. A NetworkPolicy that blocks egress to this IP prevents Pods from reading node credentials:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-metadata
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.169.254/32

Exam Day Tips

Everything from the CKA still applies

The terminal setup tips from the CKA study guide all carry over: set your alias, enable completion, configure vim. The CKS uses the same proctoring platform and terminal environment.

Know where tools live

On the exam, tools like Falco, Trivy, and kube-bench are pre-installed. But know their default paths:

• Falco rules: /etc/falco/falco_rules.yaml and /etc/falco/falco_rules.local.yaml
• Falco config: /etc/falco/falco.yaml
• Audit policies: you usually create these in /etc/kubernetes/
• AppArmor profiles: /etc/apparmor.d/
• Seccomp profiles: /var/lib/kubelet/seccomp/
• API server manifest: /etc/kubernetes/manifests/kube-apiserver.yaml

After modifying the API server, wait

When you change the API server static Pod manifest, the kubelet detects the change and restarts the API server. This takes 10 to 30 seconds. Do not panic if kubectl stops responding briefly. Wait for it to come back. If it does not come back after a minute, you introduced an error in the manifest. Check your changes.

Verify your work

After applying a security change, verify it works:

# Verify a NetworkPolicy blocks traffic
kubectl exec test-pod -- curl -s --connect-timeout 3 <target-ip>

# Verify a Pod is rejected by admission control
kubectl run test --image=nginx --dry-run=server

# Verify audit logging is active
tail -f /var/log/kubernetes/audit.log

# Verify Falco detects your test
kubectl exec <pod> -- bash   # should trigger Falco alert

Common Mistakes on the CKS

Forgetting to add volume mounts when configuring audit logging. You add the --audit-policy-file flag to the API server, but the API server cannot read the file because you forgot to mount the directory. The API server fails to start and kubectl goes down. Always add both the volumes and volumeMounts entries in the API server manifest.

Editing the wrong Falco rules file. Custom rules go in falco_rules.local.yaml, not falco_rules.yaml. The default file gets overwritten on updates. If you edit it, your changes disappear.

Breaking the API server. More than any other exam, the CKS involves editing the API server manifest. One typo and the API server goes down. Always make a backup before editing:

cp /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/kube-apiserver.yaml.bak

If something goes wrong, copy the backup back and wait for the API server to recover.

Underestimating Falco. Falco is not a minor topic. It appears in a 20% domain and is almost guaranteed to be on the exam. Spend real time learning the rule syntax, output format, and common detection scenarios.

Not practicing with real tools. You can read about Trivy and Falco all day. But on the exam, you need to run the commands and interpret the output without hesitation. Install these tools in a practice environment and use them.

Best CKS Study Resources

Courses

The Linux Foundation official CKS training provides the deepest conceptual coverage. Text-based and self-paced. Good for engineers who want to understand the "why" behind each security control.

Choose a structured course with integrated labs. The labs are critical for CKS because you need hands-on time with Falco, Trivy, AppArmor, and Seccomp in a real environment.

Practice

Practice sessions are included with your CKS exam purchase. Two sessions, 36 hours each. The CKS practice sessions are harder than the real exam, same as the CKA version. Use them the same way: first session one week before, second session 2 to 3 days before.

Your own cluster with Falco, Trivy, and AppArmor installed is the best practice environment for CKS. Set up a kind or kubeadm cluster, install the security tools, and practice the scenarios. Break the security posture, then fix it.

GitHub has free, community-maintained structured learning materials and practice exercises organized by domain.

Study Timeline

Background	Study Time
Just passed CKA (within 1 month)	4 to 6 weeks
Valid CKA, active K8s experience	5 to 7 weeks
Valid CKA, passed 3 to 6 months ago	6 to 8 weeks
Valid CKA, minimal recent K8s work	8 to 10 weeks (include CKA review)

The security-specific tools (Falco, Trivy, AppArmor, Seccomp, OPA) are the main time investment. If you have used any of these in production, your study time drops significantly. If they are all new to you, budget for the longer end of these ranges.

What Comes After the CKS

If you have CKA + CKS: Add the CKAD for the complete professional set. Two to three weeks of study covers the application-specific topics. See the CKAD study guide.

If you have CKA + CKAD + CKS: The associate certs (KCNA and KCSA) are the final pieces for the Kubestronaut title. The KCNA is a weekend of review after passing three professional exams. The KCSA is a subset of CKS material at a conceptual level. See the Kubestronaut path guide for the full strategy.

For career growth: The CKS opens doors to security-focused roles that pay at the top of the Kubernetes salary range. Read our salary guide for specific numbers by role.

For the broader picture of how CKS fits into the certification ecosystem, check the certification path guide.

FAQ

How hard is the CKS exam?

The CKS is the hardest of the five Kubernetes certifications. It combines CKA-level cluster administration with an entire layer of security tools and concepts that most engineers have not used in their daily work. The pass rate is estimated lower than the CKA. The difficulty comes from both the breadth of tools you need to know and the depth of security knowledge expected.

Do I need the CKA to take the CKS?

Yes. The CKS requires a valid (unexpired) CKA certification. You cannot register for the CKS without it. This is the only hard prerequisite in the Kubernetes certification system.

How long should I study for the CKS?

Four to eight weeks if you recently passed the CKA and have been working with Kubernetes actively. Six to ten weeks if your CKA is older or your K8s skills have gotten rusty. The main variable is how familiar you are with the security-specific tools: Falco, Trivy, AppArmor, Seccomp, and OPA/Gatekeeper.

What tools do I need to learn for the CKS?

The main tools tested on the CKS: Falco (runtime security monitoring), Trivy (image vulnerability scanning), AppArmor (application-level security profiles), Seccomp (system call filtering), OPA/Gatekeeper (policy enforcement), kube-bench (CIS benchmark scanning), and kubesec (manifest security analysis). You also need deep knowledge of Kubernetes-native security features: RBAC, NetworkPolicies, Security Contexts, Pod Security Standards, and audit logging.

Is the CKS open book?

Yes. You can access kubernetes.io/docs, falco.org/docs, and other tool documentation listed in the exam resources. The same caveat as the CKA applies: looking things up costs time. Know the tools well enough that you only need docs for edge cases and specific syntax.

Is the CKS worth it for my career?

If security is part of your role or you want to move into security-focused positions, the CKS is very valuable. CKS holders earn $20,000 to $30,000 more than uncertified peers in security roles. Demand for Kubernetes security expertise is growing as more companies run production workloads on K8s. If security is not relevant to your career plans, the CKA and CKAD provide more general value.

Can I take the CKS without security experience?

Yes, but budget extra study time. The CKS does not require prior security experience as a formal prerequisite (beyond the CKA). Many people pass it as their first step into Kubernetes security. The exam tests practical skills that you can learn during preparation. You do not need a security background, but you do need to invest the time to learn the tools and concepts from scratch.

What is the CKS pass rate?

The exact pass rate is not publicly disclosed. Community estimates suggest it is lower than the CKA and CKAD, likely in the 40 to 55% range. The lower pass rate reflects the harder, more specialized content and the fact that candidates need to learn security tools many have never used before.