KCSA — the exam

The Kubernetes and Cloud Native Security Associate (KCSA) is the security-flavored sibling to KCNA on this course's associate rung — entry-level, knowledge-based, multiple-choice, no cluster and no kubectl required. It doesn't ask whether you can fix a misconfiguration under a clock; it asks whether you know where the attack surface is at all: which cluster components an attacker wants, what the built-in security primitives actually enforce, how an intrusion moves once it has a foothold, and how the 4Cs model nests one layer of trust inside another. This page is the KCSA hub for this course — who should sit it, the CNCF's official six-domain breakdown reproduced exactly as published, the 4Cs explained with a schematic, worked examples per domain, and where in this course to actually study each one before you book a seat.

What KCSA actually is, and who it's for

☺ Like you're 10: A multiple-choice quiz about how clusters get broken into, and what stops it — not a test where you fix anything yourself.

KCSA is the CNCF and Linux Foundation's entry-level, knowledge-based security credential for Kubernetes: online, remote-proctored, multiple choice, with no live cluster and nothing to type into a terminal. It certifies security literacy — that you can name the trust boundaries in a cluster, recognize which defaults are dangerous, and describe what an attacker gains at each stage of a compromise. That's a different skill from operating a hardened cluster, and it changes how you study: instead of drilling commands, you build a map of the attack surface and ask, for every feature, what does misconfiguring this hand an attacker, and which layer does the fix belong to?

Who should sit it

• Platform engineers who own guardrails — if you write admission policy or answer "is this safe to run?" for other teams, KCSA formalizes the vocabulary you already use informally.
• SREs and operators inheriting someone else's cluster — a fast, structured way to know what to check before you trust what you've been handed.
• Developers and appsec engineers meeting Kubernetes from outside — enough of the security model to stop treating the cluster as a black box.
• Anyone warming up for CKS — see the certifications hub for how KCSA sits alongside KCNA at the base of this course's five-exam ladder.

What it deliberately does not test

Two things, and knowing them up front saves real study time. Remediation under a clock: you are never graded on cluster state, so memorizing every kube-apiserver flag isn't the assignment — knowing what those flags protect is. That hands-on layer belongs to CKS, which requires an active CKA first. And tool trivia: the curriculum names capability areas — "Admission Control," "Service Mesh," "Image Repository" — not specific products. Know what the category does before you memorize any one vendor's flags.

The official domains and their weights

☺ Like you're 10: Six parts, and they are not the same size — two chunks add up to almost half the whole test.

The domain names, percentages and competency lists below are transcribed from the CNCF's published Kubernetes and Cloud Native Security Associate (KCSA) Exam Curriculum — forty-two competencies across six domains, weights summing to exactly 100%, re-ordered heaviest-first (the official PDF uses its own layout order):

Eleven, seven, seven, seven, six and four competencies — 11 + 7 + 7 + 7 + 6 + 4 = 42 — across the six domains above, and that is the entire testable surface. It fits on one page, which is exactly the point of transcribing it here rather than pointing you at a PDF.

Where the weight really sits

44% is the two 22% domains — cluster components and the built-in security primitives — and both are enumerable lists: eleven named components, seven named primitives, each with a "what it exposes, what hardens it" pair. Finite lists are where you bank marks fastest.

The 16% domains reward different thinking. Kubernetes Threat Model isn't a feature list — it's attacker behavior, told as a story with seven named beats. Platform Security reaches into supply chain, PKI, service mesh and admission control — the most platform-engineering-flavored domain on the paper. Overview of Cloud Native Security at 14% is where the 4Cs model lives, and it's worth more than its weight suggests because that model organizes everything else on the exam. The 10% compliance domain is dry and cheap to secure if you don't leave it for the last night.

The 4Cs, explained properly

☺ Like you're 10: Four layers, each one only as safe as the layer around it — like a nesting doll where the outside doll cracking breaks every doll inside it too.

The first competency in Overview of Cloud Native Security hangs off one model: Cloud, Cluster, Container, Code — four nested layers, each one secured by the layer that contains it. Cloud is the infrastructure underneath everything: node images, IAM roles, the cloud metadata endpoint, the managed control plane if you're on a hosted offering. Cluster is Kubernetes itself: the API server, RBAC, admission control, etcd. Container is the image and its runtime isolation: what's baked into the image, and what seccomp, AppArmor or a sandboxed runtime restrict at the kernel boundary. Code is your application and its dependencies — the innermost layer, and the one furthest from the exam's attention because it's the one application security programs already cover.

The exam point is the direction of dependency: you cannot secure a container running on a compromised cluster, and you cannot secure a cluster running on compromised cloud infrastructure. Hardening works outside-in, and a control placed at the wrong layer is theater — a network policy inside the cluster does nothing about an over-permissioned IAM role one layer out. Isolation techniques, a separate competency under the same domain, runs down the identical ladder: namespaces and cgroups isolate processes; seccomp, AppArmor and SELinux restrict syscalls; sandboxed runtimes (gVisor, Kata) add a stronger kernel boundary; Kubernetes namespaces, node pools and separate clusters isolate tenants from each other. Know which layer each control actually operates at, because the exam likes to ask you to place one.

