KCSA — Kubernetes Threat Model — Practice Questions

13 minute read

Practice Questions

Test your understanding of Kubernetes Threat Model concepts with these 10 multiple-choice questions. Each question mirrors the style and difficulty of the KCSA exam.

Read each question carefully before selecting your answer. The exam is conceptual — focus on understanding why each answer is correct.

Question 1 — STRIDE Category

An attacker gains access to a compromised pod and disables the Kubernetes audit logging by modifying the API server configuration. Which STRIDE category does this attack primarily fall under?

A) Spoofing

B) Tampering

C) Repudiation

D) Information Disclosure

Show Answer

Correct Answer: C) Repudiation

Explanation:

  • A) Spoofing — Incorrect. Spoofing involves impersonating an identity (e.g., using a stolen token). Disabling audit logs is not about identity impersonation.
  • B) Tampering — Incorrect. While the attacker is modifying a configuration, the primary intent is to cover their tracks, not to alter data for its own sake. Tampering focuses on unauthorized modification of data.
  • C) Repudiation — Correct. Repudiation means denying that an action occurred. By disabling audit logs, the attacker ensures there is no record of their activity — they can deny (repudiate) any actions they perform afterward.
  • D) Information Disclosure — Incorrect. Information disclosure involves exposing sensitive data to unauthorized parties. Disabling logs does not expose data; it removes evidence.

Question 2 — Trust Boundaries

A security architect is designing a multi-tenant Kubernetes cluster. They configure separate namespaces for each tenant but do not create any NetworkPolicies. Which statement is TRUE about this configuration?

A) Namespaces provide strong network isolation by default — no additional configuration is needed

B) Pods in different namespaces cannot communicate because namespaces are security boundaries

C) Pods in different namespaces can communicate freely because Kubernetes has a flat network by default

D) RBAC must be disabled for namespaces to provide network isolation

Show Answer

Correct Answer: C) Pods in different namespaces can communicate freely because Kubernetes has a flat network by default

Explanation:

  • A) Namespaces provide strong network isolation by default — Incorrect. This is a common misconception. Namespaces are a logical grouping mechanism, not a security boundary. Without NetworkPolicies, they provide zero network isolation.
  • B) Pods in different namespaces cannot communicate — Incorrect. By default, Kubernetes networking allows all-to-all pod communication regardless of namespace.
  • C) Pods in different namespaces can communicate freely — Correct. Kubernetes uses a flat network model where every pod can reach every other pod by default. Namespaces do not change this. NetworkPolicies must be explicitly created to restrict cross-namespace traffic.
  • D) RBAC must be disabled — Incorrect. RBAC controls API access, not network traffic. RBAC and NetworkPolicy are independent mechanisms.

Question 3 — Attack Surface Components

An attacker discovers that port 10250 on a Kubernetes worker node allows anonymous access. Which component is exposed, and what can the attacker do?

A) API server — the attacker can create and delete any Kubernetes resource

B) etcd — the attacker can read and modify all cluster state data

C) Kubelet — the attacker can list pods, execute commands in containers, and read logs on that node

D) Kube-proxy — the attacker can modify network routing rules for the cluster

Show Answer

Correct Answer: C) Kubelet — the attacker can list pods, execute commands in containers, and read logs on that node

Explanation:

  • A) API server — Incorrect. The API server typically runs on port 6443 (HTTPS) or 8080 (insecure, deprecated). Port 10250 is not the API server.
  • B) etcd — Incorrect. etcd uses ports 2379 (client) and 2380 (peer). Port 10250 is not etcd.
  • C) Kubelet — Correct. Port 10250 is the kubelet’s HTTPS API. With anonymous authentication enabled, anyone who can reach this port can: list all pods running on the node, execute commands inside any container on the node, read container logs, and retrieve node metrics. This is one of the most common and dangerous Kubernetes misconfigurations.
  • D) Kube-proxy — Incorrect. Kube-proxy handles node-level network routing but does not run on port 10250. Kube-proxy’s metrics port is typically 10249.

