GCP Associate Cloud Engineer Practice Question 10: Service Account Impersonation

Service Account Token Creator (roles/iam.serviceAccountTokenCreator) includes iam.serviceAccounts.getAccessToken, the permission that lets a principal mint short-lived credentials for a service account. Granting it *on the service account resource itself*, rather than on the project, limits the developer to impersonating just that one identity. The --impersonate-service-account flag then makes the gcloud CLI obtain a short-lived access token for pipeline-sa and run the command as it, with no key material anywhere on disk. The developer's own account still holds none of the service account's permissions; it merely holds the right to borrow them, and every impersonation is recorded in audit logs.

Option A is prohibited by the stated organization policy, and even without that policy, a long-lived downloaded key emailed to a person is the credential-handling anti-pattern this whole feature exists to replace.

Option C fails on two counts. roles/iam.serviceAccountUser allows attaching a service account to resources such as VMs and jobs so those resources run as it; it does not grant iam.serviceAccounts.getAccessToken, so it does not enable gcloud impersonation. And gcloud auth activate-service-account requires a downloaded key file, which is unavailable.

Option D grants the ability to create, delete, and manage service accounts (a privilege escalation path far beyond what is needed), and, like Service Account User, Service Account Admin does not itself confer the token-creation permission that impersonation requires.

Reference: Service account impersonation