mediumMultiple ChoiceObjective-mapped
CKS Practice Question: A developer creates a pod with the following…
A developer creates a pod with the following YAML: apiVersion: v1 kind: Pod metadata: name: mypod spec: serviceAccountName: default automountServiceAccountToken: true containers: - name: app image: nginx
What is the security concern with this configuration?
⚠ Common exam trap
CNCF often tests the misconception that the `default` service account is always safe or that the namespace choice is the primary risk, when in fact the automatic mounting of the service account token—especially when combined with overly permissive RBAC bindings—is the direct security concern.
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
✓
The service account token is automatically mounted, potentially providing excessive permissions
Setting `automountServiceAccountToken: true` (or omitting it, as it defaults to true) causes the pod to automatically mount the service account token of the `default` service account into the container. This token can grant excessive permissions if the default service account has been bound to roles with broad access, such as cluster-admin or other privileged RBAC bindings, which is a common misconfiguration. An attacker who compromises the container can then use this token to authenticate to the Kubernetes API server and perform unauthorized actions within the cluster.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The pod does not specify resource limits
Why it's wrong here
The absence of resource requests and limits can allow the container to consume unbounded CPU and memory, potentially leading to resource exhaustion on the node and impacting neighboring workloads. While this is a significant operational risk and a common security hardening recommendation, it is unrelated to the pod's identity or Kubernetes API access. The service account token issue is a separate and more immediate credential-exposure concern.
- ✗
The container runs as root
Why it's wrong here
The container running as root is a privilege concern because a compromised process would have root capabilities within its namespace, but it does not directly provide Kubernetes API credentials. Even with root access in the container, the ability to perform cluster-level actions depends on the mounted service account token and associated RBAC permissions. The YAML does not define a securityContext, so the container runs with its default user, yet this is not the primary security issue here.
- ✓
The service account token is automatically mounted, potentially providing excessive permissions
Why this is correct
By default, Kubernetes mounts the service account token into every pod at /var/run/secrets/kubernetes.io/serviceaccount/token unless automountServiceAccountToken is explicitly set to false. This token is a bearer credential that grants API access based on the service account's RBAC bindings, and using the default service account often includes more permissions than the application actually needs. If the container is compromised, an attacker can retrieve this token and authenticate to the Kubernetes API to escalate privileges, read secrets, or disrupt other workloads. Thus, automatically mounting the token is the most direct security concern.
- ✗
The pod uses the 'default' namespace
Why it's wrong here
Using the 'default' namespace is not a security vulnerability in itself; namespaces are logical isolation boundaries, and the risk depends on the RBAC rules applied to the service account and the namespace's objects. The default namespace often contains the default service account, but the mere presence of the pod there does not grant extra permissions. The issue remains the automatically mounted service account token, not the namespace choice.
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 CKS question from scratch — 114 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 CKS practice question is part of Courseiva's free CNCF 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 CKS exam.