Service Account Lifecycle Provisioning Strategy

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.