CKS Kubernetes Security Specialist Exam Study Guide

What Does the CKS Exam Actually Involve?

The Certified Kubernetes Security Specialist exam presents 15 to 20 performance-based tasks over 120 minutes, requires 67 percent to pass, and costs $445 USD. Every task is solved by configuring a real Kubernetes cluster from a terminal – there are no multiple-choice questions anywhere in the exam.

The six domains at a glance

Six domains carry the weight, and the distribution is worth studying before anything else.

The three 20% domains

Three domains at 20 percent each define the modern shape of the exam: what runs inside the cluster, where it came from, and what it does once running. Cluster configuration matters, but it is no longer the centre of gravity.

Why the performance format changes prep

The format changes preparation entirely. Roughly six to eight minutes per task sounds generous until you account for reading the scenario, switching to the correct cluster context, implementing, and verifying. Official objectives are published by the Linux Foundation training programme.

Why Does CKS Require a Valid CKA First?

CKS requires an active Certified Kubernetes Administrator credential because the exam assumes you can already operate a cluster fluently. It tests securing Kubernetes, not using it – so no task pauses to explain how to inspect a pod, edit a deployment, or read logs.

CKA speed is a prerequisite

The practical consequence is that CKA-level speed is a hard prerequisite rather than a recommendation. If constructing a manifest or navigating between namespaces takes you noticeable thought, the clock will beat you regardless of how well you understand security concepts.

It must be active, not historical

The requirement is also active rather than historical. Your CKA must be valid at the time you sit CKS, so an expired credential must be renewed first.

Planning around CKA expiry

One practical implication for planning: if your CKA is close to expiry, sit CKS sooner rather than later. Candidates occasionally discover the problem during registration, which is an avoidable delay.

Cluster Setup: What Does the 15% Domain Cover?

Cluster Setup covers network security policies, CIS benchmark review, TLS for Ingress, protecting node metadata, and verifying platform binaries. It establishes the secure baseline everything else depends on.

Network policies

Network policies are the highest-value topic here and among the most frequently implemented tasks on the exam. The concept that matters: Kubernetes networking is permissive by default, so any pod can reach any other pod until a policy says otherwise. Applying a policy that selects a pod immediately makes that pod default-deny for the direction the policy addresses.

Ingress and egress are independent

That direction distinction is where candidates lose marks. Ingress and egress rules are independent – a policy defining only ingress leaves egress entirely unrestricted. A default-deny posture requires an explicit policy selecting all pods for both directions, and building that from memory is worth practising until it is automatic.

CIS benchmark review

CIS benchmark review is the audit-oriented topic. You should be able to run a benchmark tool against a cluster, read its output, and remediate specific findings – the exam is more likely to ask you to fix a flagged control than to recite the benchmark. The CIS Kubernetes Benchmark is the reference standard.

Node metadata protection

Node metadata protection addresses a cloud-specific risk: pods reaching the cloud provider’s metadata endpoint can potentially obtain node credentials. Blocking that endpoint with a network policy is a compact, likely task.

How Do RBAC and API Restriction Harden a Cluster?

Cluster Hardening covers role-based access control, service account management, restricting API access, and keeping Kubernetes updated. RBAC is the dominant topic and the one where precision matters most.

The four RBAC objects

The four RBAC objects must be second nature. A Role grants permissions within a namespace; a ClusterRole grants them cluster-wide. A RoleBinding attaches a role to subjects within a namespace; a ClusterRoleBinding attaches cluster-wide. The subtlety worth knowing: a RoleBinding can reference a ClusterRole, which grants those permissions only within the binding’s namespace – a common way to reuse a role definition without granting cluster-wide scope.

Service accounts

Service accounts are the second focus. Every pod gets one, and the default service account is mounted automatically unless you prevent it. Disabling automatic token mounting for workloads that never call the API is a fast, high-value hardening step and a likely task.

Least privilege in practice

