KCSA Kubernetes and Cloud Native Security Associate Exam Topics and Questions

Cloud native security is the foundation everything else builds on. Before the exam tests you on specific Kubernetes controls, it checks whether you understand the layered model those controls fit into. This topic rewards candidates who can reason about where a given threat belongs in the stack and which layer is responsible for addressing it. Get the mental model wrong here and you will misread scenario questions throughout the rest of the exam.

– The layered model and infrastructure beneath it

The 4Cs (Cloud, Cluster, Container, Code) give you a ranked mental map of responsibility. The exam uses this map to test whether you know which layer owns a given problem. A misconfigured cloud provider setting cannot be patched at the container layer, and the exam will present scenarios that require you to identify that boundary correctly. Cloud provider and infrastructure security covers the physical and virtual substrate: network controls, IAM at the provider level, and the hardening of nodes before Kubernetes is even installed. Isolation techniques sit in this space too. The exam expects you to distinguish between VM-level isolation, namespace-based separation, and sandbox runtimes such as gVisor or Kata Containers, and to know which isolation mechanism is appropriate for a given threat scenario. Choosing the wrong isolation boundary is one of the most common ways candidates lose marks on this topic.

– Artifacts, images, and application code

Artifact repository and image security is where supply chain risk enters the picture. The exam tests your ability to identify what makes an image trustworthy: signing, scanning, minimal base images, and the controls that prevent unsigned or unscanned images from reaching a cluster. You need to know the role of a private registry versus a public one, and what controls sit at the boundary between them. Workload and application code security shifts the frame to what runs inside the container. This includes dependency management, secrets handling at the code level, and the principle that a vulnerability in application code is not a Kubernetes problem but the cluster must still limit its blast radius. Controls and frameworks tie this section together. The exam expects familiarity with recognised frameworks (CIS Benchmarks, NIST) at the level of knowing what they govern, not memorising their clause numbers.

How Overview of Cloud Native Security is tested

At 14% of the exam, this topic appears often enough to matter but is rarely the heaviest item cluster in any single sitting. Items here are almost always scenario-based: you are given a situation and asked to identify the correct layer of the 4Cs model, the appropriate isolation mechanism, or the right point in the image lifecycle to apply a control. The trap is that all four answer options will sound plausible if you only know the vocabulary. What separates the strongest option is precision about which layer owns the problem. Candidates lose marks by applying a container-layer fix to a cloud-layer problem, or by treating code-level controls as a substitute for infrastructure hardening. Items on artifact security reward knowing the sequence: scan before push, sign before deploy, enforce policy at admission. Candidates who treat this topic as introductory theory and skim it tend to miss the scenario-level nuance that the exam actually tests.

Where the previous topic set the conceptual frame, this one gets specific: every named component in a Kubernetes cluster is a potential attack surface, and the exam tests each of them. At 22%, this is one of the two heaviest topics on the exam. Expect to be asked about default configurations that are insecure, the flags and settings that harden each component, and the consequences of leaving them at their defaults. Vague familiarity with the architecture will not be enough.

– The control plane: API server, controller manager, and scheduler

The API server is the single most tested component in this group. The exam focuses on authentication and authorization modes, admission plugins that must be enabled, and flags that must be explicitly set to disable insecure defaults (anonymous authentication, the insecure port, and profiling endpoints are recurring themes). You need to know which flags do what, not just that the flags exist. The controller manager and scheduler are tested at a lighter depth but the exam still expects you to know which service account tokens they use, how their kubeconfig files should be protected, and why binding them to localhost matters. Candidates who only know the API server and skip the other control plane components routinely drop marks here.

– Node-level components: kubelet, container runtime, and KubeProxy

The kubelet is the second most heavily tested component in this topic. Anonymous access to the kubelet API is a well-known attack path, and the exam tests both the flag that closes it and the authorization mode that replaces it. Read-only port exposure is another area where the exam expects a precise answer. Container runtime security covers the interface between Kubernetes and the runtime (containerd, CRI-O), including why the runtime must not run as root and how runtime classes map to isolation mechanisms covered in the previous topic. KubeProxy is tested more narrowly: the exam is interested in its RBAC footprint and network exposure rather than its iptables mechanics in depth.

– Pods, etcd, networking, clients, and storage

