mediumMultiple Choice
CKS Practice Question: A security policy requires that all…
A security policy requires that all ServiceAccounts in a namespace do not automatically mount their tokens. How can this be achieved at the namespace level?
⚠ Common exam trap
CNCF often tests the distinction between namespace-level and pod-level controls, and the trap here is that candidates mistakenly think PodSecurityPolicy can control token mounting or that deleting the default ServiceAccount is a viable solution, when in fact the ServiceAccount's `automountServiceAccountToken` field is the intended namespace-wide mechanism.
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
✓
Set automountServiceAccountToken: false in the ServiceAccount definition
Setting `automountServiceAccountToken: false` in the ServiceAccount definition applies the setting to all pods that use that ServiceAccount, effectively enforcing the policy at the namespace level when the default or all ServiceAccounts are configured this way. This is the correct approach because the ServiceAccount's `automountServiceAccountToken` field controls token mounting for pods referencing it, overriding any pod-level setting unless explicitly set in the pod spec.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set automountServiceAccountToken: false in each pod spec
Why it's wrong here
Setting automountServiceAccountToken: false directly in each pod spec only affects that specific pod's API token projection and does not enforce the policy across the namespace. New pods created without this field, or workloads managed by controllers like Deployments, will still mount the default token unless every pod template is individually edited. This is an operational workaround, not a namespace-wide control, and it is easy to miss pods or future workloads, leaving the security requirement unenforced.
- ✗
Use a PodSecurityPolicy to deny token mounting
Why it's wrong here
PodSecurityPolicy (PSP) was deprecated as of Kubernetes v1.21 and removed in v1.25, so it cannot be relied upon for current security enforcement. Even where PSP is still present, it is an admission controller that applies to pods, but it cannot directly set the automountServiceAccountToken field on a ServiceAccount; you would need a mutating PSP or webhook, which is complex and not the intended tool. Consequently, using PSP does not provide a simple, supported, or cluster-wide solution for disabling token auto-mounting.
- ✓
Set automountServiceAccountToken: false in the ServiceAccount definition
Why this is correct
Setting automountServiceAccountToken: false on the ServiceAccount definition is the correct, namespace-scoped control because this field controls whether the kubelet automatically projects the service account token into every pod that uses that account. When applied to the default ServiceAccount, it affects all pods in that namespace that do not explicitly override the setting, since most workloads implicitly use the default account unless a different one is specified. This is the precise, declarative mechanism designed to disable automatic token mounting at the service account level, fulfilling the security policy cleanly.
- ✗
Delete the default ServiceAccount
Why it's wrong here
Deleting the default ServiceAccount is dangerous because Kubernetes automatically recreates the 'default' ServiceAccount in each namespace, so the deletion is not persistent. During the window before recreation, or if the recreation fails, existing or new pods that implicitly rely on the default service account may fail to be admitted or may lack necessary credentials for the API server. Additionally, even if you could delete it permanently, any workload referencing the 'default' account would break, making this an unreliable and non-declarative way to enforce the policy compared to simply modifying the ServiceAccount's field.
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.