A CI Job deploys apps using a dedicated ServiceAccount in the payments namespace but cannot create Deployments. What binding pattern grants the least-privilege fix?
Select an answer to reveal the explanation.
Short Explanation
Give the CI ServiceAccount a namespace Role and RoleBinding—like a contractor badge for one department. That is least privilege for deploy rights. cluster-admin everywhere is a master key you do not need.
Full Explanation
A CI Job that deploys apps with a dedicated ServiceAccount in the payments namespace but cannot create Deployments needs a namespace Role listing the required Deployment verbs and a RoleBinding whose subjects include that CI ServiceAccount in payments. That binding pattern is least privilege for municipal payment pipelines: one identity, one namespace, only the verbs required to roll out applications—without elevating unrelated accounts.
Binding cluster-admin to the default ServiceAccount in every namespace fails least privilege and creates a catastrophic blast radius if any Pod uses default. Storing a long-lived user token in a ConfigMap mounted by the Job fails secret hygiene and still depends on RBAC for that identity. Granting the kubelet permission to mutate Deployments cluster-wide for CI fails separation of duties; kubelet is a node agent identity, not a continuous-delivery principal.
Exam caveat: the RoleBinding must reside in the payments namespace when binding a Role there, and verb lists must match what the CI tooling actually calls (create, patch, update, get, list). Operational check: create the Role and RoleBinding, test with kubectl auth can-i create deployments --as=system:serviceaccount:payments:<sa> -n payments, rerun the Job, and verify Deployments appear in payments.