A security engineer needs to configure access for an engineer (developer@example.com) who must generate short-lived OAuth 2.0 access tokens to impersonate a specific deployment service account (deploy-prod@example-proj.iam.gserviceaccount.com) from their local environment. The project contains multiple sensitive service accounts used by critical infrastructure. To uphold the principle of least privilege and prevent unintentional privilege escalation, how should the security engineer grant the necessary access?

Grant the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) to `developer@example.com` directly on the `deploy-prod@example-proj.iam.gserviceaccount.com` service account resource.: ### What the Service Account Token Creator Role Is The **Service Account Token Creator** role (`roles/iam.serviceAccountTokenCreator`) grants principals the permissions necessary to generate short-lived credentials for a service account, including **OAuth 2.0 access tokens**, **OIDC ID tokens**, and signed JSON Web Tokens (JWTs). This enables direct credential generation and service account impersonation without relying on long-lived service account private keys. ### How It Meets the Requirements - **Token Generation for Impersonation**: By holding `roles/iam.serviceAccountTokenCreator`, the engineer can programmatically request short-lived access tokens to authenticate API calls and run deployment workflows as the service account. - **Least Privilege and Resource-Level Scope**: Granting this role directly on the target service account (`deploy-prod@example-proj.iam.gserviceaccount.com`) restricts impersonation capabilities strictly to that single identity. It prevents the principal from impersonating other sensitive or higher-privileged service accounts within the same project. ### Key Advantages and Capabilities - **Eliminates Static Key Management**: Avoids the security risks associated with downloading, rotating, and storing exported service account private keys. - **Precise Authorization Boundary**: Confines token creation permissions to an individual identity rather than inheriting blanket project-wide impersonation privileges. - **Full Auditability**: Requests for short-lived credentials via the IAM Credentials API are logged in **Cloud Audit Logs**, detailing both the calling user and the impersonated identity. ### Why This Is Optimal Applying the role at the **resource level** (on the specific service account allow policy) rather than at the project level ensures strict isolation. It enables the engineer to execute their deployment duties without risking unauthorized privilege escalation across other service accounts residing in the project.