KCSA Mock Exam · Set 2

Correct: B. Authentication and authorization are separate stages — anonymous auth doesn't skip authorization, it just lets an unauthenticated request through to it under the system:anonymous identity, in the system:unauthenticated group. If any RBAC binding grants that identity or group anything at all, an attacker needs no credentials to use it. (A) inverts the actual risk: anonymous auth being enabled is precisely what lets the request past authentication in the first place. (C) invents a Dashboard-only scope the flag doesn't have — it governs the API server's own authentication pipeline. (D) confuses two unrelated settings; anonymous authentication and transport encryption are independent concerns.

Correct: A. Every Kubernetes object the API server persists lives in etcd, and a Secret without encryption-at-rest configured is stored there merely base64-encoded — trivially readable by anyone who can read etcd directly. That's the exact reason KCSA's curriculum treats owning etcd as equivalent to owning the whole cluster. (B) invents a separate Secrets datastore that doesn't exist; Secrets live in etcd exactly like every other object. (C) is false — etcd stores full object bodies, not just metadata. (D) misattributes scheduling: the scheduler makes its decision in memory and the API server persists the result to etcd, but etcd access alone doesn't let an attacker schedule anything — it lets them read and, with write access, forge state.

Correct: C. The read-only port serves a read-only subset of the kubelet API — Pod specs, node info, and more — with zero authentication or authorization, entirely independent of how tightly the authenticated port is locked down. Reconnaissance information (running Pods, mounted volumes, image names) leaks straight through it. (A) overclaims: the port is deprecated and disabled by default on recent kubelets, but "deprecated" is not "impossible to enable," and older or misconfigured nodes are exactly what this question describes. (B) overreaches — the read-only port doesn't expose exec or command execution, only read endpoints; that capability sits on the authenticated port. (D) understates real exposure — Pod specs and node state are meaningful reconnaissance for an attacker planning a next move.

Correct: B. A sandboxed runtime interposes a user-space kernel (gVisor) or a lightweight VM boundary (Kata) between the container and the real host kernel, which is exactly the layer a runtime-escape risk needs — seccomp and AppArmor profiles help but still share the same underlying kernel that a sufficiently serious escape can reach. (A) controls network reachability, unrelated to a kernel-level escape. (C) controls resource consumption, not isolation boundary. (D) only ever tells you an escape happened after the fact — it doesn't prevent one.

Correct: A. Client security is exactly this risk: a kubeconfig is a bearer credential, and a long-lived, broadly-privileged one sitting in a default path gets swept into laptop backups, screen-share sessions, and stolen-device incidents far more often than any cluster-side control gets breached directly — which is why short-lived, OIDC- or exec-plugin-backed credentials are the fix the curriculum expects. (B) is a real networking concern but not a client-credential exposure. (C) describes a properly hardened Pod, the opposite of a risk. (D) describes ordinary, safe default Service behavior.

Correct: B. Pod Security Standards are the three named policy levels (privileged, baseline, restricted); Pod Security Admission is the built-in controller that enforces one of those levels, configured entirely through namespace labels like this one, in one of three modes (enforce, audit, warn). (A) confuses a policy level with an admission controller — the label configures an existing controller, it doesn't install a new one. (C) describes the deprecated, removed PodSecurityPolicy API, an unrelated and retired mechanism. (D) mismatches the mode: enforce genuinely rejects non-conforming objects; only the separate audit and warn labels are non-blocking.

Correct: B. NetworkPolicy is additive and strictly directional — a policy only restricts the traffic directions actually named in its own policyTypes. With no Egress entry at all, egress for these Pods is untouched by this policy, and stays at whatever the cluster's baseline behavior already was. (A) is the single most common NetworkPolicy misconception on this exam — one policy touching a Pod does not silently lock down every direction it doesn't mention. (C) invents an egress restriction the spec never defines. (D) is false; nothing in the stem restricted egress before this policy was applied.

Correct: B. Base64 is an encoding, not encryption — trivially reversible by anyone with read access to the object or to etcd directly. Genuine protection at rest requires configuring an EncryptionConfiguration on the API server, or moving the value into an external secrets manager. (A) fabricates automatic key management that doesn't exist by default. (C) would make the value unrecoverable, which defeats the purpose — Secrets must remain retrievable by the workloads that consume them. (D) is false; Secrets are stored in etcd exactly like every other Kubernetes object.

Correct: B. Kubernetes audit levels form a hierarchy — None, Metadata, Request, RequestResponse — and Metadata captures request metadata only (who, when, verb, resource) while RequestResponse additionally captures the full bodies, which is exactly why the "crown jewels" resources get the heavier, more expensive level here. (A) denies a real and deliberate distinction. (C) is false; audit levels apply to reads and writes alike, governed by the policy's rules, not by verb type alone. (D) has the hierarchy inverted — RequestResponse is the more verbose level, not Metadata.

