KCSA Certification Study Guide 2026: Kubernetes and Cloud Native Security Associate

The KCSA (Kubernetes and Cloud Native Security Associate) is the CNCF's entry-level security certification. It is a multiple-choice exam that checks whether you understand the fundamentals of securing container-based applications and cloud native environments: how Kubernetes enforces access, how containers are isolated, how software reaches production safely, and how you notice when something goes wrong. This guide covers the six exam domains and their weights, what to study in each, and how it fits next to the CKA, CKAD, and CKS.

KCSA Exam Domains and Weights

The KCSA has six domains, and no single one dominates the exam. These weights come from the CNCF's KCSA curriculum.

Several third-party KCSA guides I checked while writing this list a different six-domain split, with names like "Kubernetes Cluster Component Security" and "Kubernetes Threat Model" and a different set of weights. That does not match the CNCF curriculum page above. The CNCF page publishes the domain names and weights only, with no version number or date, so I cannot tell you whether the other guides describe an older release of the exam or are simply wrong. Either way, plan from the CNCF table, and treat any guide whose domains do not match it with suspicion.

Because the official outline stops at domain names, the sections below describe what each domain covers in practice. They are my reading of the domain titles and the Kubernetes security model, not a copy of an official topic list.

Exam logistics are less settled than the curriculum. Prep sites commonly report about 60 questions in 90 minutes, a pass mark around 75%, a fee near $250 that often includes one retake, and a validity period of two years. I could not confirm any of these against the Linux Foundation's own page, and the sources disagree on details such as validity, so read the official KCSA certification page before you book.

Cloud Native Fundamentals (16%)

This domain is about the model that everything else hangs on. The anchor is the 4Cs of cloud native security: Cloud, Cluster, Container, and Code. Each layer builds on the one outside it, so a weakness in an outer layer undermines the inner ones regardless of how careful you were inside.

What to be able to explain:

• Why the 4Cs are layered, and which layer a given control belongs to.
• The shared responsibility split between a cloud provider and you.
• How a Kubernetes cluster is put together (control plane, nodes, kubelet, API server, etcd) at the level needed to say what each part exposes.
• Why cloud native changes the security picture: ephemeral workloads, declarative config, and many small services.

Kubernetes Security Fundamentals (20%)

This is the largest domain, tied with containers. It covers the controls Kubernetes itself gives you.

• Authentication and authorization. Know how the API server decides who you are and what you may do, and that RBAC is deny by default. kubectl auth can-i is the fastest way to build intuition:

kubectl auth can-i list secrets --namespace prod --as system:serviceaccount:prod:app

• Pod Security Standards. Three levels (privileged, baseline, restricted), enforced per namespace through Pod Security Admission:

kubectl label namespace prod pod-security.kubernetes.io/enforce=restricted

• NetworkPolicy. Pods accept all traffic by default. A policy selecting a pod flips that pod to deny anything not explicitly allowed, and it only works if your network plugin enforces it.
• Secrets. A Kubernetes Secret is base64-encoded, not encrypted. Encryption at rest is a separate API server setting, and the exam likes this distinction.
• Admission control. Where policy engines such as Kyverno or OPA Gatekeeper plug in to validate or mutate objects before they are stored.

My practical advice: run each of these once on a throwaway cluster. A question about restricted versus baseline, or about why a NetworkPolicy had no effect, is much easier when you have watched it happen. Our Kubernetes production best practices guide covers RBAC, network policies, and pod security in a way that maps well to this domain.

Container Security Fundamentals (20%)

Containers are processes with isolation features, not small virtual machines, and this domain tests whether you understand where that isolation comes from and where it stops.

• Namespaces and cgroups: what they isolate and what they do not.
• Running as non-root, dropping Linux capabilities, read-only root filesystems, and why privileged containers defeat most of this.
• Image hygiene: minimal base images, pinning, and not baking secrets into layers.
• Container runtimes and the sandboxing options that add a stronger boundary than the default.

If you build images yourself, our Docker production containerization guide covers the image-level practices that show up here, and the Linux server hardening guide explains the host layer underneath containers.

Secure Software Supply Chain (16%)

This domain asks how code becomes a running workload and whether you can trust each step. Expect questions that name a problem and ask which control addresses it.

• Scanning images and dependencies for known vulnerabilities, for example with Trivy:

trivy image --severity HIGH,CRITICAL registry.example.com/app:1.4.2

• Signing and verification so the cluster only runs images you built. Sigstore's cosign is the common tool.
• SBOMs (software bills of materials) that list what is inside an image, in formats such as SPDX or CycloneDX.
• Provenance and build integrity, including the idea behind SLSA levels.
• Registries and admission policy that block unsigned or non-compliant images from being deployed.

In the clusters I have worked on, scanning is the easy part and verification at deploy time is the part teams skip. The exam rewards knowing the difference.

Monitoring, Logging and Runtime Security (12%)

The smallest domain, but easy points if you know the vocabulary.

• Kubernetes audit logs: who called the API, on what, with what result.
• Runtime detection: tools that watch syscalls and flag unexpected behaviour. Falco is the CNCF example.
• The difference between prevention (admission, policy) and detection (runtime, logs), and why you need both.
• Where logs should go so an attacker with node access cannot quietly erase them.

General Security Knowledge (16%)

This domain is not Kubernetes-specific. It tests that you have general security literacy.

• Core principles: least privilege, defence in depth, and zero trust.
• Threat modelling approaches such as STRIDE, and frameworks such as MITRE ATT&CK.
• Common attack patterns, vulnerability management, and compliance basics, including benchmarks like the CIS Kubernetes Benchmark.
• Cryptography basics: TLS, mTLS, and certificate handling.

If this is your weakest area, our cloud security threats overview is a reasonable primer on the attack landscape.

A 3-Week KCSA Study Plan

This assumes you already run Kubernetes and can spend about 5 hours a week. Add a week if you are newer to it.

Reread the CNCF curriculum table on day one and again in week three. The weights tell you how much of your score each area carries.

Is the KCSA Worth It?

It is worth taking if you want a vendor-neutral security credential, if you are collecting the Kubestronaut set (the KCNA, KCSA, CKA, CKAD, and CKS), or if you work with Kubernetes and have never been tested on the security side of it. The study process fills gaps even for experienced engineers, because day-to-day work rarely touches supply chain controls or threat modelling.

It is not a substitute for experience. A multiple-choice associate exam shows you know the concepts, not that you can lock down a cluster, and a hiring manager will weigh a hardening project above it. If your goal is hands-on Kubernetes security, treat the KCSA as the warm-up and the CKS as the real test.

Practice Kubernetes Security Hands-On With CloudaQube

The controls in this exam stick when you run them. CloudaQube's courses and labs let you work through cloud and container security without building a lab environment first. Start with the free security fundamentals course and move into the Kubernetes material from there.