Courseiva

CCNA Kubernetes Threat Model Questions

47 questions · Kubernetes Threat Model · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

What is the security risk of configuring `privileged: true` in a container's SecurityContext?

A.It restricts the container from writing to any attached volume.
B.It disables container isolation, granting full access to host devices and kernel capabilities
C.It forces the API server to reject all incoming TLS client requests.
D.It prevents the application from reading its own environment variables.
AnswerB

Privileged mode removes the container's namespace and cgroup isolation, giving the process unrestricted access to host devices and all kernel capabilities. This directly satisfies the stem's risk: a compromised container effectively gains root-equivalent control of the host node, defeating the containment that ordinary SecurityContext restrictions provide.

Why this answer

Setting `privileged: true` in a container's SecurityContext gives the container all Linux capabilities available to the host and disables the default isolation mechanisms (namespaces, cgroups restrictions, seccomp/AppArmor defaults). The container can then access host devices like /dev, mount filesystems, load kernel modules, and effectively act as root on the node. This is why privileged containers are considered a critical security risk in Kubernetes.

Exam trap

KCSA often tests the misconception that privileged mode is a minor permission tweak rather than a full removal of container isolation — candidates who confuse it with capabilities or readOnlyRootFilesystem pick the wrong option.

How to eliminate wrong answers

Option A is wrong because privileged mode actually grants broader write access to volumes and devices, not restricts it — volume write restrictions come from readOnly flags or filesystem permissions, not privileged mode. Option C is wrong because TLS client request handling is a function of the API server's authentication and admission configuration, not of a pod's SecurityContext. Option D is wrong because environment variables are injected by the kubelet into the container's process environment regardless of privileged status; privileged mode does not block env var reads.

Practice this question →
2
MCQhard

A security auditor reviews a Kubernetes cluster threat model and identifies that the Kubelet API on port 10250 permits unauthenticated requests if not configured properly. What authentication and authorization mode should be enforced on the Kubelet to prevent unauthorized remote code execution?

A.Enforcing Basic HTTP Authentication headers in kubelet configuration files
B.Disabling the Kubelet API entirely by turning off port 10250
C.Enabling anonymous requests with strict NetworkPolicy egress rules
D.Kubelet Authentication Mode set to Webhook and Authorization Mode set to Webhook
AnswerD

Configuring both authentication and authorization to Webhook makes the Kubelet validate client certificates or tokens against the API server and then check RBAC, closing the anonymous, unauthenticated access that enables remote code execution on port 10250.

Why this answer

The Kubelet exposes an HTTPS endpoint on port 10250 that, if left with anonymous authentication enabled and authorization mode AlwaysAllow, allows any unauthenticated client to execute commands in pods (e.g., via /exec, /run, /logs). Setting authentication to Webhook makes the kubelet validate client certificates or bearer tokens against the API server via SubjectAccessReview, and setting authorization to Webhook makes the kubelet delegate authorization decisions to the API server using the same mechanism. Together these enforce that only authenticated, RBAC-authorized identities (nodes, system components, or admins) can call the kubelet API.

Exam trap

KCSA often tests the misconception that NetworkPolicy or disabling the port can secure the kubelet, when the actual control is the kubelet's own authentication and authorization mode settings.

How to eliminate wrong answers

Option A is wrong because Basic HTTP Authentication is deprecated and removed from kubelet; it was never a robust mechanism and does not integrate with cluster RBAC. Option B is wrong because port 10250 is required for the control plane to manage pods, retrieve logs, and execute probes; disabling it breaks the cluster. Option C is wrong because enabling anonymous requests is precisely the misconfiguration being remediated, and NetworkPolicy cannot protect the kubelet's host-network endpoint from in-cluster attackers.

Practice this question →
3
MCQhard

An organization wants to prevent supply chain attacks where malicious code is injected into third-party Helm charts before deployment. What mitigation technique provides cryptographic verification of Helm chart integrity and authenticity?

A.Restricting etcd database access using client certificate authentication
B.Verifying Helm chart provenance files using cryptographic signatures and public key rings
C.Disabling anonymous requests in the kube-apiserver configuration
D.Enabling Pod Security Standards in the target namespace
AnswerB

Helm provenance files contain a signed hash of the chart, verified against a public key ring. This cryptographic signature confirms the chart's origin and that its contents were not altered, satisfying the requirement to detect malicious code injected into third-party charts before deployment.

Why this answer

Helm supports provenance files (.prov) generated with helm package --sign, which use PGP/GPG signatures and a public key ring to cryptographically verify that a chart was produced by a trusted party and has not been altered. Running helm verify or installing with --verify checks the chart's integrity and authenticity against the keyring, directly mitigating tampered or injected third-party charts.

Exam trap

KCSA often tests whether candidates confuse chart provenance verification (integrity/authenticity of Helm artifacts) with cluster-side hardening controls like etcd access, anonymous request disabling, or Pod Security Standards, which address different layers of the attack surface.

How to eliminate wrong answers

Option A (Restricting etcd database access using client certificate authentication) is wrong because etcd access control protects cluster state at rest, not the integrity of Helm charts before deployment. Option C (Disabling anonymous requests in the kube-apiserver configuration) is wrong because it hardens API server authentication but does nothing to verify chart provenance or detect injected code. Option D (Enabling Pod Security Standards in the target namespace) is wrong because PSS restricts pod-level privileges at admission time and cannot detect malicious code embedded in a chart's templates or images.

Practice this question →
4
MCQmedium

A security engineer identifies that an enterprise Kubernetes cluster has several cluster-admin bindings granted to user accounts that have left the company. Which Kubernetes security principle has been violated?

A.NetworkPolicy ingress traffic isolation
B.Principle of Least Privilege and proper identity/access lifecycle management
C.Pod Security Standards baseline enforcement
D.Container image vulnerability scanning policies
AnswerB

Departed users retaining cluster-admin bindings violates least privilege because excessive rights persist beyond their need, and it breaches access lifecycle management, which requires revoking permissions when identities leave. Microsoft Entra ID-integrated clusters should remove or disable those accounts, eliminating stale privileged bindings that attackers could exploit.

Why this answer

The presence of cluster-admin bindings for departed users violates the Principle of Least Privilege and proper identity/access lifecycle management. Least Privilege dictates that users should have only the permissions necessary for their role, and lifecycle management ensures access is revoked when users leave. Cluster-admin is the most powerful role and should be tightly controlled and audited.

Exam trap

KCSA often tests the ability to map a security misconfiguration (orphaned cluster-admin bindings) to the correct principle (Least Privilege and identity lifecycle), with distractors about network policies or pod security.

How to eliminate wrong answers

Option A is wrong because NetworkPolicy ingress isolation is about controlling pod-level network traffic, not user access permissions. Option C is wrong because Pod Security Standards baseline enforcement governs pod security contexts (e.g., privileged containers), not RBAC bindings. Option D is wrong because container image vulnerability scanning is about detecting vulnerabilities in images, not managing user access.

Practice this question →
5
MCQeasy

An administrator notices that a compromised Pod is attempting to access the cloud provider metadata service to retrieve IAM role credentials. Which native Kubernetes resource is best suited to block this specific attack vector at the network layer?

A.ResourceQuota
B.NetworkPolicy
C.ValidatingWebhookConfiguration
D.SecurityContext
AnswerB

NetworkPolicy selects Pods by label and enforces ingress and egress rules at layer 3/4, so an egress rule can block traffic to the metadata endpoint. It satisfies the stem's requirement for a native Kubernetes resource blocking this vector at the network layer.

Why this answer

A NetworkPolicy is a Kubernetes resource that controls traffic flow at the IP address and port level (Layer 3/4). By defining egress rules, you can block a compromised Pod from reaching the cloud provider's metadata service (e.g., 169.254.169.254), thus preventing credential theft. This is the native Kubernetes network-layer control for such attack vectors.

Exam trap

The trap is confusing network-layer controls with admission or resource controls; candidates might pick SecurityContext or ValidatingWebhookConfiguration, but only NetworkPolicy operates at the network layer to block specific IPs.

How to eliminate wrong answers

Option A is wrong because ResourceQuota limits resource consumption (CPU, memory, object counts) within a namespace, not network traffic. Option C is wrong because ValidatingWebhookConfiguration is used for admission control of API requests, not for runtime network blocking. Option D is wrong because SecurityContext defines privilege and access control settings for Pods/containers (e.g., runAsUser), not network policies.

Practice this question →
6
Multi-Selecthard

Which THREE of the following mechanisms are essential for securing the Kubernetes control plane against unauthorized access and privilege escalation?

Select 3 answers
A.Enforcing robust Role-Based Access Control (RBAC) with least privilege principles
B.Requiring mutual TLS (mTLS) for all internal API server and component communications
C.Using mutable `:latest` image tags for all control plane system components
D.Enabling encryption at rest for sensitive data stored in etcd
E.Setting `allowPrivilegeEscalation: true` across all default container security contexts
AnswersA, B, D

RBAC binds Kubernetes API requests to identities and restricts verbs and resources through Roles and ClusterRoles, satisfying the least-privilege constraint. Without it, any authenticated principal could escalate by creating privileged workloads. It is essential, though insufficient alone: authentication and admission controls must complement it.

Why this answer

Option A is correct because robust RBAC with least-privilege principles ensures that users, service accounts, and controllers only receive the exact permissions they need, preventing unauthorized access and privilege escalation within the cluster. Option B is correct because requiring mutual TLS (mTLS) for all internal API server and component communications authenticates both ends of every connection, protecting against man-in-the-middle attacks, spoofing, and unauthorized components joining the control plane. Option D is correct because enabling encryption at rest for sensitive data stored in etcd protects secrets, tokens, and configuration from being read directly from the backing datastore if it is compromised.

Option C is incorrect because mutable `:latest` image tags make deployments non-deterministic and can silently pull vulnerable or malicious images, weakening rather than strengthening control plane security. Option E is incorrect because setting `allowPrivilegeEscalation: true` explicitly permits containers to gain more privileges than their parent process, which directly enables privilege escalation and should be set to false.

Exam trap

KCSA often tests whether candidates recognize that allowPrivilegeEscalation: true and mutable :latest tags are anti-patterns — the exam mixes in security-sounding options that actually weaken the control plane.