Correct: C. Kubernetes deliberately has no first-class User API object — a human's identity is whatever the authentication plugin asserts (a cert's Common Name, an OIDC token's claims), and RBAC then binds Roles or ClusterRoles to that asserted name or group. (A) and (D) both invent an object that plainly doesn't exist in the API. (B) confuses human authentication with the separate mechanism built specifically for workload identity — a ServiceAccount is a real API object, but it's not what represents an authenticated human.

Correct: B. A privileged container removes normal kernel capability restrictions, and mounting the host's root filesystem hands the container a writable path onto the node itself — the textbook combination the curriculum's Privilege Escalation competency describes as an attacker's route from "inside one container" to "controls the node." (A) describes an availability attack, not the escalation risk this configuration creates. (C) is an unrelated domain entirely. (D) describes lateral movement across the network, not privilege escalation on a single node.

Correct: B. Persistence is specifically about surviving past the original point of compromise — a rogue CronJob re-establishes access on a schedule, and a malicious mutating webhook can tamper with every matching object cluster-wide, independent of whether any one Pod is still running. (A) describes reconnaissance (Access to Sensitive Data), not persistence. (C) describes Denial of Service. (D) describes reconnaissance for lateral movement, not a mechanism for surviving cleanup.

Correct: C. The baseline Kubernetes networking model is flat and NAT-less — every Pod can reach every other Pod, across every namespace, unless a NetworkPolicy explicitly restricts it. That single fact is why "Attacker on the Network" carries real weight on this exam: lateral movement after one compromised Pod is trivial by default. (A) invents a namespace boundary that has no effect on networking without an explicit policy. (B) inverts the actual default — no policy means no restriction, not implicit deny. (D) confuses Service endpoint membership with network-layer reachability; a Pod not listed as a Service endpoint is still directly reachable by IP.

Correct: B. Absent an explicit automountServiceAccountToken: false, Kubernetes still mounts a ServiceAccount token into the Pod by default — and whatever RBAC that ServiceAccount is bound to becomes immediately available to anyone who gets code execution in the Pod, even when the application itself never calls the Kubernetes API. That's exactly the Access to Sensitive Data path this competency is built around. (A) misstates current default behavior — auto-mounting is still the default; only the setting to disable it has existed for a long time. (C) confuses an unrelated concept (image build secrets) with the ServiceAccount token mechanism. (D) understates the exposure — the token's actual permissions depend entirely on RBAC, which can be far broader than log access.

Correct: B. Signing an image proves provenance, but proof is worthless unless something actually checks it before the workload runs — an admission controller enforcing signature verification is the step that turns "we sign our images" into "unsigned images cannot start," and it's the step this domain's curriculum specifically calls out as commonly missed. (A) is the exact misconception the question is testing — a signature that nothing verifies stops nothing. (C) adds redundant provenance data without closing the actual gap, which is enforcement, not documentation. (D) protects confidentiality at rest, unrelated to verifying what's about to run.

Correct: B. A tag is just a mutable pointer in the registry — nothing stops it from being pushed again tomorrow to point at a completely different image, silently invalidating every scan and signature that was ever performed against "that tag." A digest (@sha256:...) pins the exact, immutable content, which is why hardened admission policy typically requires digests rather than tags. (A) denies the entire point of digest pinning as a control. (C) understates real risk — this is a supply-chain integrity gap, not a performance concern. (D) is false; the OCI spec permits mutable tags, it's simply a registry convention, not a technical restriction.

Correct: B. The mesh's sidecar terminates and originates mTLS on the application's behalf, so both sides of a connection prove identity to each other and the traffic between them is encrypted in transit, all without the application itself handling any TLS logic. (A) overreaches — mTLS establishes transport-layer identity and encryption; RBAC governs a completely separate layer, API authorization, and neither replaces the other. (C) confuses transport encryption between Pods with etcd's own encryption-at-rest, an unrelated control. (D) overstates mTLS's role — it secures the transport, but a NetworkPolicy still restricts which Pods may even attempt a connection in the first place; the two are complementary, not substitutes.

Correct: C. Kubernetes always runs the full mutating admission phase before the validating phase, precisely so a validating webhook sees the final, already-mutated object — which is exactly what makes the sidecar-injection-then-require-the-sidecar pattern in the stem work at all. (A) has the order backwards. (B) invents randomness where the chain is in fact deterministic by phase. (D) is false — a cluster can register any number of both webhook types simultaneously.

