Key takeaways
- Cluster Component Security and Security Fundamentals are 22% each: know every control plane and node component and the controls around it.
- The 4Cs (cloud, cluster, container, code) are layers: a control at one layer cannot fix a gap at another.
- Threat model questions describe an attack and ask which category or control applies; learn the seven listed threat areas by example.
- KCSA is about knowing which control fits; CKS is about configuring it. Study the purpose of each control, not its YAML.
On this page
KCSA at a glance
The exam has 60 questions in 90 minutes, a 75% pass mark, a $250 list price and 2-year validity. Like every Linux Foundation multiple-choice exam it is proctored online and allows no documentation. The six domains below are quoted from the CNCF curriculum PDF with the weights from the official certification page.
| Domain | Weight | Curriculum topics |
|---|---|---|
| Overview of Cloud Native Security | 14% | The 4Cs, cloud provider and infrastructure security, controls and frameworks, isolation techniques, artifact repository and image security, workload and application code security |
| Kubernetes Cluster Component Security | 22% | API server, controller manager, scheduler, kubelet, container runtime, kube-proxy, Pod, etcd, container networking, client security, storage |
| Kubernetes Security Fundamentals | 22% | Pod Security Standards, Pod Security Admission, authentication, secrets, isolation and segmentation, audit logging, network policy |
| Kubernetes Threat Model | 16% | Trust boundaries and data flow, persistence, denial of service, malicious code execution, attacker on the network, access to sensitive data, privilege escalation |
| Platform Security | 16% | Supply chain security, image repository, observability, service mesh, PKI, connectivity, admission control |
| Compliance and Security Frameworks | 10% | Compliance frameworks, threat modelling frameworks, supply chain compliance, automation and tooling |
The 4Cs: layers, not a checklist
The 4Cs of cloud native security are cloud, cluster, container and code. Each layer sits inside the one before it: code runs in containers, containers run in a cluster, and the cluster runs on cloud or data-centre infrastructure. The model is useful in the exam because many questions describe a weakness and ask where the fix belongs. A strong admission policy does not protect an etcd that is reachable from the internet, and a hardened node does not stop an application from leaking its own credentials.
- Cloud: the infrastructure and its access controls, including who can reach the control plane and etcd over the network.
- Cluster: the Kubernetes components and their configuration, plus the workloads’ permissions inside the cluster.
- Container: images, the runtime, and what a container is allowed to do on its node.
- Code: the application itself, its dependencies and how it handles secrets and input.
Cluster component security: one control per component
This domain is 22% of the exam and has the longest topic list. A good way to study it is to make a table with one row per component and three columns: what it does, how it is reached, and the main controls that protect it. Questions often describe a component in one sentence and ask which risk or control applies, so the row you wrote is the answer you need.
| Component | Why it matters | Controls to know |
|---|---|---|
| API server | Every request to the cluster passes through it | Authentication, authorization (RBAC), admission control, TLS, audit logging |
| etcd | Holds all cluster state, including Secrets | Network isolation, TLS between peers and clients, encryption at rest |
| kubelet | Runs Pods on each node and exposes an API | Authentication and authorization of its API, no anonymous access |
| Scheduler and controller manager | Decide placement and reconcile objects | Least-privilege credentials, secure ports only |
| Container runtime | Starts containers on the node | Restricting privileged containers, sandboxed runtimes where needed |
| kube-proxy and networking | Route Service traffic between Pods | NetworkPolicy support in the CNI, encrypted Pod-to-Pod traffic where required |
Security fundamentals: the controls you will see named
Security Fundamentals is also 22%. It covers the built-in controls every cluster has. Know the three Pod Security Standards levels (privileged, baseline and restricted) and that Pod Security Admission enforces them per namespace; the difference between authentication and authorization; what a Secret is and is not (base64 encoding is not encryption); what audit logging records; and what a NetworkPolicy can select and block.
- Pod Security Admission modes: enforce, audit and warn, set by namespace labels.
- RBAC: Roles and ClusterRoles grant permissions; bindings attach them to users, groups or ServiceAccounts.
- Secrets: protect them with RBAC and encryption at rest; mounting them is not the same as exposing them in environment variables.
- Audit logs: who did what to which resource and when, at the level the audit policy sets.
- NetworkPolicy: default-allow until a policy selects a Pod; then only the allowed traffic passes.
The threat model in the terms questions use
The Kubernetes Threat Model domain (16%) lists seven areas. Questions usually describe an attack in a sentence and ask which category it belongs to, or which control would have limited it. Learn each area through one concrete example rather than a definition, and connect each example to the control that interrupts it. The trust boundaries topic is the frame for the rest: data crossing from the internet into a Pod, from a Pod to the API server, or from a node to etcd is where controls belong.
The examples are illustrations written for this guide, not exam questions. They show the shape of reasoning the domain needs: name the threat, then the layer, then the control.
| Threat area | Example | Controls that limit it |
|---|---|---|
| Persistence | An attacker creates a CronJob or a DaemonSet that keeps running after the original Pod is gone | RBAC limits on workload creation, admission policies, audit log review |
| Denial of service | A workload without limits exhausts node memory | Resource requests and limits, ResourceQuota, LimitRange |
| Malicious code execution | A compromised image runs a miner inside a container | Image provenance, admission control, runtime detection, restricted Pod security |
| Attacker on the network | A Pod reaches services it never needs | Default-deny NetworkPolicy, mTLS through a service mesh |
| Access to sensitive data | A ServiceAccount token reads every Secret in a namespace | Least-privilege RBAC, encryption at rest, short-lived tokens |
| Privilege escalation | A privileged container mounts the host filesystem | Pod Security Standards restricted level, dropping capabilities, no hostPath |
Platform security and compliance
Platform Security (16%) moves from the cluster to what surrounds it: the supply chain that builds images, the registry that stores them, observability, service mesh, PKI and admission control. Compliance and Security Frameworks (10%) asks what frameworks are for. Expect to tell a compliance framework, which defines requirements an auditor checks, from a threat modelling framework, which helps you find what could go wrong.
- Supply chain: signing images, generating an SBOM, and only admitting images from trusted registries.
- PKI: Kubernetes components authenticate each other with certificates; know what a certificate authority does for the cluster.
- Service mesh: mutual TLS between workloads and identity-based authorization.
- Automation and tooling: benchmarks and scanners that check configuration against a standard, run continuously rather than once.
A four-week KCSA plan
The plan follows the weights, puts the two largest domains early, and leaves the last week for mixed practice and a timed mock. Each day starts with due reviews from the previous days, so the missed questions come back while you are still on the topic.
If you already passed KCNA, the first week can be shorter. If you have never read the Kubernetes security documentation, read its overview pages before week one.
| Week | Focus | Practice |
|---|---|---|
| 1 | The 4Cs and cluster component security | Build the component table above; focus mode on Cluster Component Security |
| 2 | Security fundamentals: Pod security, RBAC, Secrets, audit, NetworkPolicy | Focus mode on Security Fundamentals; read each explanation twice |
| 3 | Threat model, platform security and compliance | Write one example per threat area; mixed practice on the three domains |
| 4 | Weakest domain, then mixed review | Two timed mock exams; book when every domain is above the pass mark |
Frequently asked questions
Is KCSA harder than KCNA?
It is narrower but deeper. KCNA covers the whole cloud native landscape at a basic level; KCSA assumes that vocabulary and asks which security control, component setting or framework fits a described situation. Most people find KCSA harder if they have never thought about Kubernetes from an attacker’s point of view.
Do I need to know how to configure the controls?
Not at the level of writing manifests under time pressure; that is CKS. KCSA questions ask what a control does, which layer it belongs to and which threat it mitigates. Knowing roughly what a NetworkPolicy, a Pod Security Standard or an audit policy looks like still helps you rule out wrong options.
What are the 4Cs of cloud native security?
Cloud, cluster, container and code: four layers, each building on the one outside it. The KCSA curriculum lists the 4Cs as the first topic of its Overview of Cloud Native Security domain. The practical lesson is that security at an inner layer cannot make up for a weak outer layer.
Is KCSA required before CKS?
No. The only official prerequisite for CKS is a passed CKA. KCSA's own prerequisite field reads: None. KCSA is still useful preparation, and under the CARE program passing CKS renews KCSA.
Which domain do candidates under-prepare?
Compliance and Security Frameworks is the smallest domain at 10%, and it is easy to skip. It is also the one where questions hinge on knowing what a framework is for, such as threat modelling versus compliance, so a few hours of reading pays back quickly.
How many KCSA questions does GoldenKube have?
378, each with an explanation, filed under the official domains so you can focus on one at a time. The first 10 answers need no account.
Is KCSA hands-on?
No. KCSA is multiple-choice and no resources are allowed during the exam. A small local cluster is still useful for the security fundamentals domain: applying a NetworkPolicy, a Pod Security level or an RBAC Role yourself makes the options much easier to separate.
Sources
Every exam fact on this page comes from these pages, read on the date shown.
- Linux Foundation: Kubernetes and Cloud Native Security Associate (KCSA) certification page, checked
- CNCF curriculum: KCSA Curriculum (PDF), checked
- Multiple-choice exam instructions, Linux Foundation certification docs, checked
- Multiple-choice exam FAQ, Linux Foundation certification docs, checked
- Resources allowed during the exam, Linux Foundation certification docs, checked
- Kubernetes documentation: Security overview, checked