Practice this question →
7
MCQmedium

An attacker gains execution in a container and attempts to perform a denial of service attack on other workloads sharing the same Kubernetes node by consuming all available CPU and memory resources. What Kubernetes feature prevents this cross-workload resource exhaustion?

A.ValidatingWebhookConfiguration rejecting pod creations
B.NetworkPolicy egress blocking rules
C.Container Resource Requests and Limits (CPU and memory)
D.ClusterRoleBindings restricting RBAC permissions
AnswerC

CPU and memory requests and limits constrain each container's consumption, so a compromised container cannot exhaust the node's shared resources. Requests guarantee scheduling reservations, while limits cap usage and trigger throttling or OOM termination, directly preventing the cross-workload denial of service described in the stem.

Why this answer

Container Resource Requests and Limits (CPU and memory) allow you to specify the minimum resources a container needs (requests) and the maximum it can consume (limits). By setting limits, you prevent a single container from monopolizing node resources, thus protecting other workloads from resource exhaustion and denial of service.

Exam trap

The trap is confusing admission control or network policies with runtime resource enforcement; candidates might think webhooks or RBAC can prevent resource exhaustion, but only resource limits directly constrain CPU/memory usage.

How to eliminate wrong answers

Option A is wrong because ValidatingWebhookConfiguration is for admission control, not runtime resource enforcement; it cannot prevent a running container from consuming resources. Option B is wrong because NetworkPolicy egress rules control network traffic, not CPU/memory consumption. Option D is wrong because ClusterRoleBindings manage RBAC permissions (who can do what in the API), not resource usage.

Practice this question →
8
MCQeasy

Which attack vector involves tricking a Kubernetes cluster user or service into executing unintended actions via authenticated sessions, frequently mitigated by robust CSRF defenses and proper API design?

A.Cross-Site Request Forgery (CSRF)
B.Denial of Service via memory leaks
C.Container escape via kernel flaw
D.Image tag mutation
AnswerA

CSRF exploits a victim's authenticated session by luring them into submitting forged requests, causing unintended cluster actions. Robust CSRF tokens and sound API design mitigate it, matching the stem's description of tricking users or services through authenticated sessions.

Why this answer

Cross-Site Request Forgery (CSRF) tricks an authenticated user's browser or session into sending unintended requests to a trusted application — for example, a malicious page causing a logged-in Kubernetes dashboard user to issue API calls. Mitigations include CSRF tokens, SameSite cookies, and requiring re-authentication for sensitive operations, which is exactly what the question describes.

Exam trap

KCSA often tests whether candidates can distinguish session-abuse attacks (CSRF) from supply-chain (image tag mutation), isolation-break (container escape), and availability (DoS) attacks, luring them toward the more 'Kubernetes-sounding' options.

How to eliminate wrong answers

Option B is wrong because DoS via memory leaks exhausts resources to cause unavailability — it does not involve tricking an authenticated session into performing unintended actions. Option C is wrong because container escape via kernel flaw exploits a vulnerability in the kernel or runtime to break isolation, not to abuse a user's authenticated session. Option D is wrong because image tag mutation involves overwriting a mutable tag (e.g., :latest) in a registry to deliver malicious code — a supply-chain attack, not a session-abuse attack.

Practice this question →
9
MCQhard

In a zero-trust Kubernetes architecture, an attacker attempts to exploit the Kubernetes API server via a Server-Side Request Forgery (SSRF) flaw in a poorly written custom controller. Which defense-in-depth mechanism specifically protects against unauthorized API requests originating from inside the cluster network?

A.Configuring Horizontal Pod Autoscalers to limit request rates
B.Enabling Pod Security Standards in baseline mode across all namespaces
C.Mandatory client certificate authentication and rigorous RBAC authorization on API endpoints
D.Disabling the Kubelet read-only port on all worker nodes
AnswerC

Client certificate authentication forces every caller to prove identity cryptographically, and RBAC then authorises each verb on each resource. An SSRF flaw in a controller cannot forge a valid certificate, so requests from inside the cluster network are rejected before reaching API logic.

Why this answer

Client certificate authentication combined with strict RBAC ensures that every request to the API server is cryptographically tied to an authenticated identity and authorized against explicit policy, so an SSRF from a compromised controller cannot impersonate another principal or escalate privileges. Even if the attacker crafts requests from inside the cluster network, the API server rejects them without valid credentials and matching RBAC bindings. This is the core zero-trust 'never trust, always verify' control at the API boundary.

Exam trap

KCSA often tests the confusion between pod-level hardening controls (Pod Security Standards, disabling kubelet ports) and identity-based API server controls (mTLS + RBAC), tricking candidates into picking a pod-hardening option when the question is really about authenticating API requests.

How to eliminate wrong answers

Option A is wrong because Horizontal Pod Autoscalers only adjust replica counts based on CPU/memory metrics — they provide no authentication or authorization and do nothing to stop unauthorized API calls. Option B is wrong because Pod Security Standards baseline mode restricts pod-level privileges (host namespaces, privileged containers) but does not authenticate or authorize API server requests, so an SSRF payload still reaches the API server. Option D is wrong because disabling the Kubelet read-only port (10255) closes an information-disclosure vector on nodes but has no bearing on API server authentication or SSRF-originated requests.

Practice this question →
10
MCQeasy

An administrator needs to analyze the STRIDE threat model category that encompasses an attacker gaining unauthorized elevation of privilege inside a Kubernetes cluster by exploiting a misconfigured RBAC ClusterRoleBinding. Which threat category does this represent?

A.Tampering
B.Elevation of Privilege
C.Repudiation
D.Information Disclosure
AnswerB

Elevation of Privilege covers an attacker gaining higher access than authorised. A misconfigured ClusterRoleBinding grants cluster-wide permissions, letting a subject escalate beyond intended rights — precisely the unauthorised privilege gain the stem describes. This directly satisfies the STRIDE category for RBAC misconfiguration abuse within Kubernetes.

Why this answer

Elevation of Privilege in STRIDE covers any attack where an adversary gains capabilities or access rights beyond what they were legitimately granted. Exploiting a misconfigured RBAC ClusterRoleBinding — for example, binding a powerful role like cluster-admin to a service account or user that should not have it — lets an attacker escalate from limited permissions to cluster-wide control. This is the defining characteristic of the Elevation of Privilege category, not data modification or confidentiality loss.

Exam trap

KCSA often tests whether candidates confuse Elevation of Privilege with Tampering or Information Disclosure when the root cause is an access-control misconfiguration rather than data modification or exposure.

How to eliminate wrong answers

Option A (Tampering) is wrong because Tampering concerns unauthorized modification of data or code in transit or at rest, not the acquisition of higher permissions. Option C (Repudiation) is wrong because Repudiation involves denying having performed an action and relates to logging, audit trails, and non-repudiation controls, not privilege escalation. Option D (Information Disclosure) is wrong because Information Disclosure covers exposure of confidential data to unauthorized parties, whereas here the attacker gains control capabilities rather than merely reading data.

Practice this question →
11
Multi-Selectmedium

When modeling threats related to Kubernetes secrets management, which TWO actions help protect secrets from unauthorized access?

Select 2 answers
A.Granting all namespace users cluster-admin read permissions on Secret objects
B.Integrating external secret management systems (e.g., HashiCorp Vault, AWS Secrets Manager)
C.Disabling RBAC authentication across all API server endpoints
D.Enabling etcd encryption at rest using a dedicated encryption provider configuration
E.Storing database credentials in plain text ConfigMaps in the default namespace
AnswersB, D

External secret managers keep sensitive values outside etcd and the cluster's native Secret objects, so a compromised pod or API access cannot read them directly. This satisfies the stem by removing secrets from the cluster's default trust boundary.

Why this answer

Option B is correct because integrating external secret management systems such as HashiCorp Vault or AWS Secrets Manager removes secrets from Kubernetes' native etcd storage and centralizes access control, auditing, and rotation in a hardened secrets store, reducing the blast radius of unauthorized access to Kubernetes Secrets. Option D is correct because enabling etcd encryption at rest via an EncryptionConfiguration with a dedicated provider (e.g., aescbc or KMS) ensures that Secret data written to etcd is encrypted, so an attacker who gains access to the etcd data files or backups cannot read plaintext secret values. Option A is wrong because granting all namespace users cluster-admin read permissions on Secrets massively expands the attack surface and violates least privilege.

Option C is wrong because disabling RBAC authentication on API server endpoints removes authorization controls entirely, allowing any authenticated or anonymous caller to access resources. Option E is wrong because storing credentials in plaintext ConfigMaps in the default namespace exposes them to any user or workload with read access and provides no encryption or access restriction.

Exam trap

The trap is selecting options that seem to simplify access (like granting broad permissions) or ignoring the need for encryption. The exam tests whether you understand that secrets management requires both external integration and encryption at rest.

Practice this question →
12
MCQhard

A security engineer is assessing the threat model of a Kubernetes cluster where the kubelet is configured with the flag --anonymous-auth=true. An attacker has network access to the node's kubelet port (10250). What is the most significant risk introduced by this configuration?

A.The attacker can modify the node's iptables rules to redirect traffic by sending unauthenticated requests to the kubelet's /proxy endpoint.
B.The attacker can list all pods on the node and read their environment variables and logs via the kubelet's read-only endpoints without authentication.
C.The attacker can execute arbitrary commands in any pod on the node via the kubelet's /exec endpoint without authentication.
D.The attacker can retrieve the kubelet's configuration, including the cluster's certificate authority private key, from the /configz endpoint.
AnswerB

With --anonymous-auth=true, unauthenticated requests to the kubelet's read-only endpoints (e.g., /pods, /logs, /metrics) are allowed if the anonymous user is authorized. By default, the kubelet authorizes anonymous requests as system:anonymous, which often has read access to these endpoints. This can expose pod specifications, environment variables (including secrets), and logs, leading to sensitive data disclosure and further compromise.

Why this answer

Enabling anonymous authentication on the kubelet exposes read-only endpoints to unauthenticated users. Attackers with network access can query /pods, /logs, and /metrics to gather sensitive information such as environment variables, which may contain secrets. This information disclosure can facilitate further attacks, making it a critical misconfiguration in the Kubernetes threat model.

