Disabling Automatic Service Account Token Mounting

• A.Delete the service account token secret
• ✓ B.Add 'automountServiceAccountToken: false' to the pod spec
• C.Use a NetworkPolicy to block access to the token
• D.Set the service account's 'automountServiceAccountToken' field to false

Why B: Option B is correct because setting `automountServiceAccountToken: false` in the pod spec explicitly disables the automatic mounting of the service account token into the pod. This is the most direct and granular way to prevent the token from being available inside the container, which is a key hardening step to reduce the attack surface if the pod does not need to interact with the Kubernetes API.

• A.Set automountServiceAccountToken: false in each pod spec
• B.Use a PodSecurityPolicy to deny token mounting
• ✓ C.Set automountServiceAccountToken: false in the ServiceAccount definition
• D.Delete the default ServiceAccount

Why C: 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.

• A.Set --service-account-issuer flag on API server
• B.Set env: - name: KUBERNETES_SERVICE_ACCOUNT_TOKEN to false
• ✓ C.Set automountServiceAccountToken: false in the ServiceAccount YAML
• ✓ D.Set spec.automountServiceAccountToken: false in the Pod spec
• ✓ E.Use the 'default' service account with automount disabled

Why C: Option C is correct because setting `automountServiceAccountToken: false` in the ServiceAccount YAML disables automatic mounting of the service account token for all pods that use that ServiceAccount. This is a declarative way to prevent the Kubernetes API server from injecting the token volume into pods, which is a key security hardening step to reduce the attack surface from compromised pods.

• ✓ A.The automountServiceAccountToken field is set in the container spec instead of the pod spec
• B.The kubelet is configured to always mount tokens
• C.The namespace has a default automountServiceAccountToken: true
• D.The pod is using a custom service account with automountServiceAccountToken: true

Why A: The `automountServiceAccountToken` field is a pod-level setting. If it is set to `false` in the pod spec, the kubelet will not automatically mount the service account token. However, if the field is mistakenly set inside a container spec (which is not a valid field for containers), the pod-level setting is ignored, and the default behavior (mounting the token) applies. This is why the token still appears mounted despite the intention to disable it.

• A.It disables the service account controller
• ✓ B.It prevents the automatic mounting of the service account token into the pod
• C.It deletes the service account after the pod starts
• D.It prevents the pod from using any service account

Why B: 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.