KCSA Study Plan & Practice Bank
The KCSA is a multiple-choice exam about how a Kubernetes platform gets broken into and what stops it — no cluster, no terminal, and no partial credit for a command that almost worked. That should change how you study for it: instead of drilling kubectl muscle memory, you're building a map of the attack surface, six domains deep, and rehearsing retrieval under exam-style pressure rather than watching more videos. This page does two things at once. First, a four-week study plan sized to the CNCF's own published domain weights — a dedicated week each for the two 22% domains that make up nearly half the paper, a combined week for the two 16% domains, and a final week for the smaller 14% and 10% domains plus review. Second, a 24-question multiple-choice practice bank, distributed across all six domains in roughly the same proportion the real exam uses, with the correct answer and a full explanation under every question — including why the plausible-looking wrong options are wrong. Work the plan, then the bank, then book.
Imagine you're training to be a museum security consultant — not a guard standing at one door, but someone who can walk the whole building and point out every window that doesn't lock, every door propped open with a fire extinguisher, and every guard badge left in a drawer where a stranger could pick it up. You don't have to catch the burglar in the act. You just have to know, room by room, where a burglar tries first, and which fix actually closes that gap versus which fix only looks like it does. That's the whole KCSA in one sentence: an exam about noticing, not about tackling. This page hands you a four-week tour of every room in the museum, then a stack of practice cards to check whether you actually noticed.
The domain-weighted study budget
☺ Like you're 10: The exam doesn't spend its marks evenly across six domains, so a plan that spends the same amount of time on all of them is already wrong before week one starts.
These are the six domains and weights exactly as published in the CNCF's Kubernetes and Cloud Native Security Associate (KCSA) Exam Curriculum: forty-two competencies, split unevenly across six domains that sum to exactly 100% — 22 + 22 + 16 + 16 + 14 + 10. The two 22% domains, Cluster Component Security and Security Fundamentals, are worth as much between them as the other four domains combined; treat that as a hard constraint on your calendar, not a rough guideline. (The sibling Platform Engineering course's own KCSA page tabulates these same six domains from the identical curriculum PDF — worth a second look once this page feels familiar.)
Turning that weight and each domain's competency count into an hours budget gives a plan you can actually schedule against:
| Domain | Weight | Competencies | Study-budget hours |
|---|---|---|---|
| 🦉 Cluster Component Security | 22% | 11 | ~9 hrs |
| 🐢 Security Fundamentals | 22% | 7 | ~9 hrs |
| 👺 Threat Model | 16% | 7 | ~6 hrs |
| 🔐 Platform Security | 16% | 7 | ~6 hrs |
| ☁️ Overview of Cloud Native Security | 14% | 6 | ~6 hrs |
| ⚖️ Compliance & Security Frameworks | 10% | 4 | ~4 hrs |
| Domain core, total | 100% | 42 | ~40 hrs |
That ~40-hour core doesn't include the practice bank below or a final review pass — budget another ~10–12 hours for those, for a full plan of roughly 50–52 hours across four weeks, or about 13 hours a week. KCSA is a 90-minute knowledge exam, not a two-hour performance exam, and its study budget is sized accordingly — well under half of what this course's CKA study plan asks for. Compress this into two or three weeks if you already run clusters daily and just need the security vocabulary formalized; stretch it to six or seven if you're newer to Kubernetes generally and want the KCNA study plan running alongside it first.
A four-week roadmap
☺ Like you're 10: Here's the actual calendar — which week gets which domain, and which pages on this course to use that week.
Four weeks, sized to the budget above. The two 22% domains each get a dedicated week, because eighteen combined competencies is genuinely too much ground to hold in your head at once. The two 16% domains share a week, because Threat Model and Platform Security read naturally as one continuous story — an attacker's chain of moves, and the platform controls that break each link in it. The two smallest domains close the plan out alongside the practice bank and a final review pass.
| Week | Focus | Hours | What you actually do |
|---|---|---|---|
| 1 | 🦉 Cluster Component Security — 22% | ~9 | API server, etcd, kubelet, controller manager & scheduler, container runtime, kube-proxy, Pod, container networking, storage, client security — each learned as an "exposes / hardens" pair, not a flag to memorize. Read control plane internals and Kubernetes architecture for the substrate, then RBAC & admission control for the API server's own authorization path. |
| 2 | 🐢 Security Fundamentals — 22% | ~9 | Pod Security Standards versus Pod Security Admission, NetworkPolicy's flat-by-default networking, Secrets as base64 rather than encryption, authentication versus authorization, isolation and segmentation, audit logging. Work RBAC & admission control and networking & the CNI, then try the hands-on workshop below. |
| 3 | 👺 Threat Model + 🔐 Platform Security — 16% + 16% | ~12 | Narrate the attacker's chain aloud — malicious code execution, access to sensitive data, privilege escalation, lateral movement on the network, persistence, denial of service — then the platform controls that break each link: supply-chain signing and SBOMs, PKI and mTLS, service mesh, admission control, observability as a security signal. Read security: defense in depth and the DevSecOps course's container & supply-chain security page. |
| 4 | ☁️ Cloud Native Security + ⚖️ Compliance, then practice | ~10 | The 4Cs — Cloud, Cluster, Container, Code — and the isolation-technique ladder underneath them; then the CIS Kubernetes Benchmark, NIST SP 800-190, STRIDE and MITRE ATT&CK for Containers, and why "automation and tooling" is called out as its own competency. Read the DevSecOps course's compliance & governance page, then work the full 24-question practice bank below — twice. |
Studying a knowledge-based exam, not a performance-based one
☺ Like you're 10: This test only ever asks you to spot the right answer among a few options — so the fastest way to prepare is to practice producing the answer yourself with the page closed, not to keep re-reading it.
KCSA is multiple choice / multiple select, remote-proctored, with no cluster and no terminal — a genuinely different skill from this course's performance-based exams. That changes what "studying" should mean. Re-reading a page makes the material feel familiar, which is not the same thing as being able to produce it cold; the practice bank below exists specifically to force retrieval instead of recognition.
For every competency, force yourself to answer one question out loud before you check anything: what does an attacker gain if this is misconfigured, and which layer of the 4Cs does the fix belong to? A component, primitive, or control you can't slot into that sentence yet is exactly what to re-read — not the whole domain again.
A second habit matters specifically because of this exam's favorite trap: KCSA rewards knowing what a control does and its exact scope. A NetworkPolicy that "protects" a namespace on a CNI that doesn't implement NetworkPolicy protects nothing; Pod Security Standards naming a level is not the same fact as Pod Security Admission enforcing one. The practice bank below is deliberately full of these near-miss pairs, because the real exam is too.
On a throwaway kind cluster: label a namespace pod-security.kubernetes.io/enforce: restricted and apply a plain nginx Deployment — read the rejection line by line, it lists every rule you broke, which is a free study guide. Fix the Pod until it schedules. Then apply a default-deny NetworkPolicy in that namespace, watch DNS break, and add back only the egress rule to CoreDNS on UDP/TCP 53 until it resolves again. Nothing on KCSA requires you to have done this — but nothing fixes a shaky mental model of PSA and NetworkPolicy faster than watching both fail and recover once.
Practice bank — 24 questions across all six domains
☺ Like you're 10: Twenty-four practice questions, split up the same uneven way the real paper is — more questions from the two big domains, fewer from the two small ones.
Every question below is original to this course, not reproduced from any official exam, and mirrors the style and difficulty of a real KCSA item: one correct answer, three plausible-sounding wrong ones, and a question that tests whether you understand a control's exact scope, not just its name. Work a domain's questions cold, then open its answer key — the explanation matters more than the letter, because the same reasoning is what a differently-worded version of the same question will need on the real day.
🦉 Cluster Component Security — 22% · 5 questions
Which control-plane component, if fully compromised, hands an attacker every Secret in the cluster — because it is the single source of truth for all cluster state?
- A. kube-scheduler
- B. CoreDNS
- C. etcd
- D. kube-proxy
A cluster's kubelet API is reachable with
--anonymous-auth=trueand no authorization webhook configured. What can an attacker who reaches that port do?- A. Nothing without a valid ServiceAccount token
- B. Read only cluster metrics
- C. Exec into and read logs from any Pod scheduled on that node, unauthenticated
- D. Modify RBAC bindings cluster-wide
What is the recommended
--authorization-modesetting for the kube-apiserver in a hardened cluster?- A. AlwaysAllow
- B. Node,RBAC
- C. ABAC
- D. Anonymous
Why should kube-scheduler and kube-controller-manager bind their metrics and profiling endpoints to localhost rather than
0.0.0.0?- A. It improves scheduling latency
- B. It prevents unauthenticated network access to sensitive internal state and profiling data
- C. It is required for horizontal pod autoscaling to function
- D. It reduces etcd storage size
A container escapes to the host kernel via a container-runtime vulnerability. Which control is specifically designed to contain this class of attack, even against an unpatched kernel bug?
- A. NetworkPolicy
- B. An RBAC RoleBinding
- C. A sandboxed runtime such as gVisor or Kata Containers
- D. Pod Security Admission in "baseline" mode
Check your answers — Cluster Component Security
- C. etcd. It stores the complete desired-and-current state of the cluster, Secrets included — compromising etcd is equivalent to compromising the cluster outright.
- C. The kubelet API grants exec, logs and port-forward access scoped to Pods on that one node. With anonymous auth on and no webhook authorization, that access needs no credential at all — but it's node-scoped lateral movement, not cluster-wide RBAC control, which is the API server's job, not the kubelet's.
- B. Node,RBAC. The Node authorizer scopes each kubelet to objects related to its own node; RBAC governs everyone else.
AlwaysAllowdisables authorization entirely and should never appear on a real cluster. - B. Both components carry powerful credentials and can leak internal state or profiling data to anyone who can reach the port over the network; binding to localhost removes that surface from the network entirely rather than merely restricting it.
- C. A sandboxed or microVM runtime interposes a second kernel or a syscall boundary between the container and the real host kernel, containing exactly this failure mode. RBAC and NetworkPolicy operate at completely different layers — API authorization and network traffic, not container-to-kernel escape.
🐢 Security Fundamentals — 22% · 5 questions
Under the Pod Security Standards, which of the three levels permits privileged containers and host-namespace access?
- A. restricted
- B. baseline
- C. privileged
- D. audit
You're rolling out Pod Security Admission on a namespace with workloads you didn't build. What is the safest sequencing of PSA's three modes?
- A. enforce → warn → audit
- B. warn and audit first, then flip to enforce once nothing is flagged
- C. enforce only — warn and audit are for CI, not clusters
- D. audit only, forever, without ever enforcing
A namespace has zero NetworkPolicy objects defined. What is the resulting default connectivity between Pods in that namespace and Pods in every other namespace?
- A. All traffic is denied by default
- B. Only same-namespace traffic is allowed
- C. All traffic is allowed in every direction — Kubernetes networking is flat by default
- D. Only traffic to Services of type LoadBalancer is allowed
Kubernetes has no built-in
Userobject. How do humans typically authenticate to the API server?- A. By creating a Secret named after their username
- B. Via client certificates, an OIDC identity provider, or an authenticating proxy — Kubernetes trusts an external identity, not an internal object
- C. Via a ServiceAccount token issued to their laptop
- D. Authentication isn't required for
kubectl— only authorization is checked
A
Secretobject'sdatafield is base64-encoded. What does that actually provide, from a security standpoint?- A. Strong encryption at rest, equivalent to AES-256
- B. No confidentiality at all — base64 is an encoding, not encryption, and it's trivially reversible
- C. Confidentiality, as long as RBAC is configured
- D. Protection against anyone with file-system access to etcd, but not API access
Check your answers — Security Fundamentals
- C. privileged. It's the unrestricted level;
baselineblocks known privilege escalations while allowing a fairly ordinary Pod spec;restrictedenforces current hardening best practice. "audit" isn't a Standards level at all — it's a PSA enforcement mode, exactly the conflation the next question is about. - B.
warn(message the submitter) andaudit(record to the audit log) surface violations with zero blast radius before you flip toenforce(reject) and start actually rejecting Pods. - C. Without any NetworkPolicy, Kubernetes networking is flat: every Pod can reach every other Pod, across every namespace. A NetworkPolicy only restricts traffic once at least one policy selects a Pod — and only if the CNI actually implements NetworkPolicy enforcement.
- B. Kubernetes has no first-class human-identity store; it delegates authentication to certs, OIDC, webhook, or a proxy, and RBAC then binds to whatever identity authentication produces. ServiceAccount tokens (C) identify workloads, not people — a related but distinct mechanism.
- B. Base64 is reversible with zero secret material required; it only prevents accidental terminal-mangling of binary data. Real confidentiality needs an
EncryptionConfiguration— ideally KMS-backed — plus tight RBAC onget secrets, and ideally an external secrets store.
👺 Kubernetes Threat Model — 16% · 4 questions
In the Kubernetes Threat Model's attacker narrative, what is typically the first foothold an attacker needs before any other stage in the chain becomes possible?
- A. Privilege escalation
- B. Malicious code execution inside a container
- C. Persistence via a CronJob
- D. Denial of service against the API server
An attacker who has code execution inside a Pod wants to survive a Pod restart or redeploy. Which of the following is a documented persistence technique?
- A. Reading environment variables
- B. Installing a malicious CronJob or a mutating admission webhook that keeps re-injecting the attacker's payload
- C. Sending an HTTP request to an external server
- D. Reading the Pod's own resource limits
Once inside a container, which two things are most commonly the first source of "access to sensitive data" an attacker checks?
- A. The Pod's resource requests and its readiness probe
- B. The node's hostname and its uptime
- C. The auto-mounted ServiceAccount token and the cloud provider's instance-metadata endpoint
- D. The container's image digest
Which Pod configuration is the most direct privilege-escalation vector named in the KCSA threat model?
- A. A CPU resource limit set too low
- B. A container running with
privileged: true, or ahostPathmount to a sensitive host directory - C.
imagePullPolicy: IfNotPresent - D. A missing
livenessProbe
Check your answers — Threat Model
- B. The chain generally begins with code execution inside a compromised or malicious container — from there, the attacker pivots toward sensitive data, privilege escalation, lateral movement, and persistence.
- B. Persistence is specifically about surviving restarts, redeploys, and detection — a scheduled CronJob or a mutating webhook that keeps re-inserting malicious config are the textbook mechanisms under this competency.
- C. An auto-mounted ServiceAccount token hands over a live credential to the API server, and a cloud metadata endpoint — reachable over plain HTTP from inside most pods by default — often hands over cloud IAM credentials. Both are default-on unless explicitly disabled.
- B. A privileged container effectively has root on the node; a writable
hostPathmount into something like/etcor the container runtime socket gives an equivalent escape route without even needing theprivilegedflag.
🔐 Platform Security — 16% · 4 questions
Which tool or approach from the CNCF ecosystem is used to cryptographically sign a container image so its provenance can be verified at admission time?
- A. Trivy
- B. Sigstore / cosign
- C. kube-bench
- D. Falco
What does a Software Bill of Materials (SBOM) provide that a vulnerability scan alone does not?
- A. A guarantee that the image contains no vulnerabilities
- B. A complete, machine-readable inventory of every component and dependency in an artifact — the basis for later answering "were we affected?" the next time a CVE is disclosed
- C. A signed attestation that the image was built on approved infrastructure
- D. Runtime behavioral profiling of the container
Which platform-security competency covers issuing and rotating the TLS certificates that let two services establish mutual TLS (mTLS) inside a cluster?
- A. Observability
- B. PKI
- C. Admission Control
- D. Image Repository
An organization wants to reject any Pod whose image is unsigned or comes from an unapproved registry, before the Pod is ever scheduled. Which competency and mechanism does this fall under?
- A. Observability — via Falco runtime rules
- B. Admission Control — via a policy engine such as Kyverno or OPA/Gatekeeper evaluating the request before it's persisted
- C. Network Policy — via a default-deny egress rule
- D. Audit Logging — via a
RequestResponse-level audit policy
Check your answers — Platform Security
- B. Sigstore's
cosignsigns OCI artifacts and stores the signature alongside the image in the registry; an admission controller can then verify the signature before letting the image run. Trivy scans for vulnerabilities — a related but different competency — kube-bench checks CIS Benchmark compliance, and Falco is a runtime detection tool. - B. An SBOM is an inventory, not a verdict — it's what lets a team instantly answer "do we ship the vulnerable library?" days or years after the image was built, without re-scanning everything from scratch. Signed build provenance is a related but separate practice, closer to SLSA.
- B. PKI is commonly implemented in-cluster with a tool such as cert-manager, and is often driven end-to-end by a service mesh like Istio or Linkerd for automatic mTLS between workloads.
- B. This is a validating or mutating admission decision, made before the object is ever written to etcd — the job of an admission policy engine, not a runtime tool, a network control, or a purely after-the-fact audit log.
☁️ Overview of Cloud Native Security — 14% · 3 questions
In the 4Cs of Cloud Native Security — Cloud, Cluster, Container, Code — why does the outside-in ordering matter?
- A. It's alphabetical and carries no technical meaning
- B. Each layer is only as secure as the one outside it — you cannot fully secure a Container running on a compromised Cluster, so hardening has to work from the outside in
- C. It reflects the order features were added to Kubernetes historically
- D. It ranks the layers by how frequently their configuration changes
Which is the correct order, weakest to strongest, of the isolation techniques covered under "Isolation Techniques"?
- A. Sandboxed runtimes → namespaces/cgroups → separate clusters
- B. Namespaces and cgroups → syscall restriction (seccomp/AppArmor/SELinux) → sandboxed runtimes (gVisor/Kata) → separate node pools or clusters
- C. Separate clusters → seccomp → namespaces
- D. There is no meaningful ordering — all isolation techniques provide equivalent guarantees
"Workload and Application Code Security" as a competency is primarily concerned with which of the following?
- A. Hardening the etcd data store
- B. Dependency and source-code-level risk in the application itself, independent of how well the cluster around it is configured
- C. TLS certificate rotation for the control plane
- D. Node-level kernel patching
Check your answers — Overview of Cloud Native Security
- B. The 4Cs describe nested trust boundaries; a control placed at the wrong layer — hardening application Code while the underlying Cluster is wide open, say — is largely theater, because a compromise at an outer layer undermines everything inside it.
- B. Isolation strength increases as you move from process-level primitives (namespaces/cgroups), to syscall restriction, to a full alternate kernel boundary (sandboxed runtimes), to physically or logically separate infrastructure for the strongest multi-tenancy guarantee.
- B. This competency sits at the innermost "Code" layer of the 4Cs — it's about the application's own dependency and code-level risk, which no amount of cluster or container hardening compensates for.
⚖️ Compliance and Security Frameworks — 10% · 3 questions
What does the CIS Kubernetes Benchmark provide?
- A. A list of CVEs specific to Kubernetes
- B. A vendor-neutral, prescriptive set of configuration recommendations for hardening a cluster, checkable with tooling such as kube-bench
- C. A certification exam blueprint
- D. A runtime intrusion-detection ruleset
MITRE ATT&CK for Containers and STRIDE are both examples of which kind of framework, as distinct from a compliance framework like SOC 2 or ISO 27001?
- A. Threat-modeling frameworks — they structure how you reason about attacker tactics and techniques, rather than defining an audit or certification standard
- B. Supply-chain compliance frameworks
- C. Automation and tooling frameworks
- D. Cloud-provider shared-responsibility frameworks
"Automation and Tooling" is called out as its own competency inside Compliance and Security Frameworks. Why does it matter as a distinct topic rather than being assumed?
- A. Because manual, one-time compliance checks don't scale and drift out of date — automated checks such as kube-bench in CI, or policy-as-code, are what actually keep a cluster continuously compliant
- B. Because the CNCF requires all clusters to run one specific tool
- C. Because it replaces the need for RBAC
- D. Because automation is only relevant to Platform Security, not compliance
Check your answers — Compliance & Security Frameworks
- B. The CIS Benchmark is a configuration-hardening checklist, not a CVE feed or an intrusion-detection ruleset —
kube-benchis the common open-source tool that automates checking a live cluster against it. - A. Compliance frameworks — the CIS Benchmark, NIST SP 800-190, SOC 2, ISO 27001, PCI DSS — describe "what good looks like" for an audit; threat-modeling frameworks — STRIDE, MITRE ATT&CK for Containers, the CNCF Security TAG's own Kubernetes threat model — describe how attacks are structured, independent of any compliance obligation.
- A. A framework checked once at audit time and never again gives a false sense of security; continuous, automated checking — CI-integrated benchmarking, policy-as-code — is what keeps compliance real between audits.
Resources: official, this course, and second opinions
☺ Like you're 10: A few sources do all the real work here — there's no need to read "everything you can find."
KCSA has an unusually short reading list for how broad it is, because the curriculum itself is close to the syllabus.
| Resource | Use it for |
|---|---|
| The published curriculum — github.com/cncf/curriculum | The exact competency wording and current curriculum version — confirm it matches what you're studying before you sit. |
The Kubernetes documentation, kubernetes.io | Canonical detail on NetworkPolicy, Pod Security Admission, RBAC, and the API server flags referenced throughout this page. |
| This course's deep dives — RBAC & admission control · security: defense in depth · networking & the CNI · control plane internals · the CNCF project landscape | Going a layer deeper than KCSA needs on each domain's underlying mechanics. |
| The DevSecOps course — container & supply-chain security · compliance & governance | Full-depth treatment of the Platform Security and Compliance domains from a security-engineering angle. |
| This course's KCSA pages — KCSA — the exam · Mock Exam · Set 1 · Set 2 | The full exam-hub framing, and two complete timed mock papers once this plan and the bank above feel solid. |
| Second opinion, same exam — Platform Engineering's KCSA page | The same six domains, curriculum-sourced, explained from a platform-engineer's angle rather than a Kubernetes-operator's. |
| Prerequisite associate exam — the KCNA study plan & practice bank | KCSA assumes Pod, Service, and ServiceAccount are already second nature; if they aren't yet, that page comes first. |
Keep a running weak-spot log rather than trusting memory — this course's field notes page is built for exactly that, and the glossary is faster than re-reading a whole domain the moment one term doesn't fully click. How to Study for a CNCF Exam covers the general method behind all of this, if you haven't read it yet.
Exam logistics — verify these yourself before you book
☺ Like you're 10: Here's what's generally published about the test itself. Numbers like these move without much warning, so check the official page before you pay anything.
One row below is something this page can state with full confidence, because it's transcribed directly from a document: the domains and weights. Almost everything else is logistics the Linux Foundation publishes and revises on its own schedule — treat every other row as "true at time of writing, confirm before you book."
| Item | What is generally published |
|---|---|
| Format | Online, remote-proctored, multiple choice / multiple select — no terminal, no live cluster, no documentation tab |
| Duration | 90 minutes |
| Questions | Not published by the Linux Foundation or the CNCF — plan against the 90 minutes, not against a number you saw on a forum |
| Passing score | 75%, per the Linux Foundation's Multiple Choice Exam FAQ, which covers every LF multiple-choice exam, KCSA included |
| Validity | 2 years from the date you pass |
| Retake | LF exam purchases have generally included one free retake — depends on the specific bundle you buy |
| Prerequisites | None — unlike CKS, there is no certification you must already hold |
| Level | Associate — knowledge-based, sitting below this course's performance-based exams |
| Domains & weights | The six domains transcribed above — 22/22/16/16/14/10, summing to 100% |
This page is an independent, unofficial study resource — not affiliated with the CNCF or the Linux Foundation. Price, question count, retake policy, and even curriculum version all change over time. Confirm current details on the official Linux Foundation KCSA page and the CNCF certification page before you pay for anything, and read the Candidate Handbook in your LF portal. The curriculum itself is published openly at github.com/cncf/curriculum. See Kubernetes Certifications for this course's full ladder, and the Golden Astronaut course if KCSA is one stop on the way to the full Golden Kubestronaut set.
Gizmo: Multiple choice? Easy mode. I'll just skim a question dump the night before. 🤑
Timmy: A dump gives you an answer key for questions worded exactly one way. This exam tests whether you understand a control's scope — reword the same question and a memorized answer falls apart. A real mental model doesn't.
Gizmo: Fine, real shortcut then: our whole platform is private, no public load balancer. We're basically already secure, right?
Timmy: That's a fence around the building, Gizmo. Now assume someone's already inside one pod. What can they reach?
Nutty: ...everything, probably. No NetworkPolicy anywhere, and every ServiceAccount token auto-mounts by default. I checked while you two were talking.
Foxy: That's most of the Threat Model domain in one sentence, isn't it?
Timmy: That's the whole exam in one sentence, Foxy. What does an attacker gain, and which layer does the fix belong to?
1. What are the six KCSA domains and their weights, and what do they sum to? 2. Why does this plan give weeks 1 and 2 to a single domain each, but combine two domains into week 3? 3. What is the practical difference between Pod Security Standards and Pod Security Admission? 4. Name the 4Cs of Cloud Native Security in order, and explain why the order matters. 5. What is the published KCSA pass mark, and where does that figure actually come from? 6. Give one example each of a compliance framework and a threat-modeling framework, and explain the difference between the two. 7. Why is a Kubernetes Secret not actually a secret by default, and name one real fix?
Check your answers
- Cluster Component Security 22%; Security Fundamentals 22%; Threat Model 16%; Platform Security 16%; Overview of Cloud Native Security 14%; Compliance and Security Frameworks 10% — summing to exactly 100%.
- Because those two domains are worth 22% each and eighteen combined competencies — genuinely too much to hold alongside anything else in one week — while the two 16% domains, Threat Model and Platform Security, are naturally read as one continuous story: an attacker's chain of moves, and the platform controls that break each link.
- Standards are the three policy levels —
privileged,baseline,restricted. Admission is the built-in controller that enforces a level via namespace labels, in three modes:enforce(reject),audit(record),warn(message the user). - Cloud, Cluster, Container, Code — the order is the dependency order. Each layer is only as secure as the one outside it, so hardening has to work outside-in, and a control placed at the wrong layer is largely theater.
- 75%, per the Linux Foundation's own Multiple Choice Exam FAQ, which states that rule for every LF multiple-choice exam, KCSA included — not a rumor or a forum estimate.
- A compliance framework, e.g. the CIS Kubernetes Benchmark or SOC 2 / ISO 27001, states what good configuration or governance looks like for an audit. A threat-modeling framework, e.g. STRIDE or MITRE ATT&CK for Containers, describes how attacks are structured, independent of any audit obligation.
- Because a Kubernetes
Secret'sdatafield is only base64-encoded, not encrypted — trivially reversible, and stored in etcd readable by anyone withget secretsRBAC in the namespace. Any real fix: anEncryptionConfiguration, ideally KMS-backed, tighter RBAC, or an external secrets store.