Examkin

Question

Difficulty: Very hardConfiguring Service Account Impersonation and Workload Identity

An organization mandates that infrastructure deployments executed by developers from their local workstations to the production project `proj-landing-zone` must use short-lived credentials. Long-lived service account JSON keys are explicitly prohibited by organizational policy. A dedicated service account `[email protected]` has already been assigned all necessary resource management permissions in `proj-landing-zone`. To enable developers to execute `gcloud auth application-default login --impersonate-service-account=sa-terraform-deployer@proj-landing-zone.iam.gserviceaccount.com` without granting them direct permissions to modify resources in the project, which IAM configuration is required?

  1. Grant the developer group the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) directly on [email protected].Answer
  2. B
    Grant the developer group the Service Account User role (roles/iam.serviceAccountUser) directly on [email protected].
  3. C
    Grant the developer group the Editor role (roles/editor) at the proj-landing-zone project level so that permissions inherit to the service account.
  4. D
    Export a service account JSON key for [email protected] and have developers set the GOOGLE_APPLICATION_CREDENTIALS environment variable.

Answer

Grant the developer group the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) directly on the target service account resource.
To impersonate a service account using gcloud CLI or Application Default Credentials (ADC) short-lived token generation, the calling principal must be granted the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`). Granting this role directly on the specific service account adheres to the principle of least privilege and avoids using long-lived JSON service account keys.

Step-by-Step Solution

1
Identify the authentication requirement and organizational constraints.
Developers must authenticate using short-lived credentials via service account impersonation without downloading JSON keys.
Security mandates keyless short-lived authentication for local workstation executions.
2
Distinguish between IAM roles related to service accounts.
The Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) provides permissions to mint short-lived tokens (iam.serviceAccounts.getAccessToken, signJwt, etc.), whereas Service Account User (roles/iam.serviceAccountUser) only grants permission to attach service accounts to GCP compute resources.
CLI impersonation via application-default login requires generating OAuth 2.0 access tokens on behalf of the service account.
3
Apply least privilege access binding on the specific resource.
Bind roles/iam.serviceAccountTokenCreator directly on the target service account ([email protected]) to the developer principal group.
Binding at the service account level restricts token creation privileges specifically to that service account rather than across all project service accounts or granting unnecessary project-level access.

Key Concept

Service Account Impersonation and Token Creation Roles
Rate this question

Topics

Configuring Service Account Impersonation and Workload Identity

More questions from this topic