Correct: A. The dependency runs outside-in: you cannot secure a container running on a compromised cluster, and you cannot secure a cluster running on compromised cloud infrastructure. That's the entire exam point of drawing the 4Cs as nested rectangles rather than four unrelated checkboxes — a control placed at the wrong layer is theater if the layer containing it is already lost. (B) denies real security meaning behind a deliberate design choice. (C) inverts the model outright. (D) is false and contradicted by real incident data across all four layers — cloud IAM misconfiguration and container escapes are both well-documented attack classes.

Correct: B. The isolation-techniques competency runs a real ladder — namespaces and cgroups isolate processes within one shared kernel, sandboxed runtimes strengthen that kernel boundary, and fully separate clusters (or dedicated node pools) remove the shared-kernel and shared-control-plane assumption entirely — the strongest boundary on the list, at real operational cost. (A) understates namespaces' guarantee — they scope naming and RBAC, not kernel isolation, and two Pods in different namespaces on the same node still share a kernel. (C) is a container-level runtime restriction, not a tenant-separation technique. (D) is an RBAC construct entirely unrelated to kernel or infrastructure isolation.

Correct: B. Cloud instance metadata endpoints commonly serve the node's own IAM role credentials, and a token-less, unrestricted version reachable from any Pod turns "code execution in one container" into "valid cloud credentials for the node's role" — exactly the outside-in dependency the 4Cs model warns about, since this is a Cloud-layer gap no Cluster- or Container-layer control can fully compensate for. (A) significantly understates what these endpoints actually serve. (C) invents an unrelated billing-only scope. (D) is false — Kubernetes itself has no awareness of or default restriction on cloud metadata endpoint reachability; that has to be enforced separately, commonly with a NetworkPolicy or the provider's session-token-required mode.

Correct: A. Compliance frameworks like the CIS Kubernetes Benchmark give specific, checkable "is this setting configured correctly" recommendations; threat-modeling frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) give a structured way to reason about what an attacker might do, independent of any one checklist. (B) swaps the two roles exactly backwards. (C) mischaracterizes both PCI DSS and SOC 2, which are compliance and controls frameworks, not attacker-behavior models. (D) is false — NIST SP 800-190 is a container-security guidance document, and MITRE ATT&CK for Containers is a distinct, separately maintained attacker-tactics knowledge base.

Correct: B. The Supply Chain Compliance competency is exactly this connective tissue — an SBOM is the artifact-level record of what actually went into a build, and retaining it per release is what lets a team answer "prove this artifact's provenance" against a named obligation. (A) is an operational metric with no provenance content at all. (C) is a network-security control, unrelated to artifact provenance. (D) records who deployed something, not what that something was actually built from.

Correct: B. A point-in-time audit only proves compliance at the moment it was taken — any drift afterward is invisible until the next one. The Automation & Tooling competency's actual point is that policy-as-code (admission-time checks, continuous scanning) replaces a once-a-year snapshot with continuous evidence, catching drift the same day it happens instead of months later. (A) just shrinks the same blind-spot window without closing it. (C) denies that drift is even a real risk, which is the opposite of what this competency argues. (D) proposes manual vigilance as a substitute for automation — exactly the failure mode this competency exists to move a team away from.

1. Kubernetes Cluster Component Security 22%, Kubernetes Security Fundamentals 22%, Kubernetes Threat Model 16%, Platform Security 16%, Overview of Cloud Native Security 14%, Compliance and Security Frameworks 10% — summing to 100%. The top two domains together are 44% of the paper, close to half, so they carry a matching share of the clock — 20 of 90 minutes each.
2. It leaves egress traffic from the selected Pods completely unaffected, because NetworkPolicy is additive and directional — a policy only restricts the traffic directions actually named in its own policyTypes, and this one names only Ingress.
3. Because anonymous authentication only controls whether an unauthenticated request is let past the authentication stage at all — it still lands on the system:anonymous identity in authorization, and only becomes dangerous if any RBAC binding grants that identity or the system:unauthenticated group any permission.
4. Because the 4Cs are nested, not parallel — each layer's security guarantees rest on the layer that contains it. If the Cloud layer is compromised (stolen node IAM credentials, a hijacked managed control plane), an attacker can bypass Cluster, Container, and Code controls entirely rather than fighting through them.
5. The CIS Kubernetes Benchmark is a compliance framework — specific, checkable hardening recommendations. STRIDE is a threat-modeling framework — a structured way to reason about categories of attacker behavior (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege), independent of any one checklist.
6. 75%, per the Linux Foundation's Multiple Choice Exam FAQ. On this 100-point paper that leaves only 25 points of margin — tighter than most candidates assume going in.
7. Because a guessed single-best-answer question still has a real, non-zero chance of scoring the full point value, while a blank answer has a guaranteed zero — there is no penalty for a wrong guess on this exam format, so leaving anything unanswered is pure lost expected value.