A municipal billing Deployment and its metrics sidecar should not share one over-privileged identity. What ServiceAccount pattern best supports least privilege?
Select an answer to reveal the explanation.
Short Explanation
One shared "everything" badge for every desk is how privilege creeps. Give each component its own ServiceAccount and only the Role bindings it needs. Default SA everywhere or cluster-admin tokens are the opposite of least privilege.
Full Explanation
Least privilege for city workloads starts with identity boundaries. When a municipal billing Deployment and a metrics sidecar (or companion component) both need Kubernetes API access, giving them one shared over-privileged ServiceAccount forces every container to inherit the widest permission set either component might need. The better civic pattern is a dedicated ServiceAccount per component, each bound only to the Role or ClusterRole verbs that component actually exercises—billing might get/list ConfigMaps, while metrics might only scrape limited resources. Separate badges at the API desk keep privilege creep from turning a sidecar into an unintended admin path.
Reusing the default ServiceAccount in every namespace for all Pods looks operationally simple but concentrates risk: any workload that later needs extra verbs tends to widen the default SA, and every Pod automatically shares that expanded blast radius. Mounting a cluster-admin token Secret into containers as an environment variable bypasses scoped RBAC entirely and embeds a master key in process environments and potentially logs. Disabling ServiceAccounts and baking full admin kubeconfigs into images is even worse: credentials become immutable image content, hard to rotate, and available to anyone who can pull or exec into the container.
Exam caveat: CKAD expects you to create ServiceAccounts, Roles/RoleBindings, and set serviceAccountName on Pod templates—not to “just use default” or cluster-admin for convenience. Operational check: kubectl get sa,rolebinding -n <billing-ns>; describe the RoleBindings and confirm subjects point at the dedicated SAs; then kubectl auth can-i --list --as=system:serviceaccount:<ns>:<billing-sa> versus the metrics SA and verify each list is minimal. In the Deployment specs, confirm each Pod template sets serviceAccountName explicitly so the components do not silently fall back to default.