The principle running through the domain is least privilege applied concretely. Given an over-permissive role, you should be able to narrow it to exactly the verbs and resources required – and know that wildcards in a Role are almost always the wrong answer when a scenario asks for tightening.

API access restriction

API access restriction covers anonymous authentication, insecure ports, and the admission controllers that enforce policy at admission time. Knowing which admission controller enforces which behaviour is worth memorising.

What Does System Hardening Require at the Node Level?

System Hardening is the smallest domain at 10 percent, covering OS footprint reduction, least-privilege host access, minimising network exposure, and kernel-level controls such as AppArmor and seccomp. It addresses the layer beneath Kubernetes.

Seccomp and AppArmor

Seccomp and AppArmor are the concrete examinable skills. Seccomp restricts which system calls a container may make; AppArmor restricts file and capability access through a loaded profile. Both are applied through pod specification fields, and being able to write those fields from memory matters because they are fiddly and easy to mistype under time pressure.

The default seccomp profile

Know that the runtime default seccomp profile is the pragmatic starting point – it blocks a substantial set of dangerous syscalls without the per-application tuning a custom profile requires. When a task asks for seccomp with no further detail, the runtime default is usually the intended answer.

Conventional node hardening

The remaining topics are conventional Linux hardening applied to nodes: remove unnecessary packages and services, restrict SSH, limit privileged access. The Kubernetes-specific framing is that a compromised node compromises every workload scheduled on it, which is why node hardening belongs in a Kubernetes security exam at all.

Minimizing Microservice Vulnerabilities Is 20% – What Matters Most?

This domain covers pod security standards, secrets management, isolation techniques, and pod-to-pod encryption. At 20 percent it is joint-largest, and pod security standards plus secrets handling account for most of its tasks.

Pod Security Standards

Pod Security Standards define three profiles with escalating strictness: privileged permits everything, baseline blocks known privilege escalations, and restricted enforces hardening including running as non-root and dropping capabilities. These are applied through Pod Security Admission using namespace labels, and knowing the label syntax matters because you will type it.

Enforcement modes

The enforcement modes are equally examinable. Enforce rejects violating pods, audit records violations in the audit log, and warn returns a message to the user without blocking. A namespace can carry different modes simultaneously – enforcing baseline while auditing restricted is a realistic migration pattern and a plausible task.

Secrets management honesty

Secrets management requires a specific piece of honesty the exam tests: Kubernetes Secrets are base64-encoded, not encrypted, and are stored in etcd in plaintext by default. Enabling encryption at rest through an EncryptionConfiguration is the remediation, and understanding that base64 provides no confidentiality is the conceptual point.

Isolation and encryption

Isolation and encryption round out the domain. Namespaces provide logical separation but not runtime isolation – a container escape crosses namespace boundaries – so genuine isolation requires node separation or a sandboxed runtime. The Pod Security Standards documentation specifies each profile’s controls precisely.

Which Supply Chain Security Practices Are Tested?

Supply Chain Security is worth 20 percent and covers base image optimisation, understanding the supply chain, signing and validating artefacts, and static analysis. It reflects the reality that most cluster vulnerabilities arrive inside images rather than through the API.

Base image minimisation

Base image minimisation is the foundational practice. Every package in an image is potential attack surface, so distroless and minimal base images reduce vulnerability count simply by containing less. The reasoning the exam wants is that you cannot exploit a shell that is not present.

Image scanning

Image scanning is the practical skill. You should be able to scan an image, read the vulnerability output, and act on it – usually by rebuilding on an updated base rather than patching in place. Expect a task that scans and requires a decision based on the findings.

Admission-time control

Admission-time control is where Kubernetes enforces supply chain policy. Admission controllers can reject images from untrusted registries, images without signatures, or images failing policy – and the concept to hold is that this is preventive rather than detective. A policy blocking unsigned images at admission stops the deployment; a scan afterwards only tells you it already happened.

Static analysis of manifests