Exam trap

The trap here is focusing on high-impact actions like command execution, while the immediate and more likely risk of anonymous auth is information disclosure via read-only endpoints.

Practice this question →
13
MCQmedium

A security engineer is analyzing supply chain risks for container images. An unsigned image from an untrusted public registry is pulled into a secure cluster. Which Admission Controller plugin can be leveraged to prevent the deployment of unsigned container images?

A.NamespaceLifecycle admission plugin
B.ValidatingAdmissionWebhook executing a policy engine integrated with Cosign image signature verification
C.DefaultStorageClass admission controller
D.LimitRanger
AnswerB

A ValidatingAdmissionWebhook calls an external policy engine that verifies Cosign signatures against trusted keys, rejecting any image lacking a valid signature. This enforces the stem's requirement to block unsigned images from untrusted registries before pods are admitted to the cluster.

Why this answer

The ValidatingAdmissionWebhook admission plugin allows external policy engines (e.g., OPA Gatekeeper, Kyverno) to intercept API server requests and enforce custom validation logic. When integrated with Cosign, the webhook can verify image signatures against trusted public keys before allowing a Pod to be created. This is the standard Kubernetes-native mechanism for enforcing image signature verification at admission time, directly preventing unsigned images from being deployed.

Exam trap

KCSA often tests the misconception that built-in admission controllers like NamespaceLifecycle or LimitRanger can enforce image security policies, when in fact only dynamic webhooks with external policy engines can perform signature verification.

How to eliminate wrong answers

Option A is wrong because NamespaceLifecycle only enforces that objects are not created in namespaces that are terminating or non-existent; it has no capability to inspect image signatures. Option C is wrong because DefaultStorageClass merely assigns a default StorageClass to PersistentVolumeClaims that do not specify one; it is unrelated to container image security. Option D is wrong because LimitRanger enforces resource limits (CPU, memory) and default requests on Pods and Containers, not image provenance or signature validation.

Practice this question →
14
Multi-Selecthard

Which THREE of the following steps are recognized best practices for hardening worker nodes against attacks and container escapes?

Select 3 answers
A.Keeping node host operating system kernels and container runtimes regularly patched
B.Configuring all pods to execute with `securityContext.runAsUser: 0`
C.Disabling the Kubelet read-only port (10255)
D.Allowing anonymous authentication requests on the Kubelet API
E.Restricting direct SSH access to worker nodes and using secure bastion hosts
AnswersA, C, E

Regular patching of host kernels and container runtimes directly closes the privilege-escalation vulnerabilities that container escapes exploit, satisfying the stem's hardening requirement. Because containers share the node kernel, an unpatched runtime or kernel flaw lets an attacker break isolation and reach the host, so timely updates are a recognised best practice.

Why this answer

Option A is correct because regularly patching node host OS kernels and container runtimes closes known privilege-escalation and container-escape vulnerabilities (e.g., runc CVEs) that attackers exploit to break out of containers. Option C is correct because the Kubelet read-only port 10255 serves unauthenticated pod and node metadata; disabling it (or ensuring it is not enabled, since it is deprecated/removed in newer Kubernetes) prevents unauthenticated information disclosure and reconnaissance. Option E is correct because restricting direct SSH access to worker nodes and requiring hardened bastion hosts reduces the attack surface and enforces auditable, controlled administrative access to nodes.

Option B is wrong because running pods as UID 0 (root) violates least privilege and increases the impact of a container escape. Option D is wrong because allowing anonymous authentication on the Kubelet API exposes node and pod operations to unauthenticated users and should be disabled via --anonymous-auth=false.

Exam trap

KCSA often tests whether candidates confuse 'running as root' with administrative necessity — the trap is picking `runAsUser: 0` as a hardening step when it is actually a critical misconfiguration, and forgetting that the read-only Kubelet port 10255 is unauthenticated by design.

Practice this question →
15
MCQeasy

An organization wants to analyze potential threats to their Kubernetes cluster using the STRIDE model. Which STRIDE category maps to an attacker eavesdropping on unencrypted internal cluster traffic between pods?

A.Repudiation
B.Tampering
C.Information Disclosure
D.Denial of Service
AnswerC

Information Disclosure covers data exposure to unauthorised parties, matching the eavesdropping scenario precisely. Unencrypted pod-to-pod traffic lets an attacker on the network read payloads in transit, violating confidentiality. STRIDE assigns confidentiality breaches to Information Disclosure, so it satisfies the stem's requirement of mapping the eavesdropping threat correctly.

Why this answer

Information Disclosure in the STRIDE model covers threats where data is exposed to unauthorized parties, such as eavesdropping on unencrypted traffic. An attacker sniffing internal cluster traffic between pods to read sensitive data is a classic Information Disclosure threat. The other STRIDE categories address different threat types, such as tampering with data or denying service.

Exam trap

KCSA often tests STRIDE categories, and candidates may confuse Information Disclosure with Tampering or Repudiation; the key is that eavesdropping is a confidentiality breach, which maps to Information Disclosure.

How to eliminate wrong answers

Option A is wrong because Repudiation involves denying having performed an action, such as an attacker covering their tracks, not eavesdropping. Option B is wrong because Tampering involves unauthorized modification of data or systems, not passive interception. Option D is wrong because Denial of Service involves making a service unavailable, not reading traffic.

Practice this question →
16
MCQhard

An attacker gains execution inside a container that has the `CAP_SYS_ADMIN` capability enabled and shares the host's IPC namespace. How does `CAP_SYS_ADMIN` facilitate container escape?

A.By encrypting all network traffic traversing the CNI plugin bridge
B.By permitting system administration operations like mounting host filesystems and manipulating cgroups
C.By enabling automated horizontal scaling of replica sets
D.By automatically granting cluster-admin Kubernetes RBAC permissions
AnswerB

CAP_SYS_ADMIN grants broad privileged operations, including mounting filesystems and manipulating cgroups. With host IPC shared, an attacker can abuse these to mount the host root filesystem or alter cgroup settings, breaking container isolation and escaping to the host.

Why this answer

CAP_SYS_ADMIN is a powerful Linux capability that grants a broad range of system administration operations, including mounting filesystems, manipulating cgroups, and performing namespace operations. In a container, if this capability is enabled and the container shares the host's IPC namespace, an attacker can mount the host's filesystem (e.g., /dev/sda1) or use cgroup release_agent to execute commands on the host, achieving container escape.

Exam trap

KCSA often tests the misconception that CAP_SYS_ADMIN is a benign or networking-related capability, when in fact it is one of the most dangerous capabilities enabling container escape via mount and cgroup manipulation.

How to eliminate wrong answers

Option A is wrong because CAP_SYS_ADMIN does not encrypt network traffic; encryption is handled by TLS/IPsec and is unrelated to capabilities. Option C is wrong because horizontal scaling is a Kubernetes control-plane function (HPA) and has no relation to Linux capabilities. Option D is wrong because CAP_SYS_ADMIN does not grant Kubernetes RBAC permissions; RBAC is enforced by the API server and is separate from Linux capabilities inside the container.

Practice this question →
17
MCQeasy

Which Kubernetes feature allows administrators to define mandatory security baselines, such as disallowing privileged containers, across an entire namespace or cluster?

A.Horizontal Pod Autoscaler
B.PersistentVolume security controller
C.kube-dns policy mapper
D.Pod Security Admission
AnswerD

Pod Security Admission enforces mandatory Pod Security Standards at namespace level via labels, restricting privileged containers and other risky settings cluster-wide. It satisfies the requirement to define baseline security policies across an entire namespace or cluster without per-workload configuration, unlike discretionary controls such as SecurityContext or admission webhooks requiring custom policy code.

Why this answer

Pod Security Admission (PSA) is a built-in Kubernetes admission controller that enforces Pod Security Standards (PSS) at the namespace level. It allows administrators to define mandatory security baselines—such as disallowing privileged containers, hostPath volumes, or host networking—by labeling namespaces with pod-security.kubernetes.io/enforce, audit, or warn modes. PSA replaced the deprecated PodSecurityPolicy and is enabled by default in Kubernetes v1.23+, making it the correct feature for cluster-wide or namespace-scoped security baselines.

Exam trap

KCSA often tests the confusion between Pod Security Admission and the deprecated PodSecurityPolicy (PSP), or between security enforcement and other cluster add-ons like network policies or RBAC, causing candidates to overlook that PSA is the built-in namespace-level baseline enforcer.

How to eliminate wrong answers

Option A is wrong because Horizontal Pod Autoscaler adjusts the number of pod replicas based on CPU/memory or custom metrics; it has no security enforcement role. Option B is wrong because there is no 'PersistentVolume security controller' in Kubernetes—PersistentVolumes are storage abstractions managed by the PV controller, which handles binding and reclaiming, not security baselines. Option C is wrong because kube-dns (CoreDNS) is the cluster DNS add-on responsible for service discovery and name resolution; it has no policy mapping or security enforcement capability.

Practice this question →
18
Multi-Selecthard

Which THREE of the following configurations or features represent critical attack vectors or misconfigurations in a Kubernetes cluster threat model?

Select 3 answers
A.Mounting the host Docker socket (`/var/run/docker.sock`) into application pods
B.Exposing the unauthenticated Kubelet read-only port (10255)
C.Enabling Pod Security Admission in restricted mode across all namespaces
D.Running application pods with `securityContext.privileged: true`
E.Configuring etcd encryption at rest with a Secret encryption provider
AnswersA, B, D

Mounting the host Docker socket gives a pod control over the container runtime, enabling container creation with host mounts or privileged access, effectively escaping to the node. This represents a critical attack vector in the cluster threat model.

Why this answer

Option A is correct because mounting /var/run/docker.sock into a pod gives the container direct control over the host's Docker daemon, allowing an attacker to create privileged containers, mount host filesystems, or escape to the node. Option B is correct because the Kubelet read-only port 10255 serves unauthenticated and unencrypted API data, exposing pod specs, environment variables, and cluster details to anyone who can reach the node. Option D is correct because securityContext.privileged: true disables container isolation, granting all Linux capabilities and host device access, which makes node compromise and container escape trivial.

