easyMultiple Choice
CKS Practice Question: The purpose of the 'automountServiceAccountToken:…
What is the purpose of the 'automountServiceAccountToken: false' setting in a Pod spec?
⚠ Common exam trap
CNCF often tests the misconception that disabling token mounting also disables the service account entirely, but the service account remains assignable and usable for other purposes (e.g., RBAC bindings), and the token can still be manually mounted if needed.
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
✓
It prevents the automatic mounting of the service account token into the pod
Setting `automountServiceAccountToken: false` in a Pod spec prevents the automatic mounting of the Kubernetes service account token (a JWT) into the Pod's filesystem at `/var/run/secrets/kubernetes.io/serviceaccount/token`. This is a security hardening measure to reduce the attack surface for compromised containers, as the token can be used to authenticate to the Kubernetes API server. By default, Kubernetes mounts this token into every Pod, so explicitly disabling it is necessary when the Pod does not require API access.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
It disables the service account controller
Why it's wrong here
Setting automountServiceAccountToken to false has no bearing on the service account controller. That controller is a control-plane component that ensures the requested ServiceAccount object exists and manages its namespace lifecycle; it continues to operate normally. This field only influences a pod-level mount behavior, so the controller is never disabled or modified by this setting.
- ✓
It prevents the automatic mounting of the service account token into the pod
Why this is correct
When automountServiceAccountToken is set to false on a Pod or on the ServiceAccount it references, the kubelet does not automatically project the service account token into the container filesystem at the default path /var/run/secrets/kubernetes.io/serviceaccount/token. This reduces the risk of token extraction from a compromised container. The pod still runs with the specified service account identity, but the credential is not provided automatically; any use of the token would require explicit, manual mounting.
- ✗
It deletes the service account after the pod starts
Why it's wrong here
Service accounts are persistent cluster resources that exist independently of any pod. Even if a pod sets automountServiceAccountToken to false, the ServiceAccount object remains intact and is not deleted when the pod starts or finishes. Kubernetes has no mechanism that ties the deletion of a service account to a pod's lifecycle, and this field has no relation to deletion.
- ✗
It prevents the pod from using any service account
Why it's wrong here
This option misstates the effect: setting automountServiceAccountToken to false does not remove the pod's service account assignment. A pod still has an associated service account (the 'default' one unless another is specified), and the Kubernetes authentication layer still treats the pod as belonging to that service account. The setting only suppresses the automatic injection of the token into the container, not the identity association itself.
Go deeper
Related to this question
About these practice questions
One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.