Your enterprise organization is establishing a secure operational framework for service account usage across its development teams. You must configure IAM permissions to support two distinct operational requirements while strictly enforcing the principle of least privilege: Requirement 1: A designated group of engineers (devops-leads@example.com) must be able to impersonate a production deployment service account (prod-deployer@project-id.iam.gserviceaccount.com) from the Google Cloud CLI to obtain short-lived OAuth 2.0 access tokens for emergency rollouts without managing static keys. Requirement 2: A broader team of developers (app-devs@example.com) must be able to provision Compute Engine virtual machines that run workloads under a dedicated workload service account (app-runner@project-id.iam.gserviceaccount.com), but they must not be permitted to directly generate credentials or mint tokens for this workload service account from their local workstations. Which IAM role bindings should you configure?

Grant `roles/iam.serviceAccountTokenCreator` to `group:devops-leads@example.com` on `prod-deployer`, and grant `roles/iam.serviceAccountUser` to `group:app-devs@example.com` on `app-runner`.: ### What the Solution Is This configuration leverages **resource-level IAM role bindings** to grant specific, scoped capabilities to each group on individual service accounts, avoiding broader project-level over-permissioning. ### How It Meets the Requirements - **Meets Requirement 1:** The **Service Account Token Creator** role (`roles/iam.serviceAccountTokenCreator`) contains the `iam.serviceAccounts.getAccessToken` permission. Granting this role directly on `prod-deployer@project-id.iam.gserviceaccount.com` allows `devops-leads@example.com` to use the `--impersonate-service-account` flag in `gcloud` or call the IAM Credentials API to generate short-lived OAuth 2.0 tokens without exposing long-lived service account keys. - **Meets Requirement 2:** The **Service Account User** role (`roles/iam.serviceAccountUser`) grants the `iam.serviceAccounts.actAs` permission. Binding this role to `app-devs@example.com` on `app-runner@project-id.iam.gserviceaccount.com` allows developers to attach the service account to compute resources (such as Compute Engine instances). It deliberately does not include token generation permissions (`iam.serviceAccounts.getAccessToken`), preventing developers from minting tokens to impersonate the service account directly from their workstations. ### Key Advantages and Capabilities - **Principle of Least Privilege:** Applying IAM bindings directly at the service account resource level prevents unintended access to other service accounts in the project. - **Short-Lived Authentication:** Eliminates the security risk and maintenance lifecycle of downloadable private keys. - **Separation of Duties:** Differentiates the ability to attach identities to compute infrastructure (`actAs`) from the ability to mint credentials interactively (`getAccessToken`). - **Comprehensive Audit Trail:** Calls to `generateAccessToken` and actions utilizing `iam.serviceAccounts.actAs` generate Cloud Audit Logs identifying both the caller and the target service account. ### Why This Is Optimal Granting roles at the individual service account resource level rather than the project level minimizes the blast radius. Binding `roles/iam.serviceAccountTokenCreator` and `roles/iam.serviceAccountUser` to their respective targets precisely satisfies operational needs without creating privilege escalation paths.

Configure Iam Service Account User Token Creator | Professional Cloud DevOps Engineer

Configure Iam Service Account User Token Creator

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

Your enterprise organization is establishing a secure operational framework for service account usage across its development teams. You must configure IAM permissions to support two distinct operational requirements while strictly enforcing the principle of least privilege:

Requirement 1: A designated group of engineers (devops-leads@example.com) must be able to impersonate a production deployment service account (prod-deployer@project-id.iam.gserviceaccount.com) from the Google Cloud CLI to obtain short-lived OAuth 2.0 access tokens for emergency rollouts without managing static keys.
Requirement 2: A broader team of developers (app-devs@example.com) must be able to provision Compute Engine virtual machines that run workloads under a dedicated workload service account (app-runner@project-id.iam.gserviceaccount.com), but they must not be permitted to directly generate credentials or mint tokens for this workload service account from their local workstations.

Which IAM role bindings should you configure?

Grant roles/iam.serviceAccountUser to group:devops-leads@example.com on prod-deployer, and grant roles/iam.serviceAccountTokenCreator to group:app-devs@example.com on app-runner.

Grant roles/iam.serviceAccountTokenCreator to group:devops-leads@example.com on prod-deployer, and grant roles/iam.serviceAccountUser to group:app-devs@example.com on app-runner.

Grant roles/iam.serviceAccountAdmin to group:devops-leads@example.com on prod-deployer, and grant roles/iam.serviceAccountOpenIdTokenCreator to group:app-devs@example.com on app-runner.

Grant roles/iam.serviceAccountTokenCreator and roles/iam.serviceAccountUser to both groups at the Google Cloud project level.

Professional Cloud DevOps Engineer

Configure Iam Service Account User Token Creator

Related questions