Option C is not a vector because Pod Security Admission in restricted mode is a hardening control that enforces least-privilege pod settings. Option E is not a vector because etcd encryption at rest with a Secret encryption provider protects sensitive data in etcd rather than exposing it.

Exam trap

KCSA often tests the ability to distinguish hardening controls (Pod Security Admission, etcd encryption) from attack vectors (host socket mounts, exposed Kubelet ports, privileged pods) — candidates must read whether the question asks for risks or mitigations.

Practice this question →
19
MCQeasy

A developer configures a Kubernetes Pod with `hostNetwork: true`. Under the STRIDE threat model, which threat category is most directly introduced or elevated by this configuration?

A.Denial of Service via CPU exhaustion
B.Tampering of container image layers at rest
C.Elevation of Privilege and Information Disclosure
D.Repudiation of database audit logs
AnswerC

Sharing the host network namespace removes isolation, letting the Pod sniff node traffic and reach loopback-bound services, which is Information Disclosure. Combined with root or privileged capabilities, it also permits spoofing and bypassing network policy, elevating privilege on the node.

Why this answer

Setting hostNetwork: true places the Pod directly in the host's network namespace, so it shares the node's IP, routing table, and can bind to any host port — including privileged ports and ports used by node services. This directly elevates privilege (the Pod can sniff or interfere with node-level traffic and reach services bound to localhost) and discloses information (it can observe host network traffic and access node-local endpoints). Under STRIDE, these map to Elevation of Privilege and Information Disclosure.

Exam trap

The trap is that candidates pick a generic DoS or image-integrity answer because they associate 'host' with resource or storage risk, missing that hostNetwork's core STRIDE impact is privilege elevation plus information disclosure via the shared node network namespace.

How to eliminate wrong answers

Option A is wrong because CPU exhaustion is a resource-exhaustion/DoS concern addressed by resource requests and limits, not specifically introduced by hostNetwork — hostNetwork does not grant CPU priority. Option B is wrong because tampering with container image layers at rest is a registry/storage integrity concern (e.g., image signing, admission control), unrelated to network namespace sharing. Option D is wrong because repudiation of database audit logs concerns logging and non-repudiation controls, not network namespace configuration.

Practice this question →
20
MCQeasy

An auditor is evaluating the Kubernetes control plane attack surface. Which component exposes the primary interface for cluster management and must be protected with strong authentication and authorization?

A.CoreDNS
B.kube-proxy
C.kube-scheduler
D.kube-apiserver
AnswerD

The kube-apiserver is the sole entry point for control plane operations, serving the REST API that kubectl, controllers and nodes use. Every management request passes through it, so strong authentication and authorisation there protects the entire cluster.

Why this answer

The kube-apiserver is the central management interface for a Kubernetes cluster, exposing the REST API that all other components (kubectl, controllers, kubelets, schedulers) use to read and write cluster state. Because it is the single entry point for all control plane operations, it must be protected with strong authentication (client certs, OIDC, webhook tokens) and authorization (RBAC, ABAC, Node authorizer). Compromise of the API server effectively means full cluster compromise, making it the most critical attack surface to harden.

Exam trap

The trap is assuming any control plane component (scheduler, controller-manager) exposes the management API — only kube-apiserver does, and it is the component that must be hardened with authentication and RBAC.

How to eliminate wrong answers

Option A is wrong because CoreDNS is a cluster add-on that provides DNS resolution for services and pods; it does not expose a management API and is not the primary control plane interface. Option B is wrong because kube-proxy runs on each node to implement Service networking (iptables/IPVS rules) and does not expose a cluster management API. Option C is wrong because kube-scheduler is a control plane component that assigns pods to nodes based on resource and affinity rules, but it does not expose the primary management interface — it only watches the API server for unscheduled pods.

Practice this question →
21
MCQhard

An auditor is evaluating the security posture of an on-premises Kubernetes cluster. The team notices that the etcd data directory is stored without encryption at rest. What is the primary threat this exposes the cluster to?

A.Direct exposure of all Kubernetes Secrets in plain text to anyone with read access to etcd storage
B.Inability of worker nodes to perform TLS handshakes with the API server
C.Immediate failure of HorizontalPodAutoscaler metric polling loops
D.Automatic elevation of all ServiceAccounts to cluster-admin privileges
AnswerA

etcd stores Secrets unencrypted by default, so anyone with read access to its data directory or backups can read every Secret in plain text. This directly exposes credentials and tokens cluster-wide, which is the primary threat of missing encryption at rest.

Why this answer

Without encryption at rest, etcd stores all Kubernetes objects—including Secrets—in plaintext on disk. Anyone with read access to the etcd data directory (e.g., via filesystem access, stolen disk, or backup) can directly read sensitive data like service account tokens, database passwords, and TLS keys. This is the primary threat because etcd is the single source of truth for cluster state, and encryption at rest is a defense-in-depth measure specifically designed to protect this data if the storage medium is compromised.

Exam trap

KCSA often tests the misconception that etcd encryption at rest is about network security or performance, when it is actually about protecting data confidentiality on disk; candidates may confuse it with TLS or RBAC.

How to eliminate wrong answers

Option B is wrong because worker node TLS handshakes with the API server rely on certificates and network encryption, not on etcd encryption at rest; etcd encryption does not affect TLS negotiation. Option C is wrong because HorizontalPodAutoscaler metric polling depends on the metrics API and controller manager, not on etcd encryption; lack of encryption does not cause immediate failure of HPA loops. Option D is wrong because ServiceAccount privileges are determined by RBAC and admission controllers, not by etcd encryption; encryption at rest does not automatically elevate permissions.

Practice this question →
22
MCQeasy

What is the primary risk associated with running containers as the `root` user (`runAsUser: 0` or omitting the user directive)?

A.If a container escape vulnerability occurs, the attacker immediately obtains root privileges on the underlying host.
B.It prevents the kubelet from restarting the container upon failure.
C.It disables the container runtime engine's ability to pull images from private registries.
D.It forces the CNI plugin to drop network packets destined for external IPs.
AnswerA

Running as root means a container escape grants immediate host root privileges, because the container process's UID maps directly to host root unless user namespaces or a non-root runAsUser are configured. This satisfies the stem's constraint identifying the primary risk of runAsUser: 0.

Why this answer

Running a container as root (UID 0) means that if an attacker exploits a container escape vulnerability, they gain root privileges on the host node because the container process runs as root in the host's user namespace (unless user namespaces are enabled). This violates the principle of least privilege and significantly increases the blast radius of a compromise. The other options are unrelated to user ID configuration.

Exam trap

KCSA often tests the misconception that container isolation alone prevents host compromise, but running as root inside the container can lead to immediate host root access upon escape.

How to eliminate wrong answers

Option B is wrong because container restart behavior is controlled by the pod's restartPolicy and the kubelet's lifecycle management, not by the user ID the container runs as. Option C is wrong because pulling images from private registries depends on imagePullSecrets and registry authentication, not on the container's runAsUser setting. Option D is wrong because CNI plugins handle network traffic based on network policies and routing rules, not on the user ID inside the container.

Practice this question →
23
MCQmedium

An attacker who achieves remote code execution inside a misconfigured container discovers that the service account token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token has cluster-wide administrative permissions. Which Kubernetes security feature should be enabled on the ServiceAccount to mitigate the risk of token theft and misuse?

A.Disabling automatic token mounting (automountServiceAccountToken: false) and utilizing projected volumes with bound audiences
B.Configuring a default Deny-All NetworkPolicy for the kube-system namespace
C.Enabling the NodeRestriction admission plugin
D.EnablingAnonymousAuth on the kube-apiserver
AnswerA

Disabling automatic token mounting stops Kubernetes injecting a credential into every pod, so a compromised container no longer finds a usable token at the default path. Projected volumes with bound audiences then issue short-lived, audience-restricted tokens, limiting what a stolen credential can access cluster-wide.

Why this answer

Disabling automountServiceAccountToken and using projected volumes with bound audiences limits the blast radius of token theft because the token is only issued when explicitly requested and is scoped to a specific audience and expiry. This prevents an attacker with RCE from finding a long-lived, cluster-admin token automatically mounted in the pod filesystem. Projected tokens are also time-bound and rotated, so stolen tokens expire quickly.

Exam trap

KCSA often tests the misconception that network policies or admission plugins can mitigate token theft, when the core issue is the automatic mounting and long-lived nature of ServiceAccount tokens.

How to eliminate wrong answers

Option B is wrong because a Deny-All NetworkPolicy in kube-system only restricts network traffic and does nothing to prevent token theft or misuse from within a pod. Option C is wrong because the NodeRestriction admission plugin limits what kubelets can modify about Node and Pod objects; it does not address ServiceAccount token mounting or permissions. Option D is wrong because enabling AnonymousAuth on the kube-apiserver allows unauthenticated requests, which worsens security rather than mitigating token theft.

Practice this question →
24
MCQeasy

Which of the following represents a common cloud-native supply chain attack vector where malicious actors publish packages with names similar to popular libraries?

A.Kernel memory exploitation via unprivileged user namespaces
B.Denial of Service via packet flooding
C.Man-in-the-Middle etcd keystore sniffing
D.Typosquatting
AnswerD

Typosquatting registers package names closely resembling legitimate popular libraries, hoping developers mistype and install the malicious lookalike. This impersonation of trusted names is the defining mechanism of the supply chain vector described, distinguishing it from dependency confusion or account compromise.

Why this answer

Typosquatting is a supply chain attack where adversaries publish malicious packages with names closely resembling legitimate, popular libraries (e.g., 'lodahs' instead of 'lodash'). Developers who mistype the package name during installation inadvertently pull in malicious code. This is a well-documented cloud-native supply chain threat affecting npm, PyPI, and container registries.

Exam trap

KCSA often tests whether candidates can distinguish supply chain attacks (typosquatting, dependency confusion) from runtime or network attacks, causing confusion when technically plausible but unrelated options are presented.

How to eliminate wrong answers

