KCSA Mock Exam · Set 1 — 50 questions, one clock, six domains

This is a full KCSA-format sitting: 50 multiple-choice questions, weighted 22 / 22 / 16 / 16 / 14 / 10 to match the real exam's six official domains — Cluster Component Security, Security Fundamentals, Threat Model, Platform Security, Overview of Cloud Native Security, and Compliance and Security Frameworks — against one unbroken 90-minute block, closed-book, exactly like the real sitting. There is no cluster to build here and nothing to type into a terminal: KCSA is knowledge-based, so every question below tests whether you can locate a risk and name the control that closes it, not whether you can type fast enough to fix one yourself — that's CKS's job. Work straight through without opening a second tab, then check every answer against the explanation folded behind each domain's answer key — the explanation is the actual lesson, not the letter you happened to pick. If any domain still feels shaky going in, read the KCSA blueprint first; this paper measures recall under a clock, not first exposure to the material.

How this paper is built, and where it fits your prep

☺ Like you're 10: This isn't your only rep — it's stop two in a four-stop loop: learn, sit, fix, sit again.

KCSA has no performance-based tier to build toward — that's a separate exam, CKS, and a hard CKA prerequisite sits in front of it — so the loop here is shorter than this course's CKA mocks, but it's still a loop, not a single event. Sit this paper cold, mark yourself honestly by domain, go fix exactly the gaps it found, then confirm the fix with a second, fresh paper before you spend the exam fee.

Exam conditions for this sitting

☺ Like you're 10: One clock, closed book, and no peeking at what's behind the curtain until you've actually chosen an answer.

One timer, started once. 90 minutes. That is the real KCSA's published duration, confirmed on the Linux Foundation's own Multiple Choice Exam FAQ, and this paper uses the same clock even though its question count is a teaching choice rather than a leak. Closed-book — no reference material at all. Every knowledge-based exam on this course's ladder works this way: unlike CKA, CKAD and CKS, which open a documentation tab inside the exam environment because they're performance-based, KCSA hands you nothing but the question and four options. Close every tab except this one. One honest caveat: the real KCSA mixes single-best-answer and multiple-select items; every question on this paper is single-best-answer only, for consistency and clean self-marking — treat multi-select practice as a gap this paper doesn't close on its own. Answer every question once, in order; nothing published suggests a guess penalty, so mark uncertain ones and move on, but never leave one blank. No peeking at an answer key before you've committed — reading the answer first turns a diagnostic paper into a comprehension exercise, and you won't get that data back.

How the 50 questions are weighted

☺ Like you're 10: The questions are shared out exactly the way the real exam shares out its marks — the biggest topics get the most questions, down to the last one.

The six official weights — 22, 22, 16, 16, 14, and 10 — sum to exactly 100%, transcribed straight from the CNCF's published KCSA curriculum. Cluster Component Security and Security Fundamentals together are 44% of the paper — 22 of the 50 questions — and both are enumerable lists: eleven named cluster components, seven named security primitives, each with a "what it exposes, what hardens it" pair that this paper drills one competency at a time. Threat Model and Platform Security, 16% each, reward a different kind of knowledge: Threat Model is attacker behaviour told as a seven-beat story, and Platform Security reaches into supply chain, PKI, service mesh and admission control — the most platform-engineering-flavoured domain on the paper. Overview of Cloud Native Security at 14% is small but carries the 4Cs model that organizes everything else on the exam, and Compliance and Security Frameworks at 10% is the domain most candidates leave for the last night — a mistake, since it's also the cheapest to secure.

☸️ Domain 1 — Kubernetes Cluster Component Security (22% · Q1–11)

☺ Like you're 10: This domain is a list of every room in the clubhouse that could be tricked into doing something it shouldn't — one question for each room, no more, no less.

This domain maps exactly onto the eleven named competencies in the official curriculum, one question per component in the same order the KCSA blueprint's own table uses them: API Server (Q1), Controller Manager (Q2), Scheduler (Q3), Kubelet (Q4), Container Runtime (Q5), Kube-proxy (Q6), Pod (Q7), etcd (Q8), Container Networking (Q9), Client Security (Q10), and Storage (Q11). Learn each one as "what it exposes → what hardens it," and this domain — a fifth of the real exam — becomes close to a vocabulary drill. Kubernetes architecture and control plane internals cover the underlying mechanics this domain assumes.