Question 4 — Container Escape Methods

A security researcher finds a pod running with the following configuration:

securityContext:
  privileged: true
volumes:
  - name: host-fs
    hostPath:
      path: /

What is the severity of this finding, and why?

A) Low — privileged mode only affects networking capabilities

B) Medium — hostPath mounts are read-only by default, so data cannot be modified

C) High — the combination allows reading host files but not executing commands on the host

D) Critical — the pod has virtually unrestricted access to the host system, equivalent to root on the node

Show Answer

Correct Answer: D) Critical — the pod has virtually unrestricted access to the host system, equivalent to root on the node

Explanation:

  • A) Low — only affects networking — Incorrect. Privileged mode does far more than affecting networking. It disables nearly all container isolation including access to host devices, kernel modules, and host filesystems.
  • B) Medium — hostPath is read-only — Incorrect. hostPath mounts are read-write by default. The attacker can both read and write to the entire host filesystem.
  • C) High — can read but not execute — Incorrect. With privileged mode and host filesystem access, the attacker can write to /etc/crontab, modify system binaries, read kubelet credentials, and effectively have full root access.
  • D) Critical — Correct. privileged: true combined with mounting the host root filesystem (/) gives the container unrestricted access to the host. The attacker can: read all files on the node, write to any file (crontab, sshd_config, kubelet config), access all other containers’ filesystems, and read cloud credentials from the metadata service. This is effectively root on the node.

Question 5 — Lateral Movement

After compromising a pod in the frontend namespace, an attacker scans the network and discovers a PostgreSQL database pod in the backend namespace listening on port 5432. The database has no password configured. No NetworkPolicies exist in the cluster. What enables this attack?

A) The attacker exploited the kubelet API to access pods across namespaces

B) Kubernetes’ flat network model allows all pods to communicate across namespaces by default

C) The attacker modified RBAC to grant cross-namespace access

D) The attacker compromised the API server to proxy traffic to the backend namespace

Show Answer

Correct Answer: B) Kubernetes’ flat network model allows all pods to communicate across namespaces by default

Explanation:

  • A) Kubelet API — Incorrect. While the kubelet API can be exploited, the scenario describes direct network communication between pods, not kubelet exploitation.
  • B) Flat network model — Correct. By default, Kubernetes networking follows a flat model where every pod gets an IP address and can communicate with every other pod in the cluster, regardless of namespace. Without NetworkPolicies, there is no network-level separation between namespaces. The attacker simply connects to the database pod’s IP on port 5432 — no special exploit needed.
  • C) RBAC modification — Incorrect. RBAC controls API access (e.g., listing pods, reading Secrets), not network traffic between pods. RBAC cannot block or allow TCP connections between pods.
  • D) API server proxy — Incorrect. The attacker does not need to use the API server. Direct pod-to-pod communication works at the network layer, independent of the API server.

Question 6 — Cloud Metadata Attack

An attacker inside a compromised Kubernetes pod runs curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ and receives temporary AWS IAM credentials. Which mitigation would most effectively prevent this attack?

A) Enable RBAC to restrict the pod’s Kubernetes API access

B) Apply a NetworkPolicy blocking egress traffic to 169.254.169.254/32

C) Set readOnlyRootFilesystem: true in the pod’s security context

D) Enable audit logging on the API server

Show Answer

Correct Answer: B) Apply a NetworkPolicy blocking egress traffic to 169.254.169.254/32

