CKS Practice Question 2: ServiceAccount Token Automount
Certified Kubernetes Security Specialist (CKS) · Test 1 · question 2 of 10
A batch workload in the reporting namespace never talks to the Kubernetes API, yet a security review finds a valid API token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token inside every one of its containers. Other workloads in the same namespace also use the default ServiceAccount and *do* need their tokens.
You need to stop the token from being projected into this one workload's Pods, without changing the behaviour of the other workloads. What should you do?
Show answer and explanation
Answer:
The field exists in two places: on the ServiceAccount and on the Pod spec, and the Pod spec wins. Setting automountServiceAccountToken: false in the Pod template of just this workload removes the projected token volume from its containers only, which is precisely the scoped change the stem asks for.
Option B applies the setting correctly but at the wrong scope. Every Pod in the namespace that uses the default ServiceAccount and does not override the field would lose its token, breaking the other workloads.
Option C does not work. The default ServiceAccount is recreated automatically by the control plane, and in the meantime Pods that reference a missing ServiceAccount fail admission, so this breaks the namespace rather than hardening it.
Option D is based on an obsolete model. Since v1.24 the control plane no longer auto-creates a long-lived Secret for each ServiceAccount; the mounted credential is a short-lived projected token issued by the kubelet through the TokenRequest API, so there is no Secret to delete and the token would keep appearing.
Reference: Configure Service Accounts for Pods