How do you ensure a Build or Deployment uses a specific ServiceAccount?

• A. Set serviceAccountName in the Pod spec and grant the account necessary permissions through Roles.
• B. Attach the ServiceAccount to the Route.
• C. Store the ServiceAccount name in a ConfigMap.
• D. Add serviceAccount to the image registry.

Answer: (B)

The key idea is that a pod’s identity and permissions come from the ServiceAccount bound to that pod. To ensure a Build or Deployment uses a specific ServiceAccount, you bind the pod to that account by setting the serviceAccountName field in the Pod spec (for a Deployment, this is in spec.template.spec.serviceAccountName). This makes the pod receive the ServiceAccount’s token and credentials, so it can authenticate to the API server and act within the permissions granted to that SA.

After binding the ServiceAccount, grant the necessary permissions by creating Roles or ClusterRoles and binding them to that ServiceAccount with RoleBindings or ClusterRoleBindings. That combination—binding the pod to the SA and giving it the appropriate RBAC permissions—ensures the Build or Deployment operates with the intended identity and access.

The other options don’t achieve this binding: attaching a ServiceAccount to a Route doesn’t affect the pod’s runtime identity; storing the name in a ConfigMap is just configuration data with no automatic binding to the pod; adding the ServiceAccount to the image registry is unrelated to runtime authentication and permissions.