What you actually need to know, domain by domain

☺ Like you're 10: A list of parts that can be tricked, a couple of switches that stop most attacks, and a story about how a break-in actually spreads.

Cluster components — what each can be tricked into doing

Learn the 22% component domain as "what it exposes → what hardens it." This course covers the architecture underneath in full in Kubernetes architecture and control plane internals; the sibling Platform Engineering course goes further on the substrate framing in Kubernetes as the Platform Substrate.

Pod Security Standards vs. Pod Security Admission

Two different things, and the exam cares about the distinction. Standards (PSS) are three policy levels: privileged, baseline, restricted. Admission (PSA) is the built-in controller that enforces a level via namespace labels, in three independent modes: enforce (reject the object), audit (record the violation), warn (message the caller). Roll a new level out with warn and audit first; flip to enforce once nothing screams. This course's own admission-and-RBAC depth lives in RBAC & admission control.

# Namespace labels ARE the configuration — this is Pod Security Admission.
apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted    # record violations
    pod-security.kubernetes.io/warn: restricted     # warn at apply time
---
# A Pod that actually satisfies the "restricted" standard.
apiVersion: v1
kind: Pod
metadata: { name: checkout, namespace: payments }
spec:
  automountServiceAccountToken: false     # don't hand out a token nobody uses
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    seccompProfile: { type: RuntimeDefault }
  containers:
    - name: app
      image: registry.example.com/checkout@sha256:5f1a...   # digest, not a mutable tag
      securityContext:
        allowPrivilegeEscalation: false   # blocks setuid / file-capability escalation
        privileged: false
        readOnlyRootFilesystem: true
        capabilities: { drop: ["ALL"] }

PSA is deliberately coarse — namespace-wide, three levels, no exceptions. When you need "no latest tags" or "images only from our registry," you've left PSA for a policy engine — Kyverno or OPA/Conftest in the sibling DevSecOps course, both filed under the same Admission Control competency this exam names.

Network Policy, authentication and secrets

Kubernetes networking is flat by default: every Pod can reach every other Pod, in every namespace. That single default drives most of the "Attacker on the Network" threat-model competency. A NetworkPolicy is namespaced, additive — rules union, they never subtract — and only takes effect if your CNI actually implements it; on a CNI that ignores NetworkPolicy, a policy silently protects nothing. That's a favorite exam trap, and it's covered end to end in networking & the CNI.

# 1. Default-deny everything in the namespace, both directions.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny, namespace: payments }
spec:
  podSelector: {}                 # empty selector = every Pod in the namespace
  policyTypes: ["Ingress", "Egress"]
---
# 2. Then allow only what the app genuinely needs.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: checkout-allow, namespace: payments }
spec:
  podSelector:
    matchLabels: { app: checkout }
  policyTypes: ["Ingress", "Egress"]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: gateway }
      ports: [{ protocol: TCP, port: 8080 }]
  egress:
    - to:
        - podSelector:
            matchLabels: { app: orders-db }
      ports: [{ protocol: TCP, port: 5432 }]
    - to:                          # DNS, or nothing will resolve
        - namespaceSelector:
            matchLabels: { kubernetes.io/metadata.name: kube-system }
      ports: [{ protocol: UDP, port: 53 }, { protocol: TCP, port: 53 }]

On authentication: Kubernetes has no built-in User object. Humans authenticate via client certificates, OIDC, or an exec-credential proxy; workloads authenticate with short-lived, audience-bound ServiceAccount tokens. Authentication answers who, authorization (RBAC, Node, Webhook) answers what they may do, admission control answers is this specific object acceptable — always in that order, and the exam expects you to know the order.

On secrets: a Kubernetes Secret is base64-encoded, not encrypted — a costume, not a lock. It lives in etcd, readable by anyone with get secrets RBAC in the namespace, and isn't encrypted at rest unless you configure it. The fixes: an EncryptionConfiguration, tight RBAC, and often an external store synced in — see the sibling Platform Engineering course's Secrets & Workload Identity for the fuller pattern.

# Encryption at rest — API server flag: --encryption-provider-config
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources: ["secrets"]
    providers:
      - kms:                       # a KMS/HSM provider is the strong option
          apiVersion: v2
          name: cluster-kms
          endpoint: unix:///var/run/kmsplugin/socket.sock
      - identity: {}               # plaintext fallback — MUST be last, or nothing encrypts
---
# Audit policy: prove who did what. Levels: None, Metadata, Request, RequestResponse.
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages: ["RequestReceived"]
rules:
  - level: RequestResponse         # full bodies for the crown jewels
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  - level: Metadata                # who/what/when for everything else

Threat model, supply chain and compliance