Etcd deserves more attention than many candidates give it. The exam tests encryption at rest for etcd data, mutual TLS between the API server and etcd, and the consequence of leaving etcd accessible without authentication (full cluster compromise). Pod security at the component level here overlaps with Topic 3 but the angle is different: this section is about the pod spec settings that the component itself enforces or fails to enforce. Container networking is tested through the lens of what is exposed by default and how to limit it. Client security covers kubectl configuration, kubeconfig file permissions, and credential management. Storage touches persistent volume access modes and the risk of hostPath mounts, which the exam treats as a privilege escalation vector.

How Kubernetes Cluster Component Security is tested

At 22%, this topic will account for a significant portion of what you face. Items are almost always configuration-focused: you are given a component, a threat, and asked which setting, flag, or combination of settings addresses it. The strongest options are specific, not directional. Saying "restrict access" is not enough; the exam rewards knowing the exact mechanism. Candidates lose marks in two predictable ways. First, confusing which flags belong to which component (API server flags applied to the kubelet, for example) produces wrong answers even when the underlying concept is correct. Second, knowing that a default is insecure without knowing the replacement setting leaves you unable to pick between two plausible options. Etcd is a consistent source of missed marks because candidates deprioritise it. Items on etcd reward knowing both the encryption configuration and the transport security separately, because the exam treats them as distinct controls.

Tied with cluster component security at 22%, this topic shifts from individual components to the cluster-wide policies and controls that govern what workloads can do. The previous topic asked whether each component is hardened. This one asks whether the rules enforcing workload behaviour are configured correctly. The two topics reinforce each other: a misconfigured admission controller (Topic 2) can silently bypass the pod security standards you set here.

– Pod security: standards and admission

Pod Security Standards define three policy levels: Privileged, Baseline, and Restricted. The exam tests what each level permits and prohibits, and the consequences of applying the wrong level to a namespace. Pod Security Admission is the built-in enforcement mechanism that replaced the deprecated PodSecurityPolicy. You need to know the three modes (enforce, audit, warn) and how they interact: a namespace can have different modes for different policy levels simultaneously, and the exam will test whether you understand what happens at each mode boundary. The most common trap is conflating the policy level with the enforcement mode. They are independent axes, and the exam exploits that confusion.

– Identity: authentication and authorization

Authentication in Kubernetes covers the mechanisms by which identities are established: client certificates, bearer tokens, service account tokens, and OIDC. The exam tests which mechanism is appropriate in which context, and the security properties of each. Service account token auto-mounting is a specific area where the exam expects a precise answer: knowing that you can disable it and why you should is more examinable than the token format itself. Authorization focuses almost entirely on RBAC. The exam tests role vs. cluster role, role binding scope, and the principle of least privilege as applied to service accounts. Candidates who understand RBAC conceptually but cannot reason about the effect of a specific ClusterRoleBinding will lose marks on scenario items.

– Secrets, isolation, audit logging, and network policy

Secrets in Kubernetes are base64-encoded by default, which is not encryption. The exam tests this distinction and the controls that provide actual protection: encryption at rest via EncryptionConfiguration, and the access controls that limit which pods and users can read a secret. Isolation and segmentation here is about namespace boundaries and their limits: namespaces are not a security boundary on their own, and the exam tests what additional controls (network policy, RBAC, pod security) are needed to make them meaningful. Audit logging is tested at the policy level: what gets logged, at what verbosity, and how to configure the audit policy to capture security-relevant events without generating unmanageable volume. Network Policy is tested through scenario items: given a set of pods and a traffic requirement, which policy configuration achieves the intended isolation without over-restricting.

How Kubernetes Security Fundamentals is tested

The 22% weight means this topic appears throughout the exam, and its items tend to be the ones where candidates feel confident but drop marks on detail. The most common pattern is a scenario where you know the right control but not its exact scope or mode. Pod security admission items reward understanding the enforce-audit-warn distinction under realistic conditions. RBAC items reward tracing the effect of a binding, not just naming the resource type. Secrets items reward knowing the gap between storage and access control. The audit logging sub-topic produces items where you must read a policy excerpt and determine what it would or would not capture. Candidates who have only read about these controls without practising their configuration logic consistently pick the option that is directionally correct but scoped too broadly or too narrowly. Network policy items are particularly unforgiving: a policy that almost works is as wrong as one that does nothing.

