CKA proves you can run a cluster. CKS proves you can run it securely.

The CKA exam asks: configure this cluster, schedule these workloads, troubleshoot this node failure. The CKS exam asks: this cluster is running. Lock it down. Harden the API server. Audit what’s happening inside the containers. Enforce policy so that future deployments can’t undo your work. The shift from operations to security operations is deliberate — the CKS was introduced in 2020 specifically because the industry discovered that most Kubernetes deployments were operationally sound but security-wise catastrophic. Exposed dashboards, overprivileged service accounts, unsigned images, and misconfigured network policies were responsible for a wave of cryptojacking incidents and data exfiltrations across cloud-native infrastructure from 2018 onwards.

The CKS is the hardest of the three CNCF Kubernetes certifications. CKA tests breadth of administrative knowledge; CKAD tests application developer patterns; CKS tests adversarial thinking within a live cluster. A passing CKS candidate must know not just what a PodSecurityAdmission controller does, but how to configure it to enforce restricted standards cluster-wide, why privileged namespaces create attack surface, and how to audit the cluster’s existing workloads to identify which ones would fail under a hardened policy before applying it. That sequence — assess, harden, enforce, monitor — is the operational pattern the entire exam tests.

The prerequisite is meaningful: only candidates with an active (non-expired) CKA can register for CKS. The Linux Foundation enforces this automatically at registration. This gates the credential at a level of cluster operations fluency that ensures CKS candidates are solving security problems, not fighting kubectl syntax. Candidates who let their CKA expire must renew it before they can register for CKS — the two certifications are explicitly positioned as a progression, not alternatives.

The six CKS domains

Domain 1 — Cluster Setup (10%)

Cluster setup covers the security baseline that must be established when a Kubernetes cluster is provisioned. The exam tests whether candidates understand the attack surface of a default cluster and how to close it before workloads are ever deployed.

  • Network policies: by default, Kubernetes allows all pod-to-pod communication across the cluster. CKS tests the design and application of NetworkPolicy resources that implement a default-deny baseline and then selectively permit required traffic flows. Effective NetworkPolicy requires understanding pod selector logic, namespace selectors, IP block rules, and the limitation that NetworkPolicy enforcement depends on the CNI plugin — it is not implemented by the kube-proxy or the kubelet.
  • CIS Kubernetes Benchmark: the Center for Internet Security Kubernetes Benchmark defines hundreds of configuration checks across the API server, etcd, scheduler, controller manager, kubelet, and worker node configuration. CKS tests practical application of these benchmarks using tools like kube-bench, which automates CIS compliance checking and reports findings with remediation guidance. Candidates must be able to interpret kube-bench output and apply the corresponding fixes to API server flags, kubelet configurations, and file permission settings.
  • Ingress TLS and HTTPS enforcement: the CKS exam tests securing cluster ingress endpoints with TLS certificates, including creating TLS Secrets, configuring Ingress resources to terminate TLS, and enforcing HTTPS redirection. The security concern is that unencrypted ingress traffic exposes service credentials, session tokens, and sensitive data in transit.
  • API server security flags: the kube-apiserver is the single entry point to the cluster control plane. CKS tests key API server hardening flags including --anonymous-auth=false, --authorization-mode=RBAC,Node, --enable-admission-plugins (with specific secure plugins), --audit-log-path, and --tls-cipher-suites to restrict cipher negotiation to approved algorithms. Candidates must understand the security implication of each flag, not just its syntax.

Domain 2 — Cluster Hardening (15%)

