KCSA: The Kubernetes and Cloud Native Security Associate Exam, Domain by Domain

The Kubernetes and Cloud Native Security Associate is the CNCF and Linux Foundation credential for engineers who secure clusters, positioned below the hands-on CKS. It is an online, proctored, multiple-choice exam of 90 minutes, priced at $250 for the exam alone, with no prerequisites, one free retake, a 12-month eligibility window and a certification valid for two years. Neither a question count nor a pass mark is published.

Six domains: Kubernetes Cluster Component Security 22 %, Kubernetes Security Fundamentals 22 %, Kubernetes Threat Model 16 %, Platform Security 16 %, Overview of Cloud Native Security 14 % and Compliance and Security Frameworks 10 %. That is the flattest blueprint of the CNCF associate exams — where OTCA puts 46 % in one domain and CGOA half in two, KCSA spreads the marks across six, and the smallest is still a tenth of the paper.

Gnoseed is not affiliated with CNCF or the Linux Foundation and neither sells nor proctors this exam; it offers free spaced-repetition practice on the published curriculum. Verify the figures above against the official exam page before you book.

The blueprint's very first competency is the 4Cs of Cloud Native Security — Cloud, Cluster, Container and Code, nested so that each layer depends on the ones outside it. It is a useful model and it is still what the exam names.

It is also no longer how kubernetes.io presents the subject. The current Cloud Native Security and Kubernetes page organises the same ground by lifecycle phase — develop, distribute, deploy and runtime, with runtime splitting into access, compute and storage. A candidate who prepares only from today's upstream documentation will not meet the 4Cs there at all, which is exactly the sort of gap that costs marks on a domain worth 14 %.

So learn both framings and keep them straight: the 4Cs are the layered view the exam asks about, and the lifecycle phases are the vocabulary the current docs use for the same concerns. Neither is wrong; they answer different questions about the same system.

With 22, 22, 16, 16, 14 and 10 per cent there is no single place to concentrate, and the usual advice — start with the biggest domain — buys you very little. The better strategy is to find the domain you would score worst on today, because on a flat blueprint that is where the marginal marks are.

For most practitioners that domain is the Threat Model at 16 %. Cluster hardening is something you have done; naming the trust boundary you crossed while doing it is not. The competencies are explicitly adversarial — trust boundaries and data flow, persistence, denial of service, malicious code execution, an attacker on the network, access to sensitive data, privilege escalation — and they reward being able to say why a control exists, not just which flag turns it on.

Cluster Component Security at 22 % is the other one people misjudge, because it goes component by component rather than concept by concept. The kubelet is the classic example: its HTTPS endpoint treats unauthenticated requests as anonymous and its default authorization mode is AlwaysAllow, so anything that can reach the port can call it — and nodes/proxy in RBAC reaches every kubelet API, including executing in any container on that node. That is the level of specificity the domain is written at.

This is the one exam on this site whose study plan is a cluster of decks rather than a single track, and it is worth saying why rather than leaving you to infer it from the list. Three of the six domains are cluster-internal and live in the Kubernetes Hardening deck, which now carries modules written against this blueprint: Cloud Native Security Model for the 4Cs, lifecycle phases, isolation techniques and the framework vocabulary; Cluster Component Security for the kubelet, controller manager, PKI, service account tokens and the components' own permissive defaults; and Kubernetes Threat Model for trust boundaries, persistence, denial of service and privilege escalation. The existing modules cover authentication, authorization and audit, plus Pod Security Standards and runtime hardening.

The other three domains genuinely belong elsewhere. Platform Security names admission control, which is the OPA and Gatekeeper deck, and observability, which is where runtime threat detection with Falco sits. Supply chain and image repositories — in both the Platform Security and Compliance domains — are the Supply Chain Security deck, which goes considerably deeper than the exam needs on SBOMs, provenance and VEX.

One caveat on scope, stated precisely because it is easy to overstate. The hardening deck's original modules were written against the NSA and CISA hardening guidance, and their subject matter is the Security Fundamentals domain — authentication, authorization, audit logging, Pod Security Standards, Secrets and runtime hardening are 22 % of the exam and the deck covers them. What is off-blueprint is the occasional framing: cards phrased as “what does the NSA guide recommend”, that document's insider-threat taxonomy, and its 2021-era advice about the API server's long-removed insecure port. Read those for the practice they describe, not because a question will name the source.