After two topics focused on configuration, this one asks you to think like an attacker. At 16%, it tests whether you can map a threat to the cluster component or control it targets, reason about how an attacker moves through a compromised environment, and identify which defensive control interrupts that movement. Candidates who treated Topics 2 and 3 as checklists rather than security reasoning will find this topic harder than its weight suggests.

– Trust boundaries, data flow, and network-based threats

Kubernetes trust boundaries define where the cluster stops trusting a caller by default and requires explicit authentication or authorization. The exam tests whether you can identify which boundary a given attack crosses: a request from a pod to the API server crosses a different boundary than a request from the kubelet to etcd, and the controls at each crossing are different. Data flow mapping is tested in the context of identifying what sensitive information travels where and what could intercept it. Attacker-on-the-network scenarios focus on what an adversary with network access to the cluster can observe or manipulate without credentials, and which controls (mTLS, network policy, encryption in transit) close those paths.

– Persistence and privilege escalation

Persistence in a Kubernetes cluster looks different from persistence on a single host. The exam tests the mechanisms an attacker uses to survive a pod restart or a credential rotation: creating additional service accounts, modifying RBAC bindings, deploying DaemonSets, or abusing CronJobs. You need to know what audit log entries these actions produce and which RBAC controls prevent them. Privilege escalation is one of the most heavily tested sub-topics in this section. The exam focuses on the paths from a low-privilege pod to cluster-admin: hostPath mounts reaching sensitive node files, privileged containers, excessive service account permissions, and the ability to create pods with elevated specs. Items reward knowing which specific permission enables which escalation path.

– Denial of service, malicious code execution, and sensitive data access

Denial of service in a Kubernetes context is not just about network floods. The exam tests resource exhaustion at the pod and node level: missing resource limits, missing LimitRange objects, and the absence of ResourceQuota allowing one tenant to starve another. Malicious code execution in a container is tested through the lens of what the attacker can do once inside: the exam focuses on what container capabilities, host mounts, and network access expand the blast radius, and which controls contain it. Access to sensitive data covers the paths to secrets, environment variables, and mounted volumes from within a compromised container, as well as the cloud provider metadata API as an often-overlooked data source. Items here reward knowing the specific access path, not just the general category of risk.

How Kubernetes Threat Model is tested

At 16%, this topic produces some of the most scenario-dense items on the exam. You are rarely asked to name a threat category in isolation. Instead, you are given a situation (a pod with specific permissions, a network topology, a set of enabled features) and asked to identify the most realistic attack path or the control that breaks it. The strongest options in these items are specific about mechanism: not "restrict pod permissions" but the precise permission or spec field that matters. Candidates lose marks by identifying the right threat category but selecting a control that addresses a different attack path within that category. Privilege escalation items are particularly precise: the exam distinguishes between escalation via hostPID, via a mounted service account token, and via an overly permissive ClusterRole, and those distinctions change the answer. Persistence items reward knowing which Kubernetes resources an attacker would create, not just which files they would modify on a traditional host.

Platform security covers the controls that sit above individual cluster components but below application code: the tooling, infrastructure, and policies that the platform team owns. Coming after the threat model topic, this section asks you to apply defensive controls to the attack paths you just studied. At 16%, it carries the same weight as the threat model and rewards candidates who understand how platform-level decisions propagate security properties (or vulnerabilities) to every workload running on top.

– Supply chain, image repository, and admission control

Supply chain security at the platform level is about the pipeline from source code to running container: what controls exist at each stage, how artefacts are signed, and how the cluster verifies that what is deployed matches what was approved. The exam tests the role of image signing and verification tools, and what admission control must enforce to close the gap between a signed image and a running pod. Image repository controls cover access policies, scanning integration, and the difference between a registry that stores images and one that enforces policy on them. Admission control ties this group together: the exam tests both built-in admission plugins and webhook-based admission controllers, their order of execution, and what happens when one is misconfigured or missing.

– Observability and service mesh