Option A (Kernel memory exploitation via unprivileged user namespaces) is wrong because it describes a kernel-level privilege escalation technique, not a package-name-based supply chain attack. Option B (Denial of Service via packet flooding) is wrong because it describes a network-layer volumetric attack, unrelated to package publishing. Option C (Man-in-the-Middle etcd keystore sniffing) is wrong because it describes interception of etcd traffic (a control plane attack), not a supply chain vector involving malicious package publication.

Practice this question →
25
MCQhard

An organization is building a secure software supply chain for Kubernetes. They want to ensure that containers running in the cluster were built from verified source code and passed automated security gates. Which tool combination supports this attestation and verification pipeline?

A.Cosign for cryptographic image signing, SBOM generation, and admission controllers for policy enforcement
B.HorizontalPodAutoscaler and Metrics Server integration
C.kube-proxy for CNI routing and CoreDNS for internal name resolution
D.etcd snapshots and kubeadm control plane bootstrapping scripts
AnswerA

Cosign produces verifiable signatures and attestations tied to the image digest, while admission controllers enforce that only signed, policy-compliant images are admitted. Together they satisfy the stem's requirement for verified source provenance and automated security gates.

Why this answer

Cosign provides cryptographic signing and verification of container images, and can attach SBOMs and attestations (e.g., SLSA provenance) to images in OCI registries. Admission controllers such as Kyverno, OPA Gatekeeper, or Sigstore's policy-controller then enforce at admission time that only images with valid signatures/attestations are admitted to the cluster. Together they form the attestation-and-verification pipeline the question describes.

Exam trap

KCSA often tests whether candidates confuse supply-chain security tooling (Cosign, SBOM, admission policy) with general cluster operations tooling (HPA, kube-proxy, etcd), so the trap is picking a familiar Kubernetes component that has nothing to do with image provenance.

How to eliminate wrong answers

Option B is wrong because HorizontalPodAutoscaler and Metrics Server are workload-scaling components — they have no role in image provenance, signing, or supply-chain attestation. Option C is wrong because kube-proxy handles Service VIP/iptables-IPVS routing and CoreDNS handles in-cluster DNS resolution; neither verifies image origin. Option D is wrong because etcd snapshots and kubeadm bootstrap scripts address control-plane backup and cluster provisioning, not container image attestation.

Practice this question →
26
MCQeasy

An auditor is reviewing the Kubernetes attack surface and notes that a container is running with privileged: true in its securityContext. Which threat model risk does this setting introduce?

A.It prevents the container from writing to ephemeral storage volumes.
B.It forces the kubelet to restart the container continuously due to failing readiness probes.
C.It completely disables the Kubernetes DNS resolution service for the pod.
D.It disables container isolation, granting the container root-equivalent access to the underlying host node.
AnswerD

privileged: true grants the container all Linux capabilities and unrestricted device access, effectively removing namespace isolation. The container can then access host resources as root, satisfying the stem's concern about root-equivalent access to the underlying node.

Why this answer

Setting privileged: true in a container's securityContext disables the container's isolation from the host by granting it all Linux capabilities and access to host devices. This effectively gives the container root-equivalent control over the underlying node, allowing it to escape the container boundary, access host filesystems, and compromise the node and potentially the whole cluster.

Exam trap

KCSA often tests whether candidates understand that privileged: true removes container isolation and grants host-level access, rather than confusing it with unrelated behaviors like storage restrictions, probe failures, or DNS disruption.

How to eliminate wrong answers

Option A is wrong because privileged mode does not restrict ephemeral storage writes; if anything, it broadens access to host resources. Option B is wrong because privileged mode has no relationship to readiness probes or kubelet restart behavior — those are governed by probe configuration and restartPolicy. Option C is wrong because privileged mode does not disable DNS resolution; CoreDNS and pod DNS settings operate independently of the securityContext privileged flag.

Practice this question →
27
MCQhard

A security team is evaluating the attack surface of the Kubernetes control plane. They notice that the kubelet API port 10250 is accessible from the internal pod network without proper authorization checks if authentication defaults are misconfigured. What is the primary threat vector associated with an unauthenticated, accessible kubelet API?

A.Execution of arbitrary commands inside running containers via the kubelet exec and run endpoints
B.Direct modification of etcd key-value pairs stored on the master node
C.Bypassing container image vulnerability scanners running in the CI/CD pipeline
D.Forcing the API server to issue new root certificates via TLS bootstrapping
AnswerA

The kubelet's exec and run endpoints proxy directly to the container runtime, so unauthenticated access on port 10250 permits arbitrary command execution inside any pod on that node. This satisfies the stem's misconfigured authentication default, escalating a network-reachable control plane port into node-wide container compromise.

Why this answer

The kubelet exposes an HTTP API on port 10250 that includes endpoints such as /exec, /run, and /attach. If authentication is disabled (e.g., --anonymous-auth=true with no authorization), an attacker on the pod network can call these endpoints directly to execute arbitrary commands inside any container running on that node. This bypasses the API server entirely and grants code execution with the container's privileges, often leading to node compromise.

Exam trap

KCSA often tests the misconception that the kubelet API is only for node management and cannot execute commands, leading candidates to overlook the exec/run endpoints as the primary threat vector.

How to eliminate wrong answers

Option B is wrong because etcd listens on port 2379/2380 and is not exposed by the kubelet; direct etcd modification requires access to the etcd cluster, not the kubelet API. Option C is wrong because image vulnerability scanners run in CI/CD pipelines and are not part of the Kubernetes control plane or kubelet API attack surface. Option D is wrong because TLS bootstrapping is a kubelet-to-API-server process for issuing client certificates, not a function of the kubelet API, and the API server does not issue root certificates via kubelet endpoints.

Practice this question →
28
MCQhard

An attacker with read access to Kubernetes Secrets inspects a secret containing TLS private keys. Under the STRIDE threat model, what specific threat category does this represent regarding confidentiality?

A.Denial of Service
B.Elevation of Privilege
C.Information Disclosure
D.Repudiation
AnswerC

Reading TLS private keys from a Secret exposes confidential data to an unauthorised party, which STRIDE classifies as Information Disclosure. The threat targets confidentiality directly, not integrity or availability, matching the stem's explicit confidentiality framing.

Why this answer

Information Disclosure is the STRIDE category that covers unauthorized access to confidential data, such as an attacker reading TLS private keys from a Kubernetes Secret. Since the attacker has read access to the secret, the confidentiality of the private keys is compromised, which is precisely Information Disclosure. This threat directly maps to the confidentiality pillar of security.

Exam trap

The trap is confusing Information Disclosure with Elevation of Privilege; candidates may think reading secrets is privilege escalation, but it is only escalation if the attacker uses the secret to gain higher permissions, whereas the act of reading is Information Disclosure.

How to eliminate wrong answers

Option A is wrong because Denial of Service involves disrupting availability, not reading secrets. Option B is wrong because Elevation of Privilege involves gaining higher permissions, not merely reading data the attacker already has access to. Option D is wrong because Repudiation involves denying actions, not data exposure.

Practice this question →
29
MCQmedium

An attacker compromises a cluster node and attempts to inspect container communication. By default, how is pod-to-pod network traffic handled across different nodes in a standard Kubernetes cluster without a service mesh or CNI encryption enabled?

A.Encrypted automatically using mandatory 256-bit AES transport layer security
B.Blocked entirely by default unless a LoadBalancer service is declared
C.Routed exclusively through the etcd secure TLS database tunnel
D.Transmitted in plain text across the network fabric, making it vulnerable to sniffing
AnswerD

Plain text transmission occurs because Kubernetes delegates pod networking to the CNI plugin, and without encryption enabled, packets traverse the network fabric unencrypted. The compromised node can therefore sniff inter-node pod traffic directly, satisfying the stem's constraint of no service mesh or CNI encryption.

Why this answer

In a standard Kubernetes cluster, pod-to-pod traffic across nodes is not encrypted by default. The CNI plugin (e.g., Calico, Flannel, Cilium) is responsible for routing packets between nodes, but unless a feature like WireGuard, IPsec, or a service mesh (e.g., Istio with mTLS) is explicitly enabled, the packets are sent in plain text over the network fabric. This means an attacker who has compromised a node and can sniff network traffic can potentially capture sensitive data exchanged between pods.

Exam trap

KCSA often tests the misconception that Kubernetes encrypts pod-to-pod traffic by default, confusing the secure control plane (etcd, API server) with the data plane, or assuming that CNI plugins provide encryption out of the box.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not automatically encrypt pod-to-pod traffic with AES; encryption requires explicit configuration of a CNI with encryption or a service mesh. Option B is wrong because pod-to-pod communication is allowed by default; NetworkPolicies can restrict it, but they are not enabled by default, and LoadBalancer services are for external access, not for enabling internal pod traffic. Option C is wrong because etcd is the cluster's key-value store and is not involved in pod-to-pod data plane traffic; etcd communication is secured with TLS, but that is separate from pod networking.

Practice this question →
30
MCQmedium

A security engineer discovers that an attacker has gained access to a container and is attempting to modify container files in a way that persists across pod restarts if the container image is faulty. However, the root filesystem is marked as readOnlyRootFilesystem: true. What is the impact of this setting on the attack?

A.It enforces TLS encryption for all outbound pod network connections.
B.It mitigates threats by preventing attackers from writing malicious binaries or modifying system files in the root filesystem.
C.It automatically encrypts all environment variables stored in the Pod spec.
D.It completely prevents any container from starting up if PersistentVolumeClaims are attached.
AnswerB

Setting `readOnlyRootFilesystem: true` mounts the container's root filesystem as a read-only layer, so any write attempt by the attacker fails with a filesystem error. This directly satisfies the stem's constraint: malicious binaries or modified system files cannot be written, blocking persistence across pod restarts.

Why this answer

Setting readOnlyRootFilesystem: true mounts the container's root filesystem as read-only, which prevents an attacker from writing malicious binaries or modifying system files in the root filesystem. This directly mitigates the threat of persistent modifications to the container image or filesystem. The setting does not affect network encryption, environment variables, or PVC attachment.

Exam trap

The trap is assuming readOnlyRootFilesystem prevents all writes; candidates may forget that writable volumes can still be mounted, or confuse it with unrelated controls like TLS encryption or environment variable protection.

How to eliminate wrong answers

