The Certified Kubernetes Security Specialist (CKS) examination is a vendor-neutral, performance-based assessment of Kubernetes security work performed from a command line against Kubernetes clusters. It currently uses Kubernetes v1.35, but the Linux Foundation aligns the environment with a recent Kubernetes minor release, so verify the current version and curriculum before relying on a command, feature, or domain weight. The six domains are Cluster Setup at 15%, Cluster Hardening at 15%, System Hardening at 10%, Minimize Microservice Vulnerabilities at 20%, Supply Chain Security at 20%, and Monitoring, Logging and Runtime Security at 20%. The exam is performance-based and proctored online: you solve multiple tasks from a command line in two hours, and you must have passed the Certified Kubernetes Administrator (CKA) exam first.
We can inspect the task flow and current domain distribution next.
A CKS task is complete when the requested security state exists and you have evidence that the relevant Kubernetes control enforces it. Memorizing a command may create an object quickly, but it does not establish that a workload is selected by a policy, that an identity has only the intended API permission, or that a detection rule observes the expected runtime behavior. Read the requirement for its target resource, security boundary, and required verification signal before changing configuration.
Under time pressure, produce small, inspectable artifacts. These commonly include a manifest that declares the intended state, a narrowly scoped command that applies or inspects it, and output showing the object or behavior after the change. A manifest proves the configuration submitted to the Kubernetes API. Command output proves only the observed resource state or response at that moment, within the selected cluster and namespace. Neither alone proves that every path is secure.
Use a repeatable loop. First, identify the active cluster context and target namespace. Next, inspect the existing objects and labels that determine policy selection or authorization scope. Apply the smallest change that addresses the stated condition, then verify the outcome with an observation matched to that condition. Finally, preserve enough context to undo an incorrect change, especially when modifying cluster-wide configuration, node files, or API server settings.
Operational rule Prefer evidence tied to the requested boundary over a familiar command that changes unrelated resources.
Throughout this course, we will secure a fictional retail workload in the shop namespace. A namespace is a Kubernetes scope that groups namespaced resources and can form an authorization and policy boundary. The workload has an externally reachable ingress path to orders-api:1.0 on port 8080; that application calls payments-api:1.0 on port 8443; payments-api then uses orders-db. No workload other than ingress is reachable from outside the cluster in this model.
Each application uses its own ServiceAccount, a Kubernetes identity that a Pod can use when it calls the Kubernetes API. orders-api uses orders-sa, while payments-api uses payments-sa. Keeping these identities distinct lets us test least-privilege authorization separately from network reachability, image provenance, Pod restrictions, and runtime signals. The reusable rule is to identify the workload path and identity boundary before selecting a security control.
We can now trace the workload boundary that later defenses must preserve.