Observability in a security context means knowing what is happening in the cluster well enough to detect anomalous behaviour. The exam tests the distinction between logging (what happened), metrics (how much), and tracing (where in the call path), and which of those is most relevant for detecting a specific class of incident. This is not a deep monitoring theory question: the exam is interested in whether you know which observability signal surfaces a given threat. Service mesh is tested through its security properties: mutual TLS between services, traffic policy enforcement, and the access control capabilities that a mesh like Istio or Linkerd adds beyond what Kubernetes network policy provides. The exam does not test mesh configuration syntax; it tests what a mesh does and does not guarantee.

– PKI, connectivity, and broader platform controls

PKI in a Kubernetes cluster is more pervasive than many candidates realise. The exam tests certificate authorities, certificate rotation, and the consequences of an expired or mis-issued certificate on cluster operation and security. Knowing which components use which certificates and what breaks when one expires is more examinable than the mathematical properties of the certificates themselves. Connectivity covers how traffic enters and exits the cluster: ingress controllers, egress controls, and the security properties of each. The exam tests what a misconfigured ingress exposes and what controls limit egress to known destinations. Admission control appears in this group's context as well, reinforcing its role as the enforcement point where platform policy meets workload deployment.

How Platform Security is tested

Platform security items tend to test integration: not whether you know what a service mesh does, but whether you know what it does that network policy alone does not. The strongest options in this topic are precise about the gap a control fills. Candidates lose marks by selecting a control that addresses the right category of threat but at the wrong layer (for example, choosing a network policy solution for a supply chain problem). Supply chain items reward understanding the full pipeline and knowing where each verification step must occur. PKI items are often framed around failure scenarios: what happens when a certificate expires, which component fails first, and which control would have caught it earlier. Admission control items reward knowing the difference between a validating and a mutating webhook, and which one is appropriate for a given enforcement requirement. Observability items are the most frequently underestimated: candidates who skim this sub-topic consistently miss the distinction between what each signal type captures.

At 10%, this is the lightest topic on the exam, but candidates who dismiss it lose marks they did not need to lose. The questions here are not asking you to memorise framework documents. They test whether you can map a compliance requirement to the Kubernetes control that satisfies it, choose the right framework for a given organisational context, and understand how automated tooling fits into a continuous compliance posture. The conceptual work from every earlier topic feeds directly into the answers here.

– Compliance and threat modelling frameworks

Compliance frameworks in the Kubernetes context include CIS Benchmarks, NIST SP 800-190, and SOC 2 controls as they apply to container environments. The exam does not test clause numbers. It tests whether you know which framework governs which aspect of the stack and what kind of evidence or control each framework expects. Choosing the wrong framework for a given regulatory context is a common source of missed marks. Threat modelling frameworks (STRIDE, PASTA, and similar) are tested at the level of knowing what each framework produces and when to apply it. The exam is interested in whether you can match a threat modelling approach to a scenario, not whether you can execute the framework in full detail.

– Supply chain compliance and automation

Supply chain compliance connects the framework knowledge from the previous group to the pipeline controls from Topic 5. The exam tests whether you know which compliance requirements apply to the software supply chain specifically (SLSA levels, for example) and what controls in a Kubernetes environment satisfy them. This is one of the few places in the exam where the same control (image signing, admission policy) appears in both a technical and a compliance framing, and the exam exploits that dual framing in its items. Automation and tooling covers the tools that make compliance continuous rather than point-in-time: policy engines, CIS benchmark scanners, and admission controllers configured to enforce compliance policy automatically. The exam tests the role of each tool category, not the syntax of any specific tool. Candidates who know the tools from earlier topics but have not thought about them in a compliance context will find this sub-topic straightforward once they make that connection.

How Compliance and Security Frameworks is tested

At 10%, this topic contributes a smaller share of items, but those items are disproportionately missed by candidates who treat frameworks as background reading. Items here reward the ability to match: match a framework to a use case, match a compliance requirement to a control, match a tooling category to a compliance outcome. The trap is that multiple frameworks will seem relevant in a given scenario, and the exam is testing whether you know which one is most appropriate for the specific context described. Supply chain compliance items are the most specific: they require knowing which level of assurance a given control provides, not just that the control exists. Automation items reward knowing what a policy engine enforces versus what a scanner only reports. Candidates who have practised the earlier topics thoroughly will find that most of this topic's answers are already in their heads; the remaining work is learning the framework vocabulary well enough to recognise which label applies.