Option A is wrong because readOnlyRootFilesystem has no effect on TLS encryption for outbound connections; TLS is configured at the application or service mesh level. Option C is wrong because environment variables are not encrypted by this setting; they are stored in the Pod spec and can be exposed via the API. Option D is wrong because readOnlyRootFilesystem does not prevent container startup with PVCs; PVCs are mounted as separate volumes and can be writable even if the root filesystem is read-only.

Practice this question →
31
Multi-Selecthard

Which THREE of the following capabilities or runtime configurations pose extreme risks of container escape when granted to an untrusted workload?

Select 3 answers
A.`hostPID: true` sharing the host process namespace
B.Setting `automountServiceAccountToken: false` on the service account
C.`securityContext.privileged: true`
D.Granting the `CAP_SYS_ADMIN` capability in the container security context
E.Setting `readOnlyRootFilesystem: true` in the container specification
AnswersA, C, D

Sharing the host PID namespace lets the container see and signal host processes, enabling escape via tools like nsenter into host namespaces. It directly satisfies the extreme-risk container escape criterion by removing process isolation between workload and node.

Why this answer

Option A (`hostPID: true`) is correct because sharing the host PID namespace lets the container see and signal host processes, enabling attacks such as ptrace-based injection into host daemons or killing host security agents, which is a classic container-escape vector. Option C (`securityContext.privileged: true`) is correct because a privileged container disables most isolation: it gets all Linux capabilities, access to all host devices, and relaxed seccomp/AppArmor confinement, so it can mount the host filesystem or load kernel modules to break out. Option D (granting `CAP_SYS_ADMIN`) is correct because this capability permits mount operations, namespace manipulation, and other kernel-level actions that allow escaping the container boundary even without full privileged mode.

Option B (`automountServiceAccountToken: false`) is not a risk — it reduces exposure by preventing the pod from receiving a Kubernetes API token. Option E (`readOnlyRootFilesystem: true`) is a hardening measure that makes the container's root filesystem immutable and does not enable escape.

Exam trap

KCSA often tests the misconception that any securityContext setting that sounds restrictive (like readOnlyRootFilesystem or automountServiceAccountToken: false) is risky, when in fact they are hardening measures; the real dangers are permissive settings like hostPID, privileged, and CAP_SYS_ADMIN.

Practice this question →
32
Multi-Selectmedium

A cluster administrator is conducting a threat analysis regarding supply chain vulnerabilities in container registries and deployment pipelines. Which TWO of the following practices directly mitigate supply chain threats in Kubernetes? (Choose TWO)

Select 2 answers
A.Increasing the CPU limits on all worker nodes to handle larger container images
B.Enforcing cryptographic image signing and verification using tools like Sigstore Cosign
C.Configuring static IP addresses for all worker nodes in the private subnet
D.Integrating automated vulnerability scanning into the CI/CD pipeline before pushing images to the registry
E.Disabling the default token automount on all namespaces globally
AnswersB, D

Cryptographic signing with Sigstore Cosign attaches verifiable signatures to container images, and admission controllers reject unsigned or tampered images. This enforces provenance and integrity at deploy time, directly blocking the registry and pipeline tampering that supply chain attacks exploit.

Why this answer

Option B is correct because enforcing cryptographic image signing and verification with tools like Sigstore Cosign ensures that only images signed by trusted publishers can be admitted and run in the cluster, directly preventing tampered or malicious images from entering the supply chain. Option D is correct because integrating automated vulnerability scanning into the CI/CD pipeline before images are pushed to the registry catches known CVEs and misconfigurations at build time, stopping vulnerable artifacts from ever reaching production. Option A is incorrect because CPU limits on worker nodes have no bearing on supply chain integrity; they only affect resource scheduling and performance.

Option C is incorrect because static IP addresses for worker nodes address network stability and routing, not the authenticity or integrity of container images. Option E is incorrect because disabling the default service account token automount reduces the blast radius of a compromised pod's API credentials, but it does not mitigate supply chain threats such as image tampering or vulnerable dependencies.

Exam trap

KCSA often tests the confusion between runtime hardening controls (like disabling token automount) and build-time supply chain controls — candidates pick runtime options thinking they mitigate supply chain risk.

Practice this question →
33
Multi-Selecteasy

When modeling threats for a Kubernetes cluster using the STRIDE methodology, identifying scenarios where an attacker intercepts unencrypted traffic between worker nodes or between a client and the API server addresses which TWO STRIDE categories? (Choose TWO)

Select 2 answers
A.Repudiation
B.Denial of Service
C.Tampering
D.Elevation of Privilege
E.Information Disclosure
AnswersC, E

Interception of unencrypted node-to-node or client-to-API-server traffic lets an attacker alter packets in transit, which is Tampering under STRIDE. The lack of transport encryption (no TLS) is the specific weakness enabling modification of data between endpoints.

Why this answer

Option C (Tampering) is correct because an attacker who intercepts unencrypted traffic between worker nodes or between a client and the API server can modify the data in transit, which directly violates integrity and matches STRIDE's Tampering category. Option E (Information Disclosure) is correct because intercepting unencrypted traffic exposes sensitive data such as credentials, tokens, or configuration details to unauthorized parties, which is exactly the confidentiality violation STRIDE classifies as Information Disclosure. Option A (Repudiation) does not apply because it concerns denying having performed an action and the lack of audit trails, not interception of traffic.

Option B (Denial of Service) does not apply because it concerns availability degradation or disruption, not passive interception or modification of communications. Option D (Elevation of Privilege) does not apply because it concerns gaining higher permissions than authorized, which is not the direct result of intercepting unencrypted traffic described here.

Exam trap

KCSA often tests the distinction between STRIDE categories by presenting scenarios that seem to fit multiple categories; candidates may overlook that interception enables both data exposure (Information Disclosure) and data modification (Tampering), or incorrectly attribute it to Repudiation or Elevation of Privilege.

Practice this question →
34
MCQhard

An administrator wishes to defend against supply chain attacks involving malicious third-party Kubernetes operators installed from public catalogs. What security practice is most effective before installing such operators?

A.Reviewing requested RBAC permissions, operator manifests, and verifying image provenance
B.Enabling Horizontal Pod Autoscaling for CoreDNS replicas
C.Disabling the Kubernetes Dashboard service deployment
D.Configuring liveness probes on all worker nodes to check kubelet responsiveness
AnswerA

Inspecting the operator's requested RBAC permissions, its manifests, and verifying image provenance and signatures exposes over-privileged requests or tampered images before installation, directly mitigating malicious third-party operators from public catalogs. This pre-installation review addresses the supply chain risk at its source.

Why this answer

Before installing third-party operators, the most effective practice is to review the requested RBAC permissions, inspect the operator manifests for suspicious resources, and verify image provenance (e.g., signatures, trusted registries). This due diligence helps detect malicious intent, such as excessive privileges or backdoors, before the operator is deployed.

Exam trap

KCSA often tests the confusion between operational best practices (like HPA or liveness probes) and security practices (like RBAC review and image provenance) for supply chain defense.

How to eliminate wrong answers

Option B is wrong because enabling Horizontal Pod Autoscaling for CoreDNS is unrelated to supply chain security and does not mitigate malicious operators. Option C is wrong because disabling the Kubernetes Dashboard, while a good hardening step, does not address the risk of third-party operators. Option D is wrong because configuring liveness probes on worker nodes is an operational health check, not a security control against supply chain attacks.

Practice this question →
35
Multi-Selectmedium

An auditor evaluates network security controls in a Kubernetes cluster. Which TWO configurations help mitigate lateral movement and network-based attacks between pods?

Select 2 answers
A.Disabling CNI network plugins to run pods in bridge mode
B.Implementing a service mesh (such as Istio or Linkerd) with strict mTLS enforcement
C.Exposing all internal microservices via NodePort services on worker nodes
D.Mounting the host network namespace (`hostNetwork: true`) on all application pods
E.Enforcing Kubernetes NetworkPolicies to restrict pod-to-pod ingress and egress traffic
AnswersB, E

A service mesh with strict mTLS authenticates and encrypts all pod-to-pod traffic via sidecar proxies, rejecting unauthenticated connections. This prevents a compromised pod from impersonating others or intercepting traffic, directly mitigating lateral movement and network-based attacks within the cluster.

Why this answer

Option B is correct because a service mesh such as Istio or Linkerd with strict mTLS enforcement authenticates and encrypts all service-to-service traffic, so a compromised pod cannot impersonate another workload or sniff plaintext traffic, directly limiting lateral movement. Option E is correct because Kubernetes NetworkPolicies implement pod-level, label-selector-based ingress and egress filtering enforced by the CNI, allowing only explicitly permitted pod-to-pod flows and blocking unauthorized east-west connections. Option A is wrong because disabling CNI plugins and using plain bridge mode removes policy enforcement and segmentation, increasing exposure rather than mitigating it.

Option C is wrong because NodePort services expose internal microservices on every worker node's IP and port range, widening the attack surface instead of containing it. Option D is wrong because hostNetwork: true places pods in the node's network namespace, letting them see node traffic and bypass pod network isolation, which enables rather than prevents lateral movement.

Exam trap

KCSA often tests the misconception that hostNetwork or NodePort improves connectivity/security, when in fact they expand the attack surface — the correct mitigations are NetworkPolicies and mTLS-enabled service meshes.

Practice this question →
36
MCQmedium

An auditor notices that a cluster allows users to create Pods that mount host paths (`hostPath`). Which threat does this pose to the underlying node integrity?

A.Arbitrary read/write access to the host filesystem, enabling node compromise
B.Automatic failure of Kubernetes liveness and readiness health probes
C.Inability of the CNI plugin to assign IP addresses to pods
D.Immediate corruption of the etcd distributed consensus state
AnswerA

A `hostPath` volume bind-mounts a directory from the node's filesystem directly into the Pod, bypassing container isolation. Without a read-only flag or restrictive `allowedHostPaths` policy, a workload can read or overwrite sensitive node files such as kubelet credentials or system binaries, escalating to full node compromise.

Why this answer

