Certifications guide

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

KCSA is a 90-minute, multiple-choice exam on Kubernetes security — the knowledge counterpart to the hands-on CKS. Its six domains are unusually evenly weighted, so there is no corner of it you can afford to skip.

read
8 min read
read
last updated
August 2026
last updated
Overview

What KCSA actually certifies

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.

Breakdown

The exam at a glance

One exam, six domains, and a study plan that genuinely spans four decks — for the reason set out below.

KCSA

Kubernetes and Cloud Native Security Associate

AssociateMultiple choice · online proctored · 90 min · $250Prereq: None

<strong>Cluster Component Security (22 %)</strong> walks the components one by one — API server, controller manager, scheduler, kubelet, container runtime, kube-proxy, Pod, etcd, container networking, client security and storage. <strong>Security Fundamentals (22 %)</strong> is Pod Security Standards and Admission, authentication and authorization, Secrets, isolation and segmentation, audit logging and network policy. <strong>Threat Model (16 %)</strong> covers trust boundaries and data flow, persistence, denial of service, malicious code execution, an attacker on the network, access to sensitive data and privilege escalation. <strong>Platform Security (16 %)</strong> is supply chain, image repositories, observability, service mesh, PKI, connectivity and admission control. <strong>Overview (14 %)</strong> is the 4Cs, cloud and infrastructure security, controls and frameworks, isolation techniques, artifact and image security. <strong>Compliance (10 %)</strong> is compliance and threat-modelling frameworks, supply chain compliance, and automation.

Choose this if…

  • You run clusters and want the security model named rather than absorbed by osmosis
  • You are heading for CKS and want the concepts before the terminal
  • You are a security engineer meeting Kubernetes as one more system to assess
Check which framing you are studying

The exam names the 4Cs; the upstream docs no longer do

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.

Where the marks are

Nothing dominates, so plan by your weakest domain

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.

What this study plan covers

Four decks, because the blueprint really is that wide

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.

KCSA or CKS

One asks whether you know it, the other whether you can do it

The two Kubernetes security credentials are not competitors and not really a ladder either. KCSA is multiple-choice and has no prerequisites: it tests whether you can reason about the security model, the threat model and the frameworks around them. CKS is performance-based and requires an active CKA, and tests whether you can harden and fix a cluster in a terminal under time pressure.

If you are aiming at CKS eventually, KCSA first is a reasonable order — the vocabulary and the threat model transfer completely, and the concepts are cheaper to learn away from a terminal. If you are a security engineer who assesses systems rather than operates them, KCSA may be the only one of the two you ever need. The Kubernetes certification guide puts both in context alongside CKA, CKAD and KCNA.

FAQ

Common questions

What are the KCSA exam domains and their weights? +

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 %. It is the flattest blueprint of the CNCF associate exams.

Is the KCSA exam hands-on like the CKS? +

No. KCSA is an online, proctored, multiple-choice exam of 90 minutes with no terminal, and it has no prerequisites. CKS is the performance-based Kubernetes security exam and requires an active CKA.

What are the 4Cs of cloud native security? +

Cloud, Cluster, Container and Code — nested layers where each depends on the security of the ones outside it, so hardened application code cannot compensate for an exposed cluster or cloud account. The KCSA curriculum names them, although current kubernetes.io documentation organises the same material by lifecycle phase instead.

Do I need Kubernetes experience before KCSA? +

There are no formal prerequisites, but the Cluster Component Security domain walks through the API server, kubelet, etcd, kube-proxy and the rest one at a time, so a working mental model of how a cluster fits together makes the whole exam far easier.

How much does KCSA cost and how long is it valid? +

The exam alone is $250 and includes one free retake, with a 12-month window in which to sit it. The certification is valid for two years. Bundles with a Linux Foundation subscription are sold at a higher price point.

Why does the study plan span several decks? +

Because the blueprint does. Three domains are cluster-internal and sit in the Kubernetes Hardening deck, while Platform Security explicitly names admission control and observability — the OPA and Falco decks — and both Platform Security and Compliance name supply chain and image repositories, which is the Supply Chain Security deck.

Is KCSA worth taking if I already hold CKA? +

They overlap less than you would expect. CKA is about operating a cluster and touches security as one duty among many; KCSA is about the security model and the threat model specifically, including framework and compliance vocabulary that CKA never asks for.

Start with the domain you would fail today

Plant your first seed today. On a blueprint this evenly weighted, ten minutes a day on your weakest domain is worth more than another pass over the parts you already know.

Start learning free