Your enterprise organization is establishing baseline security and lifecycle standards for Identity and Access Management (IAM) across its Google Cloud resource hierarchy. The DevOps engineering team is tasked with defining standard operating procedures for provisioning new workload identities, managing default service accounts, and retiring decommissioned service accounts. The strategy must satisfy the following architectural requirements: Prevent newly created projects from automatically granting permissive Editor roles to default service accounts. Establish a standardized naming and configuration pattern for Compute Engine workload identities to maintain traceability and least privilege. Define a safe decommissioning lifecycle for obsolete application service accounts that prevents accidental permanent authorization loss and supports rapid rollback. Which strategy should the DevOps team implement?

Enforce the `iam.automaticIamGrantsForDefaultServiceAccounts` organization policy constraint, provision dedicated single-purpose user-managed service accounts using a `vm-[app-name]` naming convention with documented descriptions, and disable unused service accounts for a validation period before permanently deleting them.: ### What this solution is This solution implements an enterprise-grade Identity and Access Management (IAM) governance framework by combining organization policy enforcement, least-privilege workload identity provisioning, standardized naming conventions, and staged lifecycle deprovisioning. ### How it meets the requirements - **Preventing permissive default role grants**: Enforcing the organization policy constraint `iam.automaticIamGrantsForDefaultServiceAccounts` at the organization or folder level disables the automatic assignment of the basic `roles/editor` role to default service accounts when APIs like Compute Engine or App Engine are enabled. - **Establishing standardized naming and configuration**: Creating dedicated, single-purpose user-managed service accounts prefixed with workload indicators (e.g., `vm-[app-name]`) provides clear traceability in Cloud Audit Logs. Maintaining documentation and contact metadata in the description field prevents identity sprawl and aligns workload access with least privilege. - **Safe decommissioning lifecycle**: Disabling unused service accounts prior to permanent deletion preserves existing IAM allow policy bindings. If a disabled service account is mistakenly identified as obsolete, it can be re-enabled immediately without reconstructing its unique internal identity (`uniqueId`) or reapplying lost permission bindings. ### Key advantages and capabilities - **Preserved IAM Bindings**: When a service account is disabled and re-enabled, its underlying numeric identifier remains intact, ensuring all resource-level policy grants persist uninterrupted. - **Reduced Blast Radius**: Dedicated single-purpose service accounts ensure that applications do not share excessive privileges across different lifecycle stages or components. - **Auditing Transparency**: Prefixed email identifiers (such as `vm-`) clearly associate operational logs with specific infrastructure resources and workloads. - **Hardened Defaults**: Eliminating automatic Editor role assignments ensures that newly deployed projects start in a secure-by-default posture. ### Why this is optimal This strategy aligns directly with Google Cloud security best practices. Deleting a service account immediately breaks all IAM bindings permanently because recreating an account with the identical email generates a completely new unique ID. Disabling first provides a safety buffer while maintaining compliance across the resource hierarchy.

Service Account Lifecycle Provisioning Strategy | Professional Cloud DevOps Engineer

Service Account Lifecycle Provisioning Strategy

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 baseline security and lifecycle standards for Identity and Access Management (IAM) across its Google Cloud resource hierarchy. The DevOps engineering team is tasked with defining standard operating procedures for provisioning new workload identities, managing default service accounts, and retiring decommissioned service accounts.

The strategy must satisfy the following architectural requirements:

Prevent newly created projects from automatically granting permissive Editor roles to default service accounts.
Establish a standardized naming and configuration pattern for Compute Engine workload identities to maintain traceability and least privilege.
Define a safe decommissioning lifecycle for obsolete application service accounts that prevents accidental permanent authorization loss and supports rapid rollback.

Which strategy should the DevOps team implement?

Grant application teams the Service Account Admin role at the parent folder level, generate exportable JSON service account keys for VM workloads, and implement a daily scheduled query to immediately purge dormant service accounts.

Delete default service accounts immediately upon project creation, provision a shared user-managed service account across all projects within each environment folder, and immediately delete retired service accounts to clean up IAM policy bindings.

Revoke all project-level IAM roles granted to the Google APIs Service Agent, configure VMs to use default service accounts restricted solely by OAuth access scopes, and recreate deleted service accounts with identical names if an outage occurs.

Enforce the iam.automaticIamGrantsForDefaultServiceAccounts organization policy constraint, provision dedicated single-purpose user-managed service accounts using a vm-[app-name] naming convention with documented descriptions, and disable unused service accounts for a validation period before permanently deleting them.

Professional Cloud DevOps Engineer

Service Account Lifecycle Provisioning Strategy

Related questions