A hostPath volume mounts a directory or file from the node's filesystem directly into the pod, so a container with write access can modify critical node files such as /etc/cron.d, /var/lib/kubelet, or SSH keys, leading to full node compromise and potential cluster-wide lateral movement. This is why Pod Security Standards restricted mode and admission policies like OPA Gatekeeper or Kyverno commonly block hostPath usage.

Exam trap

KCSA often tests whether candidates understand that hostPath is a node-integrity risk, not a pod-scheduling or networking concern, luring them toward plausible-sounding but unrelated options about probes, CNI, or etcd.

How to eliminate wrong answers

Option B is wrong because liveness and readiness probes are HTTP/TCP/exec health checks managed by the kubelet — hostPath mounts have no relationship to probe execution or failure. Option C is wrong because CNI plugins assign pod IPs from the pod CIDR independent of volume mounts; hostPath does not interfere with IPAM. Option D is wrong because etcd stores cluster state and is accessed only by the API server — a hostPath mount inside a pod does not directly corrupt etcd's consensus or data.

Practice this question →
37
Multi-Selectmedium

In the context of Kubernetes API server security, which TWO mechanisms are used to authenticate incoming API requests?

Select 2 answers
A.Kubernetes NetworkPolicy egress CIDR blocks
B.PersistentVolume claim capacity metadata
C.X509 Client Certificates presented during TLS handshakes
D.Container image pull secrets stored in private registries
E.Bearer Tokens (including ServiceAccount JWT tokens)
AnswersC, E

The API server validates client certificates presented during the TLS handshake against its configured certificate authority, extracting the subject's common name or organisation as the authenticated username. This is a native authentication mechanism satisfying the stem's requirement.

Why this answer

Option C is correct because the Kubernetes API server supports X509 client certificate authentication, where the client presents a certificate during the mutual TLS handshake and the certificate's Common Name (CN) is used as the username and Organization (O) as group membership. Option E is correct because bearer tokens, including ServiceAccount JWT tokens mounted into pods, are passed in the Authorization: Bearer <token> header and validated by the API server via the TokenReview API or configured token authenticators. The other options do not belong: NetworkPolicy egress CIDR blocks (A) control pod-level network traffic, not API request authentication; PersistentVolume claim capacity metadata (B) is storage resource information; and container image pull secrets (D) are registry credentials used by kubelet to pull images, not API server authentication mechanisms.

Exam trap

KCSA often tests whether candidates can distinguish authentication (who you are) from authorization (what you can do) and from unrelated controls like NetworkPolicy or image pull secrets — the trap is picking any security-sounding option instead of the two real authenticators.

Practice this question →
38
MCQhard

An attacker with compromised Kubernetes credentials attempts to hide malicious activity by deleting Kubernetes audit logs on the worker node. Where should audit logs ideally be stored and managed in a securely hardened cluster to prevent tampering and ensure non-repudiation?

A.Written to the container image layer cache of the local container runtime
B.Stored inside unencrypted ConfigMaps within the default namespace
C.Saved locally in an ephemeral emptyDir volume inside the kube-system namespace
D.Forwarded to an external centralized SIEM or secure remote storage backend
AnswerD

Node-local audit logs are writable by anyone with node or credential access, so an attacker can delete them. Forwarding to an external SIEM or remote backend removes that write path, preserving tamper-evident records for non-repudiation.

Why this answer

Audit logs must be shipped off-node to an external, append-only or WORM-capable backend (SIEM, syslog server, object storage with immutability) so that a compromised node or cluster credential cannot delete or alter them. Kubernetes audit policy is configured on the API server via --audit-policy-file and --audit-log-path/--audit-webhook-config-file, and forwarding to a remote endpoint preserves non-repudiation because the attacker's blast radius no longer includes the log store. Centralized storage also enables correlation across nodes and clusters, which is essential for forensic reconstruction after an incident.

Exam trap

The trap here is assuming that any log location inside the cluster (ConfigMap, emptyDir, node filesystem) is 'secure' — KCSA tests whether you recognize that tamper resistance and non-repudiation require the log store to be outside the attacker's control boundary.

How to eliminate wrong answers

Option A is wrong because the container image layer cache is a read-only, content-addressed store managed by the runtime (containerd/CRI-O) and is not a log destination at all — audit events are never written there. Option B is wrong because ConfigMaps are etcd-backed Kubernetes objects that any principal with write access to the default namespace can modify or delete, and they are not designed for high-volume append-only log streams. Option C is wrong because an emptyDir volume is ephemeral and node-local — it is destroyed when the pod is removed and is fully accessible to anyone with node or pod access, so it offers zero tamper resistance.

Practice this question →
39
MCQmedium

An engineer is reviewing the threat model of a Kubernetes cluster exposed to the public internet via a LoadBalancer service. Which configuration flaw most commonly leads to unintended external exposure of administrative dashboards?

A.Configuring liveness probes with HTTP GET requests instead of TCP socket checks
B.Exposing management dashboards via LoadBalancer or NodePort services without authentication or IP whitelisting
C.Setting imagePullPolicy to IfNotPresent on production deployments
D.Using ClusterIP service types for internal database connectivity
AnswerB

Publishing dashboards through LoadBalancer or NodePort services without authentication or IP whitelisting exposes them to the internet, letting anyone reach administrative interfaces. This misconfiguration, not the service type alone, is the common cause of unintended external exposure.

Why this answer

The most common cause of unintended external exposure of administrative dashboards (Kubernetes Dashboard, kube-state-metrics, Prometheus, Argo CD, etc.) is exposing them via a LoadBalancer or NodePort Service without authentication or IP whitelisting. This publishes the dashboard to the public internet, and if it lacks strong auth or has default credentials, attackers can reach it directly — this is the pattern behind many real-world Kubernetes breaches. The fix is to use ClusterIP with an authenticating ingress, or restrict access via IP allowlists and strong auth.

Exam trap

KCSA often tests whether candidates can identify the most common misconfiguration leading to external exposure — the trap is picking subtle-sounding options (probe type, imagePullPolicy) instead of the obvious but correct answer: exposing dashboards via LoadBalancer/NodePort without auth or IP whitelisting.

How to eliminate wrong answers

Option A is wrong because liveness probe type (HTTP GET vs TCP socket) affects health checking behavior, not external exposure — probes are internal kubelet checks and do not open ports to the internet. Option C is wrong because imagePullPolicy: IfNotPresent affects whether kubelet pulls an image if it already exists locally; it is a supply-chain/consistency concern, not a cause of dashboard exposure. Option D is wrong because ClusterIP is the internal-only Service type — using it for databases is a security best practice, not a flaw, and it does not expose anything externally.

Practice this question →
40
MCQeasy

Which of the following is a key component of the Kubernetes threat model concerning the compromise of node kubelets via insecure configuration?

A.Leaving the Kubelet read-only port (10255) enabled and accessible
B.Enforcing Pod Security Admission in restricted mode
C.Using secure HTTPS client certificates for API server communication
D.Enabling RBAC authorization mode across the control plane
AnswerA

The unauthenticated read-only port 10255 exposes kubelet APIs without any authentication or authorisation, letting anyone query pod specs and node data. Leaving it enabled and reachable is the insecure configuration that enables kubelet compromise within the Kubernetes threat model.

Why this answer

The Kubelet read-only port 10255 exposes unauthenticated, unencrypted access to pod and node information (and in some configurations, more). Leaving it enabled and reachable is a well-known Kubernetes threat model item because an attacker on the network can query it to enumerate workloads, extract metadata, and potentially pivot. Hardening guidance (CIS Kubernetes Benchmark) explicitly requires disabling it via --read-only-port=0.

Exam trap

KCSA often tests whether candidates can identify insecure defaults versus security controls — the trap is picking a hardening measure (PSA, RBAC, client certs) as the 'threat' when the question asks for a vulnerability.

How to eliminate wrong answers

Option B is wrong because enforcing Pod Security Admission in restricted mode is a hardening control that reduces pod-level risk; it is not a threat vector related to kubelet compromise. Option C is wrong because using secure HTTPS client certificates for API server communication is a best practice that strengthens authentication; it is not a vulnerability. Option D is wrong because enabling RBAC authorization mode is a security control that restricts API access; it is not a kubelet misconfiguration.

Practice this question →
41
Multi-Selecthard

An attacker manages to compromise a low-privilege pod inside a Kubernetes cluster and attempts to escalate privileges or pivot to other cluster components. Which THREE of the following misconfigurations or weaknesses would significantly aid the attacker's lateral movement or privilege escalation? (Choose THREE)

Select 3 answers
A.Etcd is encrypted at rest using a customer-managed KMS encryption provider.
B.The cluster uses a properly configured PodSecurityStandard of Restricted across all namespaces.
C.The pod's ServiceAccount has a ClusterRoleBinding granting cluster-admin permissions.
D.The pod is configured with hostNetwork: true, allowing it to sniff traffic on the node's network interface.
E.The cloud provider's instance metadata service is accessible without IMDSv2 token restrictions from the pod network.
AnswersC, D, E

A ClusterRoleBinding to cluster-admin grants the ServiceAccount full control over every namespace and cluster-scoped resource. Any pod using that ServiceAccount inherits those permissions, so the compromised pod can immediately read secrets, create privileged workloads and pivot cluster-wide.

Why this answer