Cluster hardening covers the ongoing security posture of a running cluster: restricting access, rotating credentials, and keeping the control plane components patched and minimal.

  • RBAC least-privilege design: Role-Based Access Control is the primary authorisation mechanism in Kubernetes. CKS tests the design of Roles and ClusterRoles that grant only the permissions required for a given service account or user — not * verbs on * resources. The exam specifically tests identifying overprivileged bindings in an existing cluster and replacing them with minimal equivalent roles. Common traps include cluster-admin bindings granted to application service accounts, wildcard verb grants, and overly broad ClusterRoleBindings applied where namespace-scoped Roles would suffice.
  • Service account hardening: every Pod in Kubernetes is assigned a service account, and by default that service account’s token is auto-mounted into the pod at /var/run/secrets/kubernetes.io/serviceaccount/. CKS tests disabling auto-mounting for pods that do not need API access (automountServiceAccountToken: false), creating dedicated service accounts with minimal RBAC bindings for pods that do need API access, and auditing existing deployments for over-privileged service account usage.
  • Kubernetes version currency: the CKS exam tests awareness that unpatched Kubernetes versions carry known CVEs affecting the API server, kubelet, and container runtime. Candidates are expected to understand the upgrade path (control plane before worker nodes, one minor version at a time) and how to identify the Kubernetes version of cluster components using kubectl version and kubeadm upgrade plan.
  • etcd encryption at rest: etcd stores the entire cluster state, including Secrets. By default, Secrets are stored in etcd as base64-encoded plaintext — not encrypted. CKS tests configuring the EncryptionConfiguration API server flag to encrypt Secrets at rest using AES-CBC or AES-GCM, understanding the key rotation process, and verifying that encryption is active by inspecting etcd directly.

Domain 3 — System Hardening (15%)

System hardening covers the Linux host layer beneath Kubernetes: reducing the attack surface of the nodes that run the kubelet, container runtime, and workloads.

  • AppArmor profiles: AppArmor is a Linux Security Module that restricts the system calls and filesystem operations an application can perform. CKS tests loading AppArmor profiles on cluster nodes, applying them to specific containers via the securityContext.appArmorProfile annotation, and verifying enforcement. A container confined by an AppArmor profile cannot read arbitrary filesystem paths or execute binaries outside its allowed set — significantly reducing the blast radius of a container escape.
  • Seccomp profiles: seccomp (secure computing mode) filters the system calls a process can make to the Linux kernel. CKS tests applying the RuntimeDefault seccomp profile to pods, creating custom seccomp profiles that allow only the system calls required for a specific workload, and auditing pods that run without any seccomp profile (the default state in many clusters). The securityContext.seccompProfile field on pods and containers is the mechanism tested.
  • Minimising host OS footprint: CKS tests removing unnecessary services from cluster nodes, understanding the principle that worker nodes should run only the kubelet, container runtime, and essential OS services — not application servers, database clients, or development tools that increase attack surface. The exam tests identifying and removing unused packages on a running node without disrupting the Kubernetes components.
  • Linux capabilities and privilege escalation prevention: containers run with a default set of Linux capabilities that can be further reduced or expanded. CKS tests dropping all capabilities (securityContext.capabilities.drop: [ALL]) and adding back only those required by the specific workload. It also tests preventing privilege escalation (allowPrivilegeEscalation: false) and the security context settings that enforce a read-only root filesystem and non-root user execution.

Domain 4 — Minimize Microservice Vulnerabilities (20%)