# Five things a KCSA question is often quietly testing you against —
# every line below is a real, common misconfiguration, not a strawman.
apiVersion: v1
kind: Pod
metadata: { name: risky-example }
spec:
  automountServiceAccountToken: true   # default — mints a token nobody in this Pod asked for
  hostNetwork: true                    # shares the NODE's own network namespace directly
  hostPID: true                        # sees every process ON THE NODE, not just its own
  containers:
    - name: app
      image: example.com/app:latest    # a mutable tag — never provably the image that was reviewed
      securityContext:
        privileged: true               # effectively root against the node's own kernel

1. Why is the kube-apiserver considered the single most security-critical component in a Kubernetes cluster?

   1. It stores container image layers
   2. Every other component, and every kubectl request, passes through it — it is the sole gateway to etcd
   3. It runs user application code directly
   4. It has no authentication mechanism of its own

2. kube-controller-manager and kube-scheduler are typically hardened by binding their non-secure endpoints to which address?

   1. 0.0.0.0 (all interfaces)
   2. 127.0.0.1 (localhost only)
   3. The node's public IP
   4. The cluster's Service CIDR

3. An attacker able to influence kube-scheduler's placement decisions could most directly use that access to:

   1. Read Secrets straight out of etcd
   2. Force a sensitive workload onto a specific, less-monitored or attacker-controlled node
   3. Rewrite existing RBAC RoleBindings
   4. Change a container's image digest after it's running

4. Why is a kubelet's legacy unauthenticated read-only port considered a serious risk if left enabled?

   1. It allows arbitrary code execution inside etcd
   2. It exposes Pod and container details, including some logs, to anyone who can reach the port — with no authentication at all
   3. It grants cluster-admin automatically to any caller
   4. It silently disables the node's container runtime

5. Which class of vulnerability, if present in the container runtime, lets a process escape its container entirely and reach the node's own kernel?

   1. A NetworkPolicy bypass
   2. A container/kernel escape ("container breakout")
   3. A stale RoleBinding
   4. A DNS cache-poisoning attack

6. What does an attacker gain by compromising the credentials kube-proxy uses on a node?

   1. Direct write access to etcd's on-disk data files
   2. The ability to influence that node's own traffic-forwarding rules for Services
   3. Root access to the kube-apiserver Pod specifically
   4. The ability to mint new admission webhooks cluster-wide

7. By default, what does Kubernetes automatically mount into a Pod's containers — something KCSA's Security Fundamentals domain recommends disabling when a workload doesn't actually call the API?

   1. A hostPath volume
   2. A ServiceAccount token, via automountServiceAccountToken
   3. A NetworkPolicy object
   4. A PodDisruptionBudget

8. Why does compromising etcd effectively mean compromising the entire cluster?

   1. etcd runs every container workload directly
   2. etcd stores every Kubernetes object, including Secrets, and that data is not encrypted at rest by default
   3. etcd is the only component reachable from outside the cluster
   4. etcd fully replaces the kube-apiserver's own role

9. In a cluster with no NetworkPolicy objects applied anywhere, what is the default Pod-to-Pod reachability?

   1. All Pods are fully isolated from one another by default
   2. Every Pod can reach every other Pod, in every namespace, with no restriction at all
   3. Only Pods in the same namespace can reach each other
   4. Pods can only ever communicate through a Service object, never directly

10. Which is the strongest practice for a human operator's own kubectl credentials?

    1. A single long-lived static bearer token shared across the whole team
    2. Short-lived, OIDC-issued or exec-plugin-based credentials, and never --insecure-skip-tls-verify
    3. Embedding the cluster's root CA private key directly in the kubeconfig
    4. Disabling TLS certificate verification for convenience

11. From a security standpoint, what is the main concern with a CSI-provisioned PersistentVolume that is never explicitly encrypted?

    1. It can never be mounted by any Pod
    2. Data at rest on the underlying storage may be readable by anyone with access to that storage backend, not only through the cluster
    3. It automatically grants cluster-admin to whoever mounts it
    4. It bypasses the scheduler entirely

🐢 Domain 2 — Kubernetes Security Fundamentals (22% · Q12–22)

☺ Like you're 10: This domain is the clubhouse's actual rulebook — who's allowed in, what they're allowed to touch, and how you'd prove any of that later if someone asked.

