The Kubernetes and Cloud Native Security Associate (KCSA) is an entry-level certification from the Linux Foundation and CNCF that validates foundational knowledge of Kubernetes and cloud-native security. It's entirely multiple-choice, has no prerequisites, and serves as the knowledge-first stepping stone toward the hands-on CKS. If you work with Kubernetes clusters and want to prove you understand the controls that protect them, the KCSA is a practical and achievable starting point.
Exam Overview
| Detail | Value |
|---|---|
| Offered by | Linux Foundation / CNCF |
| Format | Multiple choice (~60 questions) |
| Duration | 90 minutes |
| Passing score | 75% |
| Prerequisites | None |
| Validity | 24 months |
| Retake policy | One free retake within 12 months |
The KCSA is entirely knowledge-based. There's no terminal, no live cluster. You need to understand how each security control works and why you'd choose it over alternatives. That's different from the CKS, where you're applying those controls against the clock on a real system.
Exam Domains
Six domains make up the KCSA curriculum:
| Domain | Weight |
|---|---|
| Kubernetes Cluster Component Security | 22% |
| Kubernetes Security Fundamentals | 22% |
| Kubernetes Threat Model | 16% |
| Platform Security | 16% |
| Overview of Cloud Native Security | 14% |
| Compliance and Security Frameworks | 10% |
The first two domains together account for 44% of the exam. Nail cluster components and security fundamentals and you're in a strong position going into the rest.
Core Concepts to Master
The Four C's of Cloud Native Security
The cloud-native security model organises defense into four layers: Cloud, Cluster, Container, and Code. Each layer has its own controls, and a weakness in any layer can compromise the others. The exam tests whether you can reason about which controls belong to which layer and what threats they address. This framework shows up directly in the "Overview of Cloud Native Security" domain, but it also provides useful context for questions across every other domain.
Cluster Component Security
You need to know how each control plane component can be hardened:
- API server: disable anonymous auth, use RBAC, enable audit logging, set
--authorization-modeappropriately - etcd: encrypt at rest with
--encryption-provider-config, restrict access to the API server only - kubelet: set
--anonymous-auth=false, use certificate-based authentication, use--authorization-mode=Webhook - Scheduler and controller-manager: bind to localhost, enforce TLS
Questions in this domain often ask why a particular flag matters or what attack vector opens if you skip it. Focus on the reasoning, not just the flag names.
Pod Security Standards
Pod Security Standards (PSS) replaced PodSecurityPolicy in Kubernetes 1.25. There are three levels: Privileged (no restrictions), Baseline (blocks known privilege escalation vectors), and Restricted (heavily locked down, current best practice). Namespaces enforce these via labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/enforce-version: latest
Know the difference between enforce, warn, and audit modes. enforce blocks the pod. warn allows it but surfaces a warning. audit logs the violation without blocking or warning.
RBAC and Least Privilege
RBAC controls who can do what in the cluster. You should know Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings, and understand when a namespace-scoped Role is appropriate versus a cluster-scoped ClusterRole.
Service accounts deserve extra attention. Many workloads mount tokens they don't use, which creates unnecessary API access. Setting automountServiceAccountToken: false in the pod spec is a simple, low-cost hardening step that the exam rewards you for knowing.
Admission Controllers
Admission controllers intercept API requests after authentication and authorisation. Mutating webhooks run first and can modify objects; validating webhooks run after and can reject them. Key controllers to know:
NodeRestriction: limits what kubelets can modify on their own node objectsAlwaysPullImages: forces image pulls, preventing use of cached images from other tenantsPodSecurity: enforces Pod Security Standards at the namespace level
One subtle point: mutating webhooks run before validating webhooks. A mutating webhook that injects a privileged sidecar after a PSS check can create a policy gap, which is why newer versions re-evaluate PodSecurity after mutation.
Network Policies
By default, all pods can reach all other pods in a cluster. NetworkPolicies let you restrict this, but they require a CNI plugin that enforces them. Flannel doesn't. Calico, Cilium, and Weave Net do.
Policies are additive: a pod with no NetworkPolicy is unrestricted, and you can't "deny" with a single rule. To lock a namespace down, start with a default-deny policy that selects all pods and specifies no ingress or egress rules, then layer in explicit allow rules for the traffic you need.
Supply Chain Security
This domain covers what happens before code reaches your cluster. Topics include:
- Scanning container images for CVEs (Trivy, Grype)
- Signing and verifying images (Cosign / Sigstore)
- Generating and consuming software bills of materials (SBOMs)
- Static analysis of Kubernetes manifests (Kubesec, KubeLinter)
- Admission policies that block unsigned or non-compliant images at deploy time
Compliance Frameworks
The KCSA expects familiarity with three key frameworks: the CIS Kubernetes Benchmark (practical hardening controls for clusters), NIST SP 800-190 (application container security guidance from the US government), and the CNCF Cloud Native Security Whitepaper (principles and patterns for cloud-native environments). You don't need to memorise control numbers, but you should know what each framework covers and who it's aimed at.
Common Exam Traps
A few patterns catch candidates off guard.
Confusing PSP with PSS. PodSecurityPolicy was deprecated in 1.21 and removed in 1.25. Questions about current recommended pod security approaches point to Pod Security Standards, not PSP.
Getting mutation and validation order wrong. Mutating webhooks run before validating webhooks. Know this ordering, know why it matters for security.
Assuming NetworkPolicies are universal. They depend on your CNI plugin. This is a common distractor in questions about why a NetworkPolicy "isn't working."
Underestimating the compliance domain. At 10% it's easy to skip. Don't. A few compliance questions can make the difference between passing and a retake.
Overlooking etcd. etcd stores all cluster state, including secrets. It's one of the highest-value targets in a Kubernetes cluster. Encryption at rest and strict access controls are required, not optional.
Study Plan
| Week | Focus |
|---|---|
| 1 | Exam domains overview; the four C's; cluster component hardening |
| 2 | RBAC, Pod Security Standards, admission controllers |
| 3 | Network policies, secrets management, supply chain security |
| 4 | Platform security, threat model, compliance frameworks |
| 5 | Practice exams, review weak areas, aim for 80% or above before sitting |
Four to five weeks is enough for most candidates with Kubernetes experience. If you're newer to Kubernetes, add a week at the start to get comfortable with the cluster architecture before going deep on security specifics.
Recommended Resources
- KCSA Exam Specification — the official curriculum is your ground truth
- Kubernetes Security Documentation — covers PSS, RBAC, admission controllers, and network policies
- CNCF Cloud Native Security Whitepaper — required reading for the compliance domain
- Kubernetes Security Checklist — a solid revision reference for cluster hardening topics
Final Thoughts
The KCSA fills a real gap. Most Kubernetes certifications are hands-on and assume you're already operating clusters in production. The KCSA is for people who need to demonstrate security awareness before they've had the chance to harden production clusters themselves. It's a strong fit for developers who deploy to Kubernetes, platform engineers early in their security journey, and security professionals who need to understand what these controls actually do.
Build your conceptual foundation, drill the weak spots, and test yourself under realistic conditions before you sit the real exam. KCSA Practice Exams are designed to match the domain weighting and question style of the real exam, with detailed explanations that help you understand the why behind every answer.