Static analysis extends the idea to manifests themselves. Scanning Kubernetes YAML for insecure configuration – privileged containers, host network access, missing resource limits – catches problems before they reach the cluster, and knowing that manifest scanning is distinct from image scanning is worth a mark.

How Is Runtime Security and Monitoring Examined?

Monitoring, Logging and Runtime Security is the third 20 percent domain, covering behavioural analytics, threat detection, attack phase analysis, container immutability, and audit logging. It addresses detecting compromise in a running cluster.

Runtime threat detection

Runtime threat detection through behavioural analysis is the domain’s centre. The model is that you define what normal container behaviour looks like and alert on deviations – a container that suddenly spawns a shell, writes to an unexpected path, or opens an unusual network connection is behaving abnormally regardless of whether any signature matches.

Container immutability

Container immutability is the complementary preventive control. A container filesystem set read-only cannot be modified by an attacker who gains execution, which both prevents persistence and makes any write attempt a high-confidence signal. Implementing immutability through the pod security context is a compact, likely task.

Audit logging

Audit logging is the forensic layer and requires configuration knowledge. Audit policy defines which events are recorded and at what level – from metadata only through request and response bodies – and the trade-off is coverage against volume. Logging every request body produces unusable volumes; logging nothing leaves no evidence.

Mapping attack phases

Understanding attack phases ties the domain together: initial access, execution, persistence, privilege escalation, and lateral movement each leave different traces, and knowing which control detects which phase is the reasoning behind scenario tasks. Comparable microsegmentation thinking appears in the Flow network security certification guide.

Which Exam Techniques Separate Passes from Failures?

CKS is as much a time management exam as a knowledge exam. Candidates who fail usually knew the material but ran out of clock – so technique deserves explicit practice rather than being left to the day.

Using documentation access

Documentation access is the single largest lever. You may use the official Kubernetes documentation during the exam, which means you do not need to memorise every YAML field – but you do need to find things fast. Practise navigating to the network policy examples, the security context reference, and the seccomp and AppArmor pages until you can reach each in seconds.

Cluster context switching

Cluster context switching is the most common source of lost marks and the most avoidable. Tasks run against different clusters, and each provides a context command. Running the command at the start of every task, without exception, prevents the failure mode where a correct solution is applied to the wrong cluster and scores zero.

• Switch context first – every task, before reading further
• Skip and return – flag anything costing more than its share of time
• Verify before moving on – confirm the pod actually starts, the policy actually blocks
• Use imperative commands – generate YAML with kubectl rather than typing manifests from scratch
• Do not over-engineer – implement what the task states, nothing more

Verify everything

Verification deserves emphasis because partial credit is limited. A network policy that looks right but was never applied because of a YAML indentation error scores nothing, and a five-second check would have caught it.

Who Should Pursue the CKS Credential?

CKS suits platform engineers running Kubernetes in production, security engineers responsible for container infrastructure, and DevSecOps practitioners embedding controls into delivery pipelines. It assumes CKA-level fluency and is not an entry point to either Kubernetes or security.

Why the hands-on format matters

Its value comes from the format. Because every task is performed on a live cluster, the credential proves capability rather than recall – a distinction hiring managers understand, and one that multiple-choice security certifications cannot make.

For security professionals

For security professionals moving into cloud-native infrastructure, CKS is often the harder direction of travel: the security concepts are familiar but the Kubernetes fluency has to be built first, which is precisely what the CKA prerequisite enforces. Platform engineers usually find the reverse – the cluster work is comfortable and the security reasoning is the new material.

Validity and renewal

The credential is valid for two years, shorter than many certifications, which reflects how quickly Kubernetes security practice changes. Pod Security Admission replacing Pod Security Policies within a few releases is the clearest illustration of why that shorter cycle exists.

How Should You Prepare for CKS?

Eight to twelve weeks at eight hours per week suits candidates holding a current CKA. Effective CKS preparation is almost entirely hands-on – reading about a network policy teaches you nothing about writing one correctly under time pressure.

