A security engineer is establishing access governance for automated multi-cloud pipelines and internal workloads that deploy infrastructure into Google Cloud. The architecture must satisfy the following security requirements: Eliminate the risk of credential leakage by completely forbidding the generation of persistent, static service account JSON keys across all projects. Enable external automated workloads running in external Kubernetes clusters to authenticate without static credentials. Allow automated deployment callers to generate short-lived OAuth 2.0 access tokens by acting on behalf of dedicated target service accounts, adhering strictly to the principle of least privilege. Which set of actions should the security engineer implement?

Enforce the iam.disableServiceAccountKeyCreation organization policy constraint, configure Workload Identity Federation with a Workload Identity Pool and Provider, and grant the Service Account Token Creator (roles/iam.serviceAccountTokenCreator) role to calling principals directly on the specific target service account resources.: ### What the solution is This architecture combines Google Cloud Organization Policy constraints, **Workload Identity Federation**, and resource-level IAM role bindings to establish secure credential delegation and completely remove static keys. ### How it meets the requirements - **Preventing static keys:** Enforcing the `constraints/iam.disableServiceAccountKeyCreation` Organization Policy at the root or folder level strictly prevents administrators and developers from creating new user-managed JSON or P12 service account private keys. - **External workload authentication:** **Workload Identity Federation** allows external workloads (such as external Kubernetes clusters, AWS, or Azure instances) to exchange local OIDC or SAML tokens via the **Security Token Service (STS)** for temporary Google Cloud credentials, eliminating persistent credentials outside Google Cloud. - **Least-privilege short-lived delegation:** Granting the **Service Account Token Creator** (`roles/iam.serviceAccountTokenCreator`) role directly on individual target service accounts (instead of at the project or organization level) allows designated callers to impersonate the target service account and mint short-lived OAuth 2.0 access tokens with granular scope. ### Key advantages - **Eliminates credential management debt:** Removes security exposure associated with downloading, rotating, and managing static key files. - **Resource-level granularity:** Applying `roles/iam.serviceAccountTokenCreator` on the specific service account resource prevents calling principals from impersonating all other service accounts within the project. - **Auditable lifecycle:** All token creation API calls are recorded in **Cloud Audit Logs**, linking the caller identity to the impersonated service account session. ### Why this is optimal This approach aligns with Google Cloud's security best practices by replacing long-lived credentials with short-lived tokens, enforcing organizational guardrails, and scoping impersonation authority to specific service account resources.

Service Account Impersonation Token Creator Governance | Professional Cloud Security Engineer

Service Account Impersonation Token Creator Governance

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.

A security engineer is establishing access governance for automated multi-cloud pipelines and internal workloads that deploy infrastructure into Google Cloud. The architecture must satisfy the following security requirements:

Eliminate the risk of credential leakage by completely forbidding the generation of persistent, static service account JSON keys across all projects.
Enable external automated workloads running in external Kubernetes clusters to authenticate without static credentials.
Allow automated deployment callers to generate short-lived OAuth 2.0 access tokens by acting on behalf of dedicated target service accounts, adhering strictly to the principle of least privilege.

Which set of actions should the security engineer implement?

Enforce the iam.disableServiceAccountKeyCreation organization policy constraint, configure Workload Identity Federation, and grant the Service Account Admin (roles/iam.serviceAccountAdmin) role to calling principals at the project level.

Enforce the iam.disableServiceAccountCreation organization policy constraint, configure Workload Identity Federation, and grant the Service Account User (roles/iam.serviceAccountUser) role to calling principals at the project level.

Enforce the iam.disableServiceAccountKeyUpload organization policy constraint, configure Cloud Key Management Service (Cloud KMS) to sign OAuth tokens, and grant the Service Account Token Creator (roles/iam.serviceAccountTokenCreator) role at the organization root level.

Enforce the iam.disableServiceAccountKeyCreation organization policy constraint, configure Workload Identity Federation with a Workload Identity Pool and Provider, and grant the Service Account Token Creator (roles/iam.serviceAccountTokenCreator) role to calling principals directly on the specific target service account resources.

Professional Cloud Security Engineer

Service Account Impersonation Token Creator Governance

Related questions