Explanation:

  • A) Enable RBAC — Incorrect. RBAC controls access to the Kubernetes API, not outbound HTTP requests from pods. The metadata endpoint is not exposed through the Kubernetes API.
  • B) NetworkPolicy blocking 169.254.169.254 — Correct. The cloud metadata endpoint (Instance Metadata Service — IMDS) is accessible via the link-local IP 169.254.169.254. A NetworkPolicy that denies egress to this IP directly prevents pods from reaching the metadata endpoint. This is the most effective and targeted mitigation. Additionally, using cloud-native solutions like AWS IRSA (IAM Roles for Service Accounts) or GCP Workload Identity eliminates the need for instance-level IAM credentials entirely.
  • C) readOnlyRootFilesystem — Incorrect. Making the filesystem read-only prevents writing to the container filesystem but does not block network requests to the metadata endpoint.
  • D) Audit logging — Incorrect. Audit logging records Kubernetes API requests, not pod-level network activity. It would not detect or prevent a curl to the metadata endpoint.

Question 7 — RBAC Misconfiguration Threat

A developer ServiceAccount has the following RBAC permissions:

rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create", "get", "list"]

Why is this a potential security risk, even though it looks minimal?

A) The list verb allows reading Secret values from all pods

B) The get verb exposes container runtime information

C) The create verb on pods allows creating privileged pods that can escape to the host

D) All three verbs combined allow modifying existing pod specifications

Show Answer

Correct Answer: C) The create verb on pods allows creating privileged pods that can escape to the host

Explanation:

  • A) list reads Secrets — Incorrect. The list verb on pods lets you list pod objects, not Secret objects. To read Secrets, you need permissions on the secrets resource.
  • B) get exposes runtime info — Incorrect. While get retrieves pod details, this is not the primary security concern with these permissions.
  • C) create on pods — Correct. The ability to create pods is one of the most powerful permissions in Kubernetes. A user who can create pods can: create a pod with privileged: true, mount the host filesystem via hostPath, use hostPID and hostNetwork to access host namespaces, and mount the ServiceAccount token of another SA with higher privileges. This effectively allows privilege escalation from pod-level to node-level access. This is why Pod Security Standards (PSS) are essential — they restrict what kind of pods can be created, even if RBAC allows pod creation.
  • D) All three allow modification — Incorrect. None of these verbs (create, get, list) allow modifying existing pods. That would require update or patch.

Question 8 — Mitigation Mapping

A security team identifies the following threat: “An attacker compromises one pod and moves laterally to access a database pod in another namespace.” Which Kubernetes-native mitigation directly addresses this threat?

A) Pod Security Standards (Restricted profile)

B) Encryption at rest using EncryptionConfiguration

C) NetworkPolicy with default-deny ingress and egress

D) ResourceQuota limiting the number of pods per namespace

Show Answer

Correct Answer: C) NetworkPolicy with default-deny ingress and egress

Explanation:

  • A) Pod Security Standards — Incorrect. PSS controls the security properties of pods (non-root, no privilege escalation, no host access). It does not control network-level communication between pods.
  • B) Encryption at rest — Incorrect. Encryption at rest protects data stored in etcd. It does not affect network traffic between pods.
  • C) NetworkPolicy — Correct. NetworkPolicy is the Kubernetes-native mechanism for controlling pod-to-pod network traffic. A default-deny policy blocks all inter-pod communication, then explicit allow rules permit only the necessary traffic flows. This directly prevents lateral movement from a compromised pod to other pods across namespaces.
  • D) ResourceQuota — Incorrect. ResourceQuota limits resource consumption (CPU, memory, number of objects) in a namespace. It does not control network traffic.

Question 9 — CIS Benchmark

During a CIS Kubernetes Benchmark audit using kube-bench, the following check FAILS:

[FAIL] 1.2.6 Ensure that the --anonymous-auth argument is set to false (API server)

Which STRIDE threat category does this failed check primarily expose the cluster to?

A) Denial of Service — anonymous users can overload the API server

B) Spoofing — unauthenticated users can interact with the API server without proving their identity

C) Information Disclosure — anonymous users can list all cluster resources

D) Tampering — anonymous users can modify API server configurations

Show Answer