Option C is correct because a ClusterRoleBinding that binds the pod's ServiceAccount to the cluster-admin ClusterRole grants that pod full, unrestricted permissions across every namespace and resource in the cluster, so a compromised pod can immediately read secrets, create privileged workloads, and take over the control plane. Option D is correct because hostNetwork: true places the pod in the node's network namespace, letting the attacker sniff node-level traffic (including kubelet, API server, and other pods' unencrypted communications) and reach services bound to the node's interfaces, which materially aids lateral movement. Option E is correct because if the instance metadata service (169.254.169.254) is reachable without IMDSv2 session-token enforcement, a compromised pod can retrieve the node's IAM credentials and use them against the cloud API, pivoting from the cluster into the underlying cloud infrastructure.

Option A does not belong because KMS-backed etcd encryption at rest protects data on disk and does nothing to help an attacker already executing inside a pod. Option B does not belong because the Restricted Pod Security Standard blocks privileged settings such as hostNetwork and hostPath, so it actually hinders rather than aids escalation.

Exam trap

KCSA often tests the confusion between controls that harden the cluster (encryption, PSS) and misconfigurations that enable attacker movement (over-permissive RBAC, hostNetwork, open IMDS).

Practice this question →
42
MCQmedium

A security team discovers that an application container running as root has successfully mounted the host's Docker socket (`/var/run/docker.sock`). What is the primary attack vector enabled by this misconfiguration?

A.Bypassing Kubernetes NetworkPolicies across different worker nodes
B.Direct modification of the etcd database state via local unix socket tunneling
C.Container escape and full node takeover by orchestrating new sibling containers with host mounts
D.Automatic escalation of RBAC roles assigned to the API server
AnswerC

Mounting the Docker socket grants the container control over the host's Docker daemon, enabling creation of sibling containers with host filesystem mounts. This escapes the container boundary and achieves full node takeover, directly satisfying the stem's root-container-with-socket constraint.

Why this answer

Mounting the host's Docker socket into a container gives that container full control over the Docker daemon, which runs as root on the host. An attacker can use the Docker API to start a new privileged container with the host filesystem mounted (e.g., -v /:/host), then chroot into it to gain root on the node — a classic container escape. This is the primary attack vector: full node takeover, and potentially lateral movement to other nodes via the cluster network or credentials.

Exam trap

KCSA often tests container escape vectors by presenting a mounted Docker socket and expecting candidates to recognize node takeover, while distracting with plausible but incorrect options about NetworkPolicies, etcd, or RBAC escalation.

How to eliminate wrong answers

Option A is wrong because NetworkPolicies are enforced by CNI plugins at the network layer; Docker socket access does not bypass them — the attacker would still be subject to network policy for pod-to-pod traffic. Option B is wrong because etcd is not accessible via a local Unix socket from the Docker socket; etcd listens on its own ports (2379/2380) and requires client certs, and the Docker socket does not tunnel to etcd. Option D is wrong because RBAC roles are managed by the Kubernetes API server, not the Docker daemon; Docker socket access does not automatically escalate Kubernetes RBAC permissions.

Practice this question →
43
MCQeasy

What is the primary security benefit of using immutable container base distroless images?

A.They prevent the API server from restarting during control plane upgrades.
B.They automatically encrypt persistent storage volumes attached to the pod.
C.They eliminate unnecessary shells and package managers, drastically reducing the attack surface.
D.They configure automatic mTLS between all pods in the cluster via CNI.
AnswerC

Distroless images ship only the application and its runtime dependencies, omitting shells, package managers and other utilities. Removing these executables denies attackers post-exploitation tooling and reduces exploitable packages, directly shrinking the attack surface as the scenario requires.

Why this answer

Distroless images contain only the application and its runtime dependencies, omitting package managers, shells, and other utilities. This drastically reduces the attack surface because attackers cannot easily execute shell commands, install tools, or exploit vulnerabilities in unnecessary packages. The primary security benefit is the minimized attack surface.

Exam trap

The trap is attributing unrelated security benefits to distroless images, such as encryption or mTLS; candidates must remember that distroless primarily reduces attack surface by removing unnecessary components.

How to eliminate wrong answers

Option A is wrong because distroless images have no impact on API server restarts during control plane upgrades; that is a control plane concern. Option B is wrong because distroless images do not encrypt persistent storage volumes; encryption is handled by storage classes or CSI drivers. Option D is wrong because distroless images do not configure mTLS between pods; mTLS is provided by a service mesh or CNI plugin, not by the image itself.

Practice this question →
44
Multi-Selectmedium

An organization is performing a STRIDE-based threat model on their Kubernetes deployment. Which TWO of the following threats map directly to the 'Tampering' category in a Kubernetes environment?

Select 2 answers
A.An attacker altering container image layers stored in an insecure registry
B.An attacker modifying Kubernetes API objects stored directly or in transit via compromised credentials
C.An attacker flooding the API server with requests to exhaust control plane memory
D.An attacker sniffing unencrypted pod-to-pod network traffic across the CNI bridge
E.An administrator denying that they executed a cluster deletion command due to missing logs
AnswersA, B

Tampering covers unauthorised modification of data. Altering image layers in a registry modifies stored artefacts, corrupting the integrity of what clusters pull and run. This directly satisfies the stem by mapping an integrity-violation scenario to the Tampering category.

Why this answer

Option A is correct because Tampering in STRIDE covers unauthorized modification of data, and altering container image layers in an insecure registry is a direct integrity attack on stored artifacts that Kubernetes nodes later pull and run. Option B is correct because modifying Kubernetes API objects—whether at rest in etcd or in transit to the API server using compromised credentials—is unauthorized alteration of cluster configuration and state, which is the canonical Tampering threat in Kubernetes. Option C is not Tampering but Denial of Service, since flooding the API server to exhaust control plane memory targets availability rather than integrity.

Option D is Information Disclosure (sniffing unencrypted pod-to-pod traffic), not Tampering, because it involves reading data rather than modifying it. Option E is Repudiation, as it concerns an administrator denying an action due to missing logs, which maps to the non-repudiation property rather than integrity.

Exam trap

The trap is conflating all 'attacker does something bad' scenarios with Tampering — candidates must distinguish integrity violations (Tampering) from confidentiality (Information Disclosure), availability (DoS), and accountability (Repudiation) violations.

Practice this question →
45
MCQmedium

A cluster administrator wants to mitigate supply chain risks stemming from vulnerable base images used by developers. Where in the software lifecycle should vulnerability scanning ideally be integrated first to shift-left security?

A.Manual inspection of etcd database backups
B.Configuring kube-dns forwarding rules to external resolvers
C.Setting up PersistentVolume backup retention policies
D.CI/CD pipeline build and image registry push stages
AnswerD

Integrating scanning at the CI/CD build and registry push stages catches vulnerable base images before deployment, satisfying the shift-left constraint. This prevents flawed images entering the registry, unlike runtime scanning which detects issues only after workloads are already running.

Why this answer

Shifting left means integrating security controls as early as possible in the software development lifecycle. Scanning base images during CI/CD build and at image registry push catches vulnerable packages before they are ever deployed to the cluster, allowing developers to remediate at the source. This is the earliest practical point where image vulnerabilities can be detected and blocked.

Exam trap

KCSA often tests whether candidates recognize 'shift-left' as meaning the earliest lifecycle stage, luring them toward cluster-side or runtime controls (NetworkPolicy, PSS, etcd hardening) that are not the first integration point for image scanning.

How to eliminate wrong answers

Option A (Manual inspection of etcd database backups) is wrong because etcd backups contain cluster state, not container image contents, and manual inspection is neither shift-left nor a vulnerability scanning mechanism. Option B (Configuring kube-dns forwarding rules to external resolvers) is wrong because DNS forwarding is a name-resolution configuration unrelated to image vulnerability scanning and may itself introduce security risk. Option C (Setting up PersistentVolume backup retention policies) is wrong because PV retention governs data durability, not the detection of vulnerable base images in the supply chain.

Practice this question →
46
Multi-Selecthard

Which THREE of the following supply chain vulnerabilities or risks can impact Kubernetes application deployments during the build or deployment phase?

Select 3 answers
A.Enforcing Pod Security Standards in baseline mode in production namespaces
B.Using outdated container base images containing known remote code execution CVEs
C.Typosquatting malicious packages in public package registries (npm, PyPI)
D.Deploying third-party Helm charts that contain backdoored deployment templates
E.Enabling Kubernetes audit logging with webhook sinks
AnswersB, C, D

Outdated base images ship known remote code execution CVEs that persist into every built layer, so exploitation occurs at runtime without any attacker action during build. This is a build-phase supply chain risk because the vulnerable dependency enters the artefact before deployment.

Why this answer

Option B is correct because outdated base images carry known RCE CVEs that are inherited by every image built FROM them, so the vulnerability is baked into the artifact during the build phase and shipped to the cluster at deployment. Option C is correct because typosquatting attacks publish malicious packages with names resembling legitimate ones on npm/PyPI, so a mistyped dependency in a Dockerfile or build script executes attacker code during image build. Option D is correct because third-party Helm charts can embed backdoored templates (e.g., privileged pods, hostPath mounts, or extra initContainers) that are rendered and applied at deployment time, compromising the workload.

Option A is not a vulnerability but a hardening control that restricts pod privileges, and Option E is a detection/auditing control using webhook sinks, so neither introduces a build- or deployment-phase supply chain risk.

Exam trap

KCSA often tests the confusion between supply chain risks and runtime/detection controls — candidates pick hardening or logging options that are mitigations, not vulnerabilities.

Practice this question →
47
MCQmedium

A DevOps team uses mutable image tags like `:latest` in their deployment manifests. Under supply chain threat modeling, what vulnerability does this practice introduce?

A.Automatic revocation of TLS certificates issued by cert-manager
B.Exposition of etcd database credentials on public DNS servers
C.Escalation of RBAC permissions from Role to ClusterRole
D.Image Tag Hijacking / Malicious substitution without manifest updates
AnswerD

Mutable tags are pointers, not immutable digests. An attacker who can push to the registry retags `:latest` to a malicious image, and the next pull silently deploys it because the manifest still references the same tag, with no change to trigger review.

Why this answer

Using mutable tags like :latest introduces the risk of image tag hijacking, where an attacker replaces the image referenced by that tag with a malicious one. Because the deployment manifest still references the same tag, Kubernetes will pull the new malicious image on the next pod restart or reschedule without any manifest change, leading to supply chain compromise. This is a classic supply chain threat in containerized environments.

Exam trap

KCSA often tests supply chain threats, and candidates may confuse image tag mutability with unrelated security controls like RBAC or TLS, or underestimate that a mutable tag can be silently replaced without manifest changes.

How to eliminate wrong answers

Option A is wrong because mutable image tags have no relationship to cert-manager TLS certificate revocation; cert-manager manages certificates independently of image tags. Option B is wrong because etcd credentials are not exposed via public DNS due to image tags; this is a nonsensical combination of unrelated concepts. Option C is wrong because RBAC permissions are defined in Role and ClusterRole bindings, not influenced by image tags; image tags cannot escalate RBAC permissions.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Kubernetes Threat Model questions.

Start 20-question session