CKS Certified Kubernetes Security Specialist Exam Topics and Questions

Cluster Setup is where the exam starts, and it is the foundation everything else rests on. Get the configuration wrong here and no amount of runtime security or RBAC tuning will save you. This domain is hands-on and unforgiving: you are expected to know which knobs to turn on real Kubernetes components, what a secure Ingress looks like, and why a misconfigured node endpoint is a liability before a workload ever runs.

– Network boundaries and traffic control

NetworkPolicies are the primary tool for restricting which pods can talk to which, and the exam tests whether you can write and apply them correctly, not just describe them. A common miss is leaving the default-allow posture in place: without an explicit NetworkPolicy selecting a pod, all ingress and egress is permitted. You need to know how selectors, namespaceSelectors, and podSelectors combine, and you need to understand that a policy only affects pods it selects.

Ingress objects carry their own security surface. TLS termination, which annotations control behaviour, and how to avoid exposing backends unintentionally are all fair game. Protecting node metadata endpoints, particularly the cloud provider metadata API accessible from inside pods, is a separate concern: the fix is a NetworkPolicy that blocks egress to the link-local address, and the exam expects you to know that path.

– Hardening components and verifying what you deploy

The CIS Kubernetes Benchmark gives you a checklist against etcd, the kubelet, kube-apiserver, and CoreDNS. You do not need to memorise every check number, but you do need to know what each component's dangerous defaults look like: anonymous authentication on the kubelet, insecure ports on the API server, missing etcd peer TLS. The exam will put you in front of a running cluster and ask you to fix something that the benchmark would flag.

Minimising GUI access means understanding that the Kubernetes Dashboard, when exposed with cluster-admin rights and no authentication, is a well-documented attack vector. The fix is scope reduction and proper RBAC, not removal by default.

Binary verification is the final check before anything runs. Knowing how to use the published SHA checksums to confirm that a kubectl or kubelet binary has not been tampered with is a short but examinable skill. The process is straightforward; forgetting to do it is the real-world mistake the exam is probing for.

How Cluster Setup is tested

At 15% of the exam, Cluster Setup produces a meaningful share of the performance-based tasks you will face. Items in this domain tend to be configuration tasks on a live cluster: apply a NetworkPolicy, fix a kubelet flag, configure TLS on an Ingress resource, or verify a binary checksum. The examiner is checking whether you can operate the tools, not whether you can recite theory.

The place candidates lose marks is speed and precision. A NetworkPolicy written with the wrong label selector silently fails: traffic continues to flow and nothing tells you the policy is not matching. Similarly, CIS benchmark fixes often require editing static pod manifests or kubelet config files and then confirming the component has restarted with the new settings. Candidates who skip the verification step hand marks back.

Items reward knowing the exact flag names and file paths from memory. Searching documentation under time pressure for the kubelet's --anonymous-auth flag location costs more time than most candidates budget for.

Where Cluster Setup deals with the initial configuration, Cluster Hardening is about locking down what is already running. The distinction matters in the exam: these tasks assume a functional cluster and ask you to reduce its attack surface without breaking it. Missteps here tend to have blast-radius consequences, because overly permissive RBAC or an exposed API server affects every workload in the cluster at once.

How Cluster Hardening is tested

At 15% of the exam, this domain carries the same weight as Cluster Setup and is tested in a similar style: live cluster tasks with a specific, verifiable outcome. The API server access question typically asks you to remove or restrict something that is currently too open. RBAC tasks require you to create or modify Roles, ClusterRoles, and their bindings with the minimum permissions needed, and the examiner checks the result by attempting an action that should now be denied.

Service account tasks are where precision matters most. The default service account in every namespace automatically mounts a token into pods unless you disable it. Items reward disabling automounting at the service account level or at the pod spec level, and they reward binding only the permissions that a specific workload genuinely needs.

The Kubernetes version update sub-topic is less about running kubeadm upgrade step by step and more about knowing why frequent updates matter from a security posture perspective. Candidates lose marks by applying changes that are too broad, breaking workloads that should still function, or failing to verify that the restriction they applied is actually in effect after the change.

System Hardening moves the conversation down one layer, from Kubernetes to the nodes it runs on. The operating system and kernel are the substrate everything else depends on, and an attacker who reaches the host bypasses most of what you configured in the previous two domains. At 10% of the exam this domain is smaller, but the tasks it contains require a different mental model: you are thinking about Linux, not Kubernetes.

How System Hardening is tested

Items in this domain tend to be narrower in scope than Cluster Hardening tasks but demand precise Linux knowledge. Reducing the host OS footprint means removing unnecessary packages and services; the exam may ask you to identify what should not be present on a node and remove it. IAM role minimisation in a cloud context means ensuring that node instance profiles carry only the permissions the node actually needs, nothing more.

The kernel hardening tools sub-topic is where candidates most often lose marks. AppArmor profiles must be loaded on the node before they can be referenced in a pod spec, and the exam tests the full path: confirm the profile is loaded, apply it to a container, verify enforcement. seccomp follows a similar pattern. Knowing the annotation or securityContext field syntax from memory is necessary; looking it up mid-task under time pressure is costly.

Minimising external network access overlaps with NetworkPolicy work from earlier domains, but here the focus is on the node itself: firewall rules, disabled services, and closed ports. Items reward demonstrating that the surface has actually been reduced, not just that a policy exists.