1. Weeks one to two – cluster setup. Build a multi-node cluster you can break freely. Write network policies until default-deny for both directions is automatic. Run a CIS benchmark and remediate real findings.
2. Weeks three to four – hardening. Practise RBAC until Role, ClusterRole, and both binding types are reflexive. Narrow over-permissive roles repeatedly. Apply seccomp and AppArmor from memory.
3. Weeks five to six – microservice security. Apply all three Pod Security Standards profiles and observe what each rejects. Enable encryption at rest for secrets and confirm the change in etcd.
4. Weeks seven to eight – supply chain. Scan images, rebuild on minimal bases, and configure admission control that rejects untrusted images. Scan manifests for insecure settings.
5. Weeks nine to ten – runtime security. Configure runtime threat detection, trigger alerts deliberately, and set an audit policy. Make a container filesystem immutable and observe what breaks.
6. Weeks eleven to twelve – timed practice. Run full-length sessions under exam conditions with only the official documentation available.

Two habits that decide outcomes

Two habits decide outcomes. Practise exclusively with the official documentation open and nothing else, so the exam environment holds no surprises. And time every task from the start, because knowing a task should take six minutes only helps if you have felt what six minutes costs. The Kubernetes security documentation is both your study material and your exam reference, and timed work through the CKS practice exam questions helps confirm domain coverage.

Frequently Asked Questions

How many questions are on the CKS exam?

The exam presents 15 to 20 performance-based tasks over 120 minutes. There are no multiple-choice questions – every task is solved by configuring a live Kubernetes cluster from a terminal.

What is the passing score for CKS?

You need 67 percent. Because tasks carry different weights, focus on completing and verifying high-value tasks rather than attempting everything superficially.

How much does the CKS exam cost?

The exam fee is $445 USD, which includes one free retake. The Linux Foundation periodically discounts certification bundles.

Do I need CKA before taking CKS?

Yes. An active Certified Kubernetes Administrator credential is required. The exam assumes CKA-level fluency and does not pause to explain routine cluster operations.

Which domains carry the most weight?

Minimize Microservice Vulnerabilities, Supply Chain Security, and Monitoring, Logging and Runtime Security each carry 20 percent, together accounting for 60 percent of the exam.

Can I use documentation during the exam?

Yes. The official Kubernetes documentation is available during the exam. Practise navigating it quickly, because the constraint is finding information fast rather than having access to it.

Are Kubernetes Secrets encrypted by default?

No. Secrets are base64-encoded, which provides no confidentiality, and are stored in etcd in plaintext unless encryption at rest is explicitly configured through an EncryptionConfiguration.

What is the difference between the three Pod Security Standards?

Privileged permits everything, baseline blocks known privilege escalations, and restricted enforces significant hardening including running as non-root and dropping capabilities. They are applied through namespace labels.

What is the most common reason candidates fail CKS?

Running out of time, usually compounded by forgetting to switch cluster context. Running the provided context command at the start of every task prevents correct solutions being applied to the wrong cluster.

How long is the CKS certification valid?

Two years, which is shorter than many certifications and reflects how quickly Kubernetes security practice evolves – Pod Security Admission replacing Pod Security Policies being the clearest example.

Conclusion

CKS is a capability exam rather than a knowledge exam, and its weightings show where cloud-native security has moved. Supply chain, runtime, and microservice hardening carry 60 percent between them, while the cluster configuration topics most associated with the credential account for 30.

Preparation must be almost entirely hands-on. Write network policies until default-deny is automatic, narrow RBAC roles repeatedly, apply all three Pod Security Standards profiles and watch what each rejects. Reading about these controls builds recognition; the exam requires production.

Then practise the mechanics that decide outcomes – switch context before every task, verify before moving on, and time everything. Candidates who fail CKS usually knew the material. They ran out of clock, or solved the right problem on the wrong cluster.