hardMultiple ChoiceObjective-mapped
PT0-002 Practice Question: During an internal penetration test, a tester…
During an internal penetration test, a tester compromises a server that is part of a Kubernetes cluster. The tester has access to the node's operating system but not to the cluster's administrative credentials. Which of the following techniques would most likely allow the tester to escalate privileges to cluster-admin or access sensitive resources within the cluster?
⚠ Common exam trap
Candidates often assume kernel exploits (Option B) are always the best escalation path, but in Kubernetes, the service account token is a simpler and more direct method to access the API server from a compromised node.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Extracting a service account token from a running container and using it to access the Kubernetes API
Service account tokens are automatically mounted into pods at /var/run/secrets/kubernetes.io/serviceaccount/token. An attacker with node-level access can extract this token from a running container's filesystem and use it to authenticate to the Kubernetes API server. Since service accounts are often granted broad permissions via RBAC bindings, this token may allow the tester to access sensitive resources or even escalate to cluster-admin if the service account has such privileges.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Extracting a service account token from a running container and using it to access the Kubernetes API
Why this is correct
Inside the compromised container, a JWT-bearing service account token is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token along with the CA certificate and namespace. Reading these files lets the tester authenticate to the kube-apiserver using the pod's service account identity. If that service account is bound to an RBAC ClusterRoleBinding (e.g., cluster-admin), the attacker immediately gains full cluster control, making this the most direct and reliable escalation path from a compromised pod.
- ✗
Exploiting a kernel vulnerability on the node to escape to the host and then compromise the Kubernetes API server
Why it's wrong here
Even though the tester is already on the node OS, exploiting a kernel vulnerability (e.g., Dirty COW) only escalates to root on that single node's underlying host. Kubernetes RBAC is enforced by the API server, and node root does not map to a cluster-admin identity. The node's kubelet credentials are signed for the system:nodes group and have limited permissions, so you would still need an additional step to obtain an API-level privilege escalation. This path is more invasive and less likely to yield cluster-level control than reusing the pod's existing service account token.
- ✗
Searching for a kubeconfig file on the node that contains a cluster-admin token
Why it's wrong here
A kubeconfig on a node is usually generated for the kubelet and references a client certificate or a token that authenticates to the API server under the system:nodes group. That identity is restricted to operations for the node's own pods and to the /api/v1/nodes/<name>/proxy endpoint—not to cluster-admin. While a misconfigured environment might contain an admin kubeconfig, relying on that in a penetration test is a guess rather than a deterministic attack. In practice, reading the kubelet's kubeconfig gives only node-scoped privileges, which does not achieve cluster-admin.
- ✗
Modifying a ConfigMap to inject a malicious pod that runs with elevated privileges
Why it's wrong here
ConfigMaps are API server resources, so modifying one (e.g., via kubectl patch) requires authentication and authorization to the Kubernetes API. At this stage the tester only controls the container's filesystem and has no API credentials, so the request would be rejected. Additionally, ConfigMaps do not directly create pods; they are consumed when a pod is defined, and a malicious pod would need to be submitted to the API server by an authenticated user. Thus this option pushes the problem forward and does not help in the initial compromise.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
Courseiva writes every PT0-003 question from scratch — 185 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PT0-003 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PT0-003 exam.