The largest domain by previous weight, covering the pod and workload security controls that prevent vulnerable or misconfigured containers from being exploited or from escaping to the host.

  • Pod Security Admission: the PodSecurity admission controller enforces three built-in security standards (privileged, baseline, and restricted) at the namespace level. CKS tests applying PSA labels to namespaces to enforce the restricted profile, understanding what the restricted profile prohibits (host namespaces, privileged containers, hostPath volumes, container port 0, non-root user requirements), and auditing existing workloads against the target policy before enforcement to avoid breaking running pods.
  • OPA Gatekeeper for policy enforcement: Open Policy Agent (OPA) with the Gatekeeper admission webhook extends Kubernetes with custom policy enforcement beyond what PSA provides. CKS tests writing ConstraintTemplates in Rego, creating Constraint resources that instantiate policies, and understanding the webhook admission flow that intercepts API server requests. Common policy examples tested include enforcing specific image registry allowlists, requiring resource limits on all containers, and preventing the use of the latest tag.
  • Secrets management: CKS tests handling Kubernetes Secrets securely: avoiding hard-coded credentials in container images and environment variables, using projected volumes to mount Secrets as files rather than environment variables (less likely to be captured in logs or crash dumps), and understanding the security boundary that Secrets provide — and their limitations when etcd encryption at rest is not configured.
  • Container sandboxing with gVisor / Kata Containers: container runtimes like gVisor and Kata Containers provide stronger isolation than standard runc by interposing between the container and the host kernel. CKS tests configuring a RuntimeClass resource to use an alternative runtime, applying that RuntimeClass to a Pod via the runtimeClassName field, and understanding the security trade-off: stronger isolation at the cost of higher overhead and reduced syscall compatibility.

Domain 5 — Supply Chain Security (20%)

Supply chain security covers the integrity of the container images and build artefacts that run in the cluster. The domain reflects the industry shift following high-profile supply chain attacks that demonstrated how malicious dependencies injected upstream could silently compromise downstream deployments.

  • Image scanning with Trivy: Trivy is the dominant open-source vulnerability scanner for container images. CKS tests running trivy image against a target image, interpreting the output (CVE IDs, severity ratings, affected packages, fixed versions), and making a security decision based on the findings. The exam does not require memorising CVE IDs — it tests the process: scan, assess severity, determine whether a patch is available, and recommend action (update the base image, update the affected package, or accept and document the risk).
  • Admission control for image policy: restricting which registries and images can be deployed into the cluster is a critical supply chain control. CKS tests using OPA Gatekeeper or ImagePolicyWebhook to enforce an image allowlist, preventing the use of latest tags (which bypass content addressability), and requiring images to be pulled from trusted internal registries rather than public repositories.
  • Image signing and verification: Sigstore’s Cosign has become the default tool for signing container images and verifying signatures at deploy time. CKS tests signing an image with cosign sign, verifying the signature with cosign verify, and integrating signature verification into the admission pipeline so that unsigned images are rejected before they can be scheduled. The underlying principle is that a signed image provides cryptographic proof that it was produced by a specific build pipeline and has not been tampered with in transit.
  • Static analysis of Kubernetes manifests: tools like kubesec perform static security analysis of Kubernetes YAML manifests before they are applied to the cluster, identifying risky configurations (privileged containers, hostPID, hostNetwork, missing resource limits) before they become running vulnerabilities. CKS tests running kubesec scan against a manifest, interpreting the scored output, and remediating the flagged issues.

Domain 6 — Monitoring, Logging & Runtime Security (20%)

Runtime security covers detection and response: identifying anomalous behaviour in running workloads, maintaining audit trails of API server activity, and configuring alerting for security-relevant events at the cluster and container level.

  • Falco for runtime threat detection: Falco is the CNCF’s runtime security tool, using Linux kernel instrumentation (eBPF or a kernel module) to detect anomalous syscall activity in running containers. CKS tests writing and applying Falco rules that alert on specific behaviours: shell execution inside a container, reading sensitive files like /etc/shadow, unexpected network connections, and privilege escalation attempts. Candidates must understand Falco’s rule syntax (condition, output, priority, tags) and how to reload rules without restarting the Falco daemon.
  • Kubernetes audit logging: the Kubernetes API server can be configured to produce an audit log of every request, recording who made the request, what they requested, and what the API server returned. CKS tests writing an audit policy (specifying which request stages and resources to log at which verbosity level), applying it to the API server, and interpreting audit log output to identify suspicious activity — such as repeated authentication failures, unusual resource access patterns, or service account tokens being used from unexpected IP addresses.
  • Immutable container filesystems: a container with a mutable filesystem can be used by an attacker to download additional tools, persist malware, or modify configuration. CKS tests enforcing a read-only root filesystem (readOnlyRootFilesystem: true) and using emptyDir volumes for paths that require write access at runtime. This limits the window for post-exploitation activity because tools cannot be written to the compromised container’s filesystem.
  • Incident response with container forensics: when a container exhibits suspicious behaviour, the response process involves capturing its state without destroying evidence. CKS tests the use of kubectl exec to inspect a running container, kubectl cp to extract files for analysis, and the decision process around whether to kill-and-restart (acceptable for stateless workloads where forensics are not required) versus isolating-and-preserving (required when legal hold or forensic chain of custody applies).