Security Fundamentals covers seven competencies, unevenly weighted here by how much ground each actually holds: Pod Security Standards (Q12–13), Pod Security Admission (Q14–15), Authentication (Q16–17), Secrets (Q18–19), Isolation & Segmentation (Q20), Audit Logging (Q21), and Network Policy (Q22). This is the domain this course's own RBAC & admission control and networking & the CNI pages cover at full depth — considerably past what these eleven questions need.

12. How many policy levels does the Pod Security Standards specification define?

    1. Two — Allow and Deny
    2. Three — Privileged, Baseline, and Restricted
    3. Five, matching the five true Pod phases
    4. One — there is only a single enforced standard

13. Which Pod Security Standards level is the maximally restrictive one, following current Pod hardening best practice — requiring a non-root user and dropping all Linux capabilities, among other rules?

    1. Privileged
    2. Baseline
    3. Restricted
    4. Enforced

14. Pod Security Admission is configured primarily through:

    1. A ClusterRole bound to every ServiceAccount in the cluster
    2. Labels applied to a Namespace, such as pod-security.kubernetes.io/enforce
    3. A field set inside every individual Pod's securityContext
    4. A dedicated NetworkPolicy object

15. What is the difference between Pod Security Admission's enforce mode and its warn mode?

    1. They are identical; warn is a deprecated alias for enforce
    2. enforce rejects a non-compliant object outright; warn lets it through but returns a warning message to the caller
    3. warn deletes the object shortly after creation; enforce blocks it before creation
    4. enforce applies only to Deployments; warn applies to every object kind

16. Kubernetes has no built-in, persistent User object. How do human operators typically authenticate to the API server?

    1. An internally stored username/password pair
    2. Via client certificates, an OIDC identity provider, or an exec-credential plugin
    3. Only through a single hard-coded default admin account
    4. Kubernetes has no way to authenticate a human at all

17. How do workloads (Pods) typically authenticate themselves to the API server?

    1. By reusing the cluster administrator's own kubeconfig
    2. Via a ServiceAccount token, ideally short-lived and audience-bound
    3. Workloads are never required to authenticate to the API server
    4. Using the node's SSH host key

18. Why is it inaccurate to call the encoding used for Kubernetes Secret data a form of encryption?

    1. Because Secrets are actually stored as plaintext with no encoding applied at all
    2. Because base64 is a trivially reversible encoding, not encryption — anyone with API read access to the Secret can decode it instantly
    3. Because Secrets use a one-way hash that can never be reversed by anyone
    4. Because Secrets are stored entirely outside etcd

19. What must be separately configured for Kubernetes Secrets to actually be encrypted while stored in etcd?

    1. Nothing — this is the default, out-of-the-box behavior
    2. An EncryptionConfiguration on the API server, ideally backed by a KMS provider
    3. A NetworkPolicy restricting inbound access to etcd's port
    4. A PodSecurityPolicy object (still enabled by default)

20. Which of the following is not a real Kubernetes or kernel isolation mechanism?

    1. Namespaces, separating workloads by team or environment
    2. A seccomp profile restricting the syscalls available to a process
    3. A sandboxed runtime such as gVisor or Kata Containers
    4. A ResourceQuota that authenticates a caller's identity

21. What is the purpose of Kubernetes' audit logging feature?

    1. To automatically block malicious requests as they arrive, in real time
    2. To chronologically record who did what against the API server, for after-the-fact investigation and compliance evidence
    3. To fully replace the need for RBAC
    4. To encrypt Secrets at rest on its own

22. A NetworkPolicy object is created, correctly selecting a set of Pods, but the cluster's CNI plugin doesn't implement NetworkPolicy enforcement at all. What happens?

    1. Kubernetes automatically falls back to enforcing the policy at the API server
    2. The object exists and can be read with kubectl, but it enforces nothing — traffic is completely unaffected
    3. The Pods it targets are deleted automatically
    4. The API server refuses to accept the NetworkPolicy object at all

👺 Domain 3 — Kubernetes Threat Model (16% · Q23–30)

☺ Like you're 10: This domain is one continuous break-in story, told in seven chapters — not seven separate flashcards to memorize out of order.

Threat Model covers seven competencies, best learned as one attack chain rather than a list: Trust Boundaries & Data Flow (Q23), Malicious Code Execution (Q24), Access to Sensitive Data (Q25), Privilege Escalation (Q26–27), Attacker on the Network (Q28), Persistence (Q29), and Denial of Service (Q30). This course walks the exact same chain, exploit to alert, in Security: Defense in Depth — the single best-matched page in this course for the whole domain — with the misconfigurations attackers actually rely on catalogued in Kubernetes anti-patterns.