The Threat Model domain names seven attacker goals, best learned as one continuous story rather than seven flashcards. An attacker gets malicious code execution in a container, hunts for access to sensitive data — the mounted token, environment variables, the cloud metadata endpoint — tries privilege escalation via a privileged container or a hostPath mount, moves sideways as an attacker on the network because nothing was default-deny, establishes persistence with a rogue CronJob or a mutating webhook, and failing all of that, falls back to denial of service. Every control covered above breaks exactly one hop in that chain; trust boundaries and data flow is the framing competency — the discipline of drawing where one hop becomes the next. This course walks that exact chain, exploit to alert, in Security: Defense in Depth — the single best-matched page in this course for the whole Threat Model domain.

Platform Security is where the exam gets closest to real platform-engineering practice. Supply chain: build reproducibly, generate an SBOM, scan for known CVEs, sign the image, and — the step people forget — verify the signature at admission so an unsigned image cannot even start. The sibling DevSecOps course covers this at full depth: Container & supply-chain security for the pattern, Trivy for scanning, Sigstore & cosign for signing. PKI and connectivity: cert-manager issuing certificates, and mutual TLS from a mesh's sidecar proxies — see this course's own service mesh fundamentals. Observability as a security control: Falco for runtime detection, audit logs shipped somewhere tamper-evident.

Compliance and Security Frameworks: compliance frameworks (the CIS Kubernetes Benchmark, NIST SP 800-190, PCI DSS, SOC 2, ISO 27001) describe what "good" looks like; threat-modeling frameworks (STRIDE, MITRE ATT&CK for Containers) describe how attacks are structured — both covered in the sibling DevSecOps course's threat modeling page; supply chain compliance ties SBOMs back to those obligations; automation and tooling is the reminder that none of this scales done by hand — see Compliance & governance for the continuous-evidence pattern that replaces a once-a-year audit.

How to prepare using this course

☺ Like you're 10: Nearly every KCSA topic already has a page somewhere on this site — this table is the shortcut to find it.

This course's own security material was written for candidates going considerably deeper than KCSA — CKS and real production hardening — so the overlap with this associate exam is close to total. Work the heaviest domains first:

Three weeks. Week 1: the 44% — work the cluster-component table above until the "exposes/hardens" pair comes from memory, then read RBAC & admission control beside the official curriculum and write the six domains and forty-two competencies out by hand. Week 2: Security: Defense in Depth for the Threat Model domain, narrating the attack chain aloud, then the Platform Security links above — run Trivy and Kyverno against a real image on kind so admission-time verification is something you've actually seen, not just read about. Week 3: Compliance & governance and the 4Cs section above, then drill with the glossary for anything that hasn't stuck, and keep a running list of trip-ups in field notes. If your interest is specifically Kubernetes security operated at production depth rather than this exam's knowledge-based ceiling, CKS is the direct next step once CKA is passed.

If you're approaching this because you're building or operating a platform above Kubernetes rather than the cluster itself, the sibling Platform Engineering course's own KCSA page covers the same curriculum from that angle — including where it sits against the CNPE's Security & Policy Enforcement domain — and is worth reading once the domains above feel settled, rather than duplicated here.

Exam logistics — and how to verify them

☺ Like you're 10: An online test you take from home while someone watches through your webcam. The exact rules change over time, so always check the official page before you pay.

Some facts about KCSA are structural and safe to state plainly. Others are exactly the sort of detail the Linux Foundation revises without much ceremony. This section keeps the two apart on purpose.

Price, the retake entitlement, and the roughly two-year certification validity window are all published on the official product page and do get revised — read them there before you budget, rather than from any third-party page, including this one.

↗ Official KCSA page — Linux Foundation ◆ CNCF certification page ◆ Official CNCF curriculum repository

Don't confuse the two exam styles on this course's own ladder. KCNA and KCSA are knowledge-based: multiple choice, proctored in a browser, nothing to type into a cluster. CKA, CKAD and CKS are performance-based: a real terminal, real clusters, tasks graded on the state you leave behind. Study material written for one style is close to useless for the other.

Where KCSA sits, and what to do next

☺ Like you're 10: A first security badge, not a final one. Take it, understand the map, then go build or go deeper.

Place KCSA honestly. It sits with KCNA on this course's associate rung: valuable as a structured curriculum and as a signal that you take guardrails seriously, but not, alone, proof you can harden a cluster under pressure. Nobody gets hired on a KCSA badge by itself. Plenty of people use it to make the next exam considerably easier.

Three next moves. For security depth: CKA first — a hard prerequisite — then CKS, hands-on and the credential that actually changes how people read your CV. For the rest of this course's ladder: the certifications hub lays out KCNA, KCSA, CKA, CKAD and CKS side by side, and holding all five active at once qualifies you for the CNCF's Kubestronaut recognition. For going wider than core Kubernetes: the sibling Golden Astronaut course covers the other ten CNCF certifications, the Linux Foundation's LFCS, and the full Golden Kubestronaut ladder above plain Kubestronaut; if platform engineering above the cluster is the more relevant direction, the sibling Platform Engineering course's CNPE gives this exact material a direct 15% under its own Security & Policy Enforcement domain.

The durable takeaway isn't the badge. It's the habit of asking, about every feature you're about to ship: what does an attacker gain if this is misconfigured, and which of the 4Cs does the fix actually belong to? That question survives every curriculum revision this exam will ever go through.