At 20% of the exam, this domain is one of the three heaviest. It sits at the intersection of Kubernetes configuration and workload isolation: you are controlling what individual pods and containers are allowed to do, how secrets are handled, and how far an attacker gets if one container is compromised. The scope is wide enough that a candidate who has only skimmed these topics will find multiple tasks here that they cannot complete confidently.

How Minimize Microservice Vulnerabilities is tested

Items in this domain ask you to configure security controls at the pod and container level, then verify that the restriction is actually enforced. OS-level security domain tasks involve writing securityContext blocks, applying OPA Gatekeeper constraints, or working with Pod Security Admission to restrict what workloads can run in a namespace. The exam checks the outcome: a pod that violates the policy should fail to schedule.

Secrets management tasks test whether you know the difference between mounting a secret as a volume versus an environment variable, and why that distinction has security implications. Items reward the more restrictive approach when both would technically work.

Runtime sandbox tasks require knowing that gVisor and Kata Containers provide isolation by intercepting syscalls or running a nested kernel, and that using them requires a RuntimeClass object plus the appropriate handler on the node. The mTLS sub-topic is typically tested through a service mesh configuration task: the exam expects you to enable mutual TLS between pods and confirm it is operating.

Candidates lose marks by applying controls at the wrong level, for example setting a securityContext on the pod spec when the requirement is per-container, or referencing a RuntimeClass that does not exist on the node.

Supply Chain Security shares the 20% weight of the previous domain and covers the path that code travels before it runs in your cluster. The threat model here is different from runtime isolation: you are thinking about what gets into the cluster in the first place, whether images are trustworthy, and whether your build artefacts have been tampered with. Candidates who treat this as a conceptual topic and skip the tooling practice tend to struggle with the hands-on tasks.

How Supply Chain Security is tested

Items in this domain ask you to demonstrate control over what images are allowed to run and to show that you can evaluate an image or a workload definition before deployment. Registry whitelisting tasks typically involve configuring an admission controller or OPA policy that rejects images from unapproved registries. The exam checks that the policy is in place and that a non-compliant pod is actually blocked.

Image signing and validation tasks require knowing the toolchain: how an image digest is used to pin a specific layer, and how signature verification fits into an admission flow. Static analysis tasks may ask you to review a Dockerfile or a Kubernetes manifest and identify what is wrong with it from a security perspective. Items reward identifying the specific, fixable problem rather than a general observation.

Vulnerability scanning tasks typically involve running a tool against an image and acting on the output. Trivy is the tool most associated with this exam. Knowing how to run it, read its output, and determine whether a finding is critical enough to act on is the examinable skill.

Candidates lose marks by configuring controls that are too permissive or that apply only to new workloads while leaving existing ones untouched.

The final domain, also at 20%, shifts from prevention to detection. Everything in the previous five domains reduces the probability of a breach; this domain is about knowing when one is happening anyway, and being able to reconstruct what occurred. The tooling is different, the mindset is different, and the exam tasks here reward candidates who have spent time with Falco and the Kubernetes audit log rather than those who understand the concepts only in the abstract.

– Behavioural detection and threat identification

Syscall-level behavioural analytics is the core skill here, and Falco is the tool the exam uses to test it. You need to know how to write and modify Falco rules: the condition syntax, the output format, and how to reload rules without restarting the daemon. The exam may give you a running Falco instance with an incomplete or incorrect rule and ask you to fix it so that a specific behaviour is detected.

Detecting threats across the full stack, from physical infrastructure through applications, networks, data, users, and workloads, sounds broad in the syllabus but in exam tasks it usually means knowing what a Falco rule for a given threat category looks like and whether your rule would fire on the right event. The attack-phase detection sub-topic reinforces this: you need to think about which syscalls or file events correspond to reconnaissance, lateral movement, or exfiltration, and write rules that catch them at each stage rather than only at the obvious moment of impact.

– Investigation, immutability, and audit logs

Deep analytical investigation in the exam context means using available evidence, Falco alerts, audit log entries, and container process listings, to identify what happened and who did it. You are not expected to operate a SIEM, but you are expected to read log output and draw a correct conclusion from it.

Container immutability is a configuration task: ensuring that a running container cannot write to its own filesystem, that processes cannot be injected into it, and that the pod spec enforces these constraints through readOnlyRootFilesystem and the absence of privilege escalation paths. Items reward a container spec that would prevent a write or execution attempt, not one that merely makes it harder.

Audit log configuration is the final skill area. You need to know how to define an audit policy, what the four audit levels mean and when each applies, and how to confirm that the API server is writing the events you expect. Candidates lose marks by writing a policy that is syntactically valid but captures either too little or so much that the output is operationally useless.

How Monitoring, Logging and Runtime Security is tested

At 20% of the exam, this domain generates as many tasks as Supply Chain Security or Minimize Microservice Vulnerabilities, but the tooling is more specialised. Falco rule tasks are the most distinctive: you will be asked to create or modify a rule file, and the item is scored on whether Falco actually fires on the target event. A rule that is syntactically correct but uses the wrong syscall filter or the wrong comparison operator will not score.

Audit policy tasks are scored similarly: the policy must be loaded, the API server must be using it, and the log must contain the events the task specifies. Candidates who write the policy but forget to reference it in the API server manifest, or who reference it but use the wrong path, hand marks back on a task they understood.

Immutability tasks are shorter but precise: the container spec must include the right fields set to the right values. Items reward a spec that enforces the constraint at the container level, not just at the pod level where it may not apply to all containers. The investigation and threat-detection sub-topics are more likely to appear as scenario-reading tasks than as configuration tasks, and they reward a specific, evidenced conclusion.