A static content Pod never calls the Kubernetes API. Which setting reduces unnecessary credential exposure?
Select an answer to reveal the explanation.
Short Explanation
If the app never talks to the API, don't hang a VIP badge on it. Turn off automountServiceAccountToken so no token volume shows up by default. That shrinks the blast radius if the container is compromised.
Full Explanation
A static content Pod that never calls the Kubernetes API should set automountServiceAccountToken false on the Pod or its ServiceAccount so a token is not auto-mounted. That reduces unnecessary credential exposure for municipal static sites that have no need to speak to the apiserver.
Binding cluster-admin to the Pod so it can delete its own token after start massively increases privilege and is the opposite of reducing exposure. Storing the SA token in a ConfigMap mounted world-readable for easier revocation publishes credentials broadly. Switching the Pod to hostNetwork so ServiceAccount tokens are unused by kubelet does not remove token mounts and introduces host networking risks.
Exam caveat: some sidecars or operators unexpectedly need API access—disable automount only when sure nothing in the Pod calls the API. Operational check: set automountServiceAccountToken false, deploy, exec to confirm the token path is absent, and keep RBAC bindings minimal for that ServiceAccount. In CKAD scenarios involving q221, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings. Keep municipal change tickets linked to the exact manifest diff so operators can audit why q221 was adjusted.