23. In the Kubernetes Threat Model domain, "Trust Boundaries & Data Flow" is best described as:

    1. A specific CVE class
    2. The discipline of mapping where one layer of trust ends and the next begins, so a control lands at the right boundary
    3. A synonym for NetworkPolicy specifically
    4. A CNCF governance committee

24. An attacker's first foothold in this domain's attack chain is typically:

    1. Privilege escalation
    2. Malicious code execution inside a single container
    3. Persistence via a rogue CronJob
    4. Denial of service against etcd

25. Once an attacker has code execution inside a Pod, which of the following is a realistic next target for "access to sensitive data"?

    1. The kube-scheduler's own source code
    2. That Pod's auto-mounted ServiceAccount token, its environment variables, or the cloud metadata endpoint
    3. The CNCF's public curriculum repository
    4. Only the cluster's DNS zone file, and nothing else

26. Which Pod-level configuration most directly enables privilege escalation from a compromised container to the underlying node?

    1. resources.limits.cpu set too low
    2. A privileged container, or one with a hostPath mount to a sensitive path plus root access
    3. A readOnlyRootFilesystem: true setting
    4. A missing livenessProbe

27. What does the Pod securityContext field allowPrivilegeEscalation: false specifically prevent?

    1. The Pod from ever being scheduled at all
    2. A process from gaining more privileges than its parent process — for example via a setuid binary or an added file capability
    3. The Pod from mounting any volume whatsoever
    4. DNS resolution from working inside the Pod

28. Why is "Attacker on the Network" a distinct threat-model competency, separate from the initial code-execution foothold?

    1. Because Kubernetes networking is encrypted by default, so this scenario can't actually occur
    2. Because Kubernetes networking is flat by default, so a foothold in one Pod can move laterally to reach any other Pod unless NetworkPolicy explicitly restricts it
    3. Because it only applies to on-premises clusters, never a cloud-managed one
    4. Because it describes attacks against the CNCF's own infrastructure, not a candidate's cluster

29. Which of these is a realistic way an attacker establishes persistence inside an already-compromised cluster?

    1. A rogue CronJob that periodically re-creates a backdoor, or a malicious mutating admission webhook
    2. A single Pod restart triggered by a normal liveness probe
    3. A routine kubectl rollout restart run by an operator
    4. A ResourceQuota being exceeded

30. Which of the following is a Kubernetes-specific denial-of-service risk, distinct from a generic network flood?

    1. A workload with no resource requests or limits set, consuming enough CPU or memory to starve other workloads or the node itself
    2. A properly configured HorizontalPodAutoscaler
    3. A NetworkPolicy that denies all egress from a namespace
    4. An RBAC Role scoped to a single namespace

🦉 Domain 4 — Platform Security (16% · Q31–38)

☺ Like you're 10: This domain is everything around the clubhouse that isn't Kubernetes itself but still has to be trustworthy — where the building materials came from, who's allowed to talk to whom, and who's checking the locks are still locked.

Platform Security covers seven competencies: Supply Chain Security (Q31–32), Image Repository (Q33), Observability (Q34), Service Mesh (Q35), PKI (Q36), Connectivity (Q37), and Admission Control (Q38). It's the domain closest to real platform-engineering practice, and the sibling DevSecOps course covers most of it at full production depth: container & supply-chain security, Trivy for scanning, Sigstore & cosign for signing, Kyverno and OPA/Conftest for admission, and Falco for observability.

# Sign at build time...
cosign sign --key cosign.key registry.example.com/app@sha256:5f1a...

# ...and verify at admission time, so an UNSIGNED image can never even start —
# this second step is the one candidates most often forget exists.
cosign verify --key cosign.pub registry.example.com/app@sha256:5f1a...

31. What does an SBOM (Software Bill of Materials) provide, in container supply-chain security practice?

    1. A cryptographic signature over the finished image
    2. A structured inventory of every component and dependency that went into building an artifact
    3. A running log of a Pod's restarts
    4. A NetworkPolicy template