Correct Answer: B) Spoofing — unauthenticated users can interact with the API server without proving their identity

Explanation:

  • A) Denial of Service — Incorrect. While anonymous access could theoretically contribute to DoS, that is not the primary threat. The core issue is the lack of identity verification, not resource exhaustion.
  • B) Spoofing — Correct. Anonymous authentication allows requests without any identity verification. This is fundamentally a Spoofing threat — the API server cannot verify who is making the request. When anonymous auth is enabled, requests are treated as coming from the system:anonymous user in the system:unauthenticated group. If RBAC grants permissions to these identities, attackers can access cluster resources without providing any credentials.
  • C) Information Disclosure — Incorrect. Information disclosure could be a consequence of anonymous access (if RBAC allows anonymous users to list resources), but the root threat is the inability to verify identity — which is Spoofing.
  • D) Tampering — Incorrect. Tampering requires not just access but the ability to modify data. The anonymous auth issue is about identity verification, not data modification permissions.

Question 10 — Kill Chain Stages

An attacker performs the following sequence of actions in a Kubernetes cluster:

  1. Exploits a known CVE in a public-facing web application
  2. Uses kubectl exec to run commands inside the compromised container
  3. Creates a CronJob that establishes a reverse shell every hour
  4. Reads the ServiceAccount token mounted in the pod
  5. Uses the token to list all pods and services across namespaces

Match step 3 to the correct attack kill chain stage:

A) Initial Access

B) Execution

C) Persistence

D) Discovery

Show Answer

Correct Answer: C) Persistence

Explanation:

  • A) Initial Access — Incorrect. Initial Access is how the attacker first gets into the system. That is Step 1 (exploiting the CVE). Step 3 happens after access is already established.
  • B) Execution — Incorrect. Execution is running attacker-controlled code. That is Step 2 (kubectl exec to run commands). While creating a CronJob involves execution, the purpose of the CronJob is to maintain access, which makes it Persistence.
  • C) Persistence — Correct. Persistence techniques ensure the attacker maintains access even if the original entry point is closed (e.g., the compromised pod is restarted or deleted). A CronJob that establishes a reverse shell every hour is a classic persistence mechanism — it recreates the attacker’s access on a schedule.
  • D) Discovery — Incorrect. Discovery is about learning about the environment. That is Step 5 (listing pods and services). Step 3 is about maintaining access, not discovering resources.

For reference, the full mapping:

  • Step 1 → Initial Access
  • Step 2 → Execution
  • Step 3 → Persistence
  • Step 4 → Credential Access
  • Step 5 → Discovery

Self-Assessment Scoring Guide

Count the number of correct answers and use the table below to assess your readiness.

Score Rating Recommendation
9–10 Excellent You have a strong grasp of Kubernetes Threat Model concepts. Review any missed questions and move on to the next chapter.
7–8 Good Solid understanding with minor gaps. Review the topics for the questions you missed before proceeding.
5–6 Needs Improvement Revisit the Threat Modeling Fundamentals and Mitigation Strategies sections before retaking.
Below 5 Review Required Go through the entire Kubernetes Threat Model chapter again. Focus on understanding the STRIDE model and the threat-to-mitigation mapping table.

Key Areas to Review If You Scored Below 8

  • STRIDE Model — Review Threat Modeling Fundamentals. Be able to classify any Kubernetes scenario into the correct STRIDE category.
  • Attack Surface — Review Kubernetes Attack Surface. Know which ports map to which components and what exposure means.
  • Lateral Movement — Review Common Attack Vectors. Understand that the flat network model is the root cause and NetworkPolicy is the fix.
  • RBAC Risks — Review Kubernetes-Specific Threats. Pod creation permission is a privilege escalation vector.
  • Mitigation Mapping — Review Mitigation Strategies. Memorize the three-column table: Threat → Mitigation → K8s Feature.

Back to: Kubernetes Threat Model — Hub Page →

Updated:

You may also enjoy