Exam format: why performance-based matters

The CKS is not a multiple-choice exam. There are no answers to guess, no process of elimination, no question stems that hint toward the correct response. The exam presents a set of tasks — typically 15–20 weighted problems — that must be completed on a live, pre-configured Kubernetes cluster accessible through a remote terminal. Each task specifies what must be accomplished; the candidate executes the commands and edits the configurations to achieve it. Automated graders check the cluster state after each task.

The open-book format means the official Kubernetes documentation is available in a browser tab throughout the exam — but only from kubernetes.io/docs, kubernetes.io/blog, and the Falco and Trivy documentation sites. This sounds generous but is not a meaningful advantage for underprepared candidates. Looking up syntax wastes time; the exam’s two-hour limit is tight enough that candidates who need to read documentation for every command will run out of time before completing the required tasks. The documentation tab helps with exact flag syntax and API field names — it does not help with the conceptual understanding of what to configure, in what order, and why.

The most common reason CKS candidates fail: they know what to configure but are too slow doing it. Each task carries a weighted score, and partial credit does not exist — a task is either solved correctly or not. Candidates who can complete 12 of 17 tasks with confidence outperform candidates who attempt all 17 and make configuration errors on half of them. Time management and command-line fluency are as much a part of the exam as technical knowledge.

Preparing for CKS: the practical approach

CKS preparation requires a hands-on environment. Reviewing documentation is insufficient — the exam tests operational execution under time pressure, and that capability only develops through repetition. A two-node Kubernetes cluster provisioned on any cloud provider or locally with kubeadm on two VMs provides the necessary practice surface. Candidates should work through every domain task type until execution is automatic: applying NetworkPolicies, modifying API server flags, writing Falco rules, configuring EncryptionConfiguration, running Trivy and remediating findings.

Killer Shell (included with the exam purchase as two 36-hour simulator sessions) provides the closest replication of the actual exam environment. Each session includes 22 weighted questions on a live cluster with the same remote desktop interface used in the real exam. Using both simulator sessions and reviewing every incorrect answer is the single highest-leverage preparation activity available. The exam environment uses a PSI bridge client — candidates should run the compatibility check before exam day and ensure their primary monitor, webcam, and network meet the requirements.

The domains that reward the most preparation time are Supply Chain Security and Runtime Security. Both were updated in the most recent curriculum revision to reflect the industry’s focus on Sigstore/Cosign for image signing and eBPF-based Falco for runtime detection — tools that many Kubernetes administrators have not yet used in production. Candidates who add Trivy, Cosign, and Falco to their daily toolkit during preparation are not just preparing for the exam; they are adopting the toolset that DevSecOps teams have standardised on for cloud-native environments.

CKS in the security credential landscape

Start with CKA — then CKS

CKS requires an active CKA, so the natural path is to clear CKA first and gain at least six months of hands-on cluster administration experience before tackling CKS. Candidates who attempt CKS immediately after CKA often pass CKA but struggle with CKS’s time pressure because they’re still internalising cluster operations fluency. The official Linux Foundation CKS candidate page includes the current exam curriculum, environment details, and links to the official Killer Shell simulator. Practice with real cluster tasks is non-negotiable — treat every study session as a timed exam and your actual exam as one more session.

Practice CKA and CKS concepts with hands-on Kubernetes questions on CertQuests.

Browse Kubernetes Certifications →