32. Generating an SBOM and scanning an image for known CVEs both happen at build time. Why is verifying the image's signature at admission time also necessary?

    1. It isn't — build-time scanning alone is fully sufficient on its own
    2. Because build-time scanning says nothing about whether the exact image later deployed to the cluster is that same, untampered artifact — admission-time verification is what closes that gap
    3. Because admission control entirely replaces the need for scanning
    4. Because signatures can only ever be checked by the container runtime, never the API server's admission chain

33. Which practice most directly reduces the risk of a workload silently running a different image than the one that was actually reviewed and approved?

    1. Referencing images by a mutable tag such as :latest
    2. Referencing images by immutable digest (e.g. @sha256:...) from a trusted, access-controlled registry
    3. Disabling the image pull policy entirely
    4. Allowing any public registry, with no restriction at all

34. As a security control, what does shipping Kubernetes audit logs and runtime-detection alerts (from a tool like Falco) to a separate, tamper-evident store primarily protect against?

    1. Slow Pod scheduling times
    2. An attacker with cluster access being able to erase or alter the evidence of their own activity
    3. DNS resolution failures inside the cluster
    4. Node disk pressure

35. In a service mesh, what does mutual TLS (mTLS) between sidecar proxies provide that plain in-cluster networking doesn't, by default?

    1. Faster DNS resolution for Service names
    2. Cryptographically verified identity and encryption for service-to-service traffic
    3. Automatic image vulnerability scanning
    4. RBAC policy enforcement on API requests

36. What is the role of a tool like cert-manager in a cluster's overall security posture?

    1. It replaces kube-proxy's networking function
    2. It automates the issuance, renewal, and rotation of TLS certificates for workloads and ingress
    3. It scans container images for known vulnerabilities
    4. It enforces NetworkPolicy objects at the CNI layer

37. From a security standpoint, why is restricting an Ingress controller's exposed surface — allowed hosts, TLS termination — important?

    1. Because Ingress is the deliberately public entry point into the cluster, and misconfiguring it can expose internal services unintentionally
    2. Because Ingress controllers replace the need for authentication entirely
    3. Because all Ingress traffic is automatically encrypted with zero configuration required
    4. Because Ingress controllers run with no privileges at all, by design

38. Which of the following best describes what an admission controller enforces, and when in the request lifecycle?

    1. It enforces RBAC rules before authentication even occurs
    2. It validates or mutates an object after authentication and authorization both succeed, but before the object is persisted to etcd
    3. It only ever runs against kubectl delete requests
    4. It's entirely optional and can never actually reject a request

☁️ Domain 5 — Overview of Cloud Native Security (14% · Q39–45)

☺ Like you're 10: This domain is the one model that explains every other domain on this exam — four layers, nested like a set of dolls, each only as safe as the one around it.

This domain covers six competencies, and two questions go to the one that organizes everything else: the 4Cs (Q39–40), Cloud Provider & Infrastructure Security (Q41), Controls & Frameworks (Q42), Isolation Techniques (Q43), Artifact Repository & Image Security (Q44), and Workload & Application Code Security (Q45). The KCSA blueprint's own 4Cs section, plus the sibling Platform Engineering course's Kubernetes as the Platform Substrate, cover the Cloud and Cluster layers this domain leans on in real depth.

39. What are the four layers of the 4Cs of Cloud Native Security, from outermost to innermost?

    1. Container, Cluster, Cloud, Code
    2. Cloud, Cluster, Container, Code
    3. Code, Container, Cluster, Cloud
    4. Cluster, Cloud, Code, Container

40. Why does the 4Cs model matter for how you prioritize security fixes?

    1. Each layer is fully independent, so fixes can be made in any order with no consequence
    2. Hardening works outside-in — a compromised outer layer (e.g. Cloud) defeats every control inside it, no matter how well Cluster, Container, and Code are hardened
    3. The innermost layer, Code, is always the single most important layer to fix first
    4. The model applies only to on-premises clusters, never a managed cloud offering

41. Which of these sits in the "Cloud" layer of the 4Cs model, outside Kubernetes' own direct control?

    1. RBAC RoleBindings
    2. A cloud provider's IAM roles and the instance metadata endpoint
    3. NetworkPolicy objects
    4. Pod Security Admission labels

42. "Controls and frameworks," as a competency under this domain, refers most directly to:

    1. The exact version numbers of Kubernetes' own components
    2. Published standards and control catalogs — such as the CIS Benchmarks — that organizations map their security posture against
    3. A single vendor's proprietary security product
    4. The Kubernetes project's own release cadence

