Passed CKS

certification - This article is part of a series.

Part : This Article

Part : Państwowy egzamin B1

Part : Passed KCNA

I passed the Certified Kubernetes Security Specialist (CKS) exam.

I passed CKS on my second attempt. I came in with CKAD and CKA already done, but CKS still felt different. On my first attempt, I spent too much time early and did not even finish reading all tasks before the timer ended. The focus is less about creating workloads and more about reducing attack surface and verifying controls under time pressure.

Exam format
#

The exam is online, proctored, and performance-based. The duration is 120 minutes. The certification is valid for 2 years. You must have passed CKA before taking CKS, but an active CKA is not required. As of 2026-02-21, the official exam environment is based on Kubernetes v1.34.

Domains
#

The CKS blueprint is split into six domains with the following weights:

pie showData
  title CKS domains (weights)
  "Cluster Setup" : 15
  "Cluster Hardening" : 15
  "System Hardening" : 10
  "Minimize Microservice Vulnerabilities" : 20
  "Supply Chain Security" : 20
  "Monitoring, Logging and Runtime Security" : 20

A short practical view of each area:

Cluster Setup (15%): NetworkPolicy basics, CIS checks, ingress TLS, and binary verification.
Cluster Hardening (15%): RBAC scope reduction, service account hygiene, API access limits, and upgrade hygiene.
System Hardening (10%): host footprint minimization, least privilege access, and kernel controls like AppArmor and seccomp.
Minimize Microservice Vulnerabilities (20%): Pod Security standards, secret handling, isolation patterns, and pod traffic encryption.
Supply Chain Security (20%): image hygiene, SBOM, signing and validation, and static checks of workloads and images.
Monitoring, Logging and Runtime Security (20%): detection signals, runtime immutability, and audit log analysis.

Preparation
#

Official references I used:

Hands-on and study materials that helped me:

Personal notes
#

These topics repeated in my drills and simulator sessions:

Falco: fixing broken rules and writing targeted detections.
Trivy and SBOM: generating outputs and triaging findings quickly.
kube-bench and CIS: reading findings fast and applying focused remediations.
Kubernetes audit logging: configuring policy, enabling audit, and validating events in logs.
Admission control in Kubernetes: understanding built-in admission controllers and checking when and why they are applied.
Cluster and node upgrades with kubeadm: planning version steps, upgrading control plane and workers, and verifying node state.
RuntimeClass and gVisor: basic setup and verification.
Istio mTLS and sidecar injection: enough to enforce policy, not over-engineer.
Runtime and daemon config changes, including Docker-related settings.
Before editing manifests or config files, I create a backup copy first, so rollback is immediate if something goes wrong.

Speed and sequencing are everything. In my experience, CKS isn’t “conceptually hard” in the way people often describe it. If you already run Kubernetes in real environments, most topics are familiar and the controls are straightforward. The real difficulty is the format: 120 minutes, sometimes ambiguous wording, and a higher task density than CKAD/CKA.

On my first attempt, I lost to time management. I went too deep too early and didn’t even finish reading all tasks before the timer ended. That attempt was still valuable-it taught me what the exam is actually asking for and where I was wasting minutes.

For the second attempt, I switched to a strict pass strategy: quick scan first, complete the highest-confidence items immediately, then return to the deeper tasks. Under pressure, context switching is expensive, so I handled tasks one by one to completion instead of bouncing between them. For disruptive steps (for example, restarting the API server), I marked them, moved on, and returned during a final verification pass to reduce blast radius and avoid breaking momentum.

Not passing on the first try is common with this exam format. For me, it was a signal to fix the process, not a reason to stop.

Why it matters
#

CKS is a strong check that you can apply Kubernetes security controls quickly, not just describe them. In real platform work this translates directly to incident response, safer defaults, and faster security reviews for delivery teams. If the first attempt does not work out, the right move is to refine your method and come back with better pacing.