43. Which sequence correctly orders isolation techniques from weakest to strongest kernel-level boundary?

    1. Namespaces/cgroups (process-level) → seccomp/AppArmor (syscall-level) → a sandboxed runtime like gVisor/Kata (a stronger kernel boundary)
    2. NetworkPolicy → RBAC → Secrets
    3. Ingress → Service → Pod
    4. etcd → kube-apiserver → kubelet

44. What does restricting which registries a cluster is allowed to pull images from — an admission-time control — actually protect against?

    1. Node disk pressure
    2. Workloads silently pulling from an untrusted or already-compromised registry outside the organization's own supply chain
    3. DNS resolution failures
    4. etcd disk corruption

45. The "Code" layer of the 4Cs is the innermost, and this exam gives it the least direct attention. Why?

    1. Because application code can never be a realistic source of compromise
    2. Because it's the layer application security programs — secure coding practice, dependency scanning of your own code — already cover, and KCSA's own focus sits at the Cloud/Cluster/Container layers instead
    3. Because "Code" isn't actually part of the 4Cs model at all
    4. Because Kubernetes automatically secures all application code on its own

⚖️ Domain 6 — Compliance and Security Frameworks (10% · Q46–50)

☺ Like you're 10: This domain is the smallest slice of the test, and the one most people study last — which is exactly backwards, because it's also the cheapest to lock in.

Compliance and Security Frameworks covers four competencies: Compliance Frameworks (Q46–47), Threat Modeling Frameworks (Q48), Supply Chain Compliance (Q49), and Automation & Tooling (Q50). The sibling DevSecOps course covers this ground at full production depth in Compliance & governance and threat modeling, considerably past what these five questions need.

46. Which of the following is a widely referenced, Kubernetes-specific compliance and hardening benchmark?

    1. The CIS Kubernetes Benchmark
    2. The OSI seven-layer model
    3. The CAP theorem
    4. The twelve-factor app methodology

47. Broad regulatory or industry compliance frameworks such as SOC 2, PCI DSS, and ISO 27001 describe:

    1. Specific Kubernetes API server flags
    2. What a mature security and controls posture should look like, independent of any one specific platform
    3. A CNCF project's maturity stage
    4. A container runtime specification

48. Which of these is a threat-modeling framework, as distinct from a compliance framework?

    1. PCI DSS
    2. STRIDE, or MITRE ATT&CK for Containers
    3. SOC 2
    4. ISO 27001

49. How does supply chain compliance connect to an SBOM?

    1. It doesn't — the two are unrelated concepts
    2. An SBOM provides the component-level evidence that supply chain compliance obligations, such as proving exactly what went into a shipped artifact, can be checked against
    3. An SBOM is itself a type of admission controller
    4. An SBOM entirely replaces the need for RBAC

50. Why does this domain emphasize automation and tooling over manual, once-a-year audits?

    1. Because automated tooling is cheaper, and cost is the only real consideration
    2. Because a cluster's configuration changes continuously, so continuous, automated evidence-gathering is the only way compliance posture stays actually current rather than stale the day after an audit
    3. Because manual audits are explicitly prohibited by the CNCF
    4. Because automation removes the need for any human review, ever

Marking yourself, and what to do next

☺ Like you're 10: Your score is a thermometer, not a verdict — the list of what you got wrong is the actual point.

Count your correct answers out of 50. The number to beat is 75%, which on this paper is 38 of 50 — the Linux Foundation's own Multiple Choice Exam FAQ states plainly that a score of 75% or above must be earned to pass a multiple-choice exam, and KCSA is one. Don't read a pass here as a guaranteed pass there — this paper isn't calibrated to the real exam's difficulty or wording — but score yourself by domain, not just by total, because the pattern is what actually travels.

Where each domain is taught, if you need more than this paper

☺ Like you're 10: Every question above came from somewhere specific on this course — go back to that page, not to a search engine.

Nothing in this paper tests material this course doesn't teach. The KCSA blueprint is the direct answer key at exam depth for all six domains; the sibling Platform Engineering course's KCSA page covers the identical curriculum from a platform-engineer's angle if a second explanation of the same material helps something click.

Beyond the blueprint: the study plan & practice bank for a week-by-week plan, the glossary for anything a question here assumed you already knew, the Security: Defense in Depth deep dive for the Threat Model domain end to end, and how to study for a CNCF exam for technique that applies across every exam on this course's ladder.