An enterprise security engineer is hardening identity governance for a production Google Cloud environment. A security audit reveals that several Compute Engine virtual machines (VMs) are utilizing the Compute Engine default service account (PROJECT_NUMBER-compute@developer.gserviceaccount.com) with the Editor role (roles/editor). Additionally, multiple legacy workloads are being decommissioned, and the operations team plans to immediately delete their associated service accounts. Which strategy should the security engineer implement to remediate the VM identities and manage the decommissioning lifecycle according to Google Cloud best practices?

Provision dedicated, single-purpose user-managed service accounts with least-privilege roles for the VMs, and disable the decommissioned service accounts for an observation period before deleting them.: What User-Managed Service Accounts and Disabling Lifecycles Are User-managed service accounts are custom identities created and managed by administrators within a project to provide workload-specific authentication and authorization. Managing the service account lifecycle by disabling unused accounts before permanently deleting them is a recommended security control that prevents operational disruption while mitigating lateral movement and privilege escalation risks. How It Meets the Audit and Lifecycle Requirements Remediating default service account exposure: By creating dedicated, single-purpose user-managed service accounts, the security team can attach unique identities to specific Compute Engine workloads and grant only the granular IAM roles required for their exact tasks. This eliminates reliance on the default Compute Engine service account and removes the overly permissive roles/editor role. Safely decommissioning legacy accounts: Disabling a service account immediately prevents new access tokens or authentication requests from succeeding, effectively neutralizing any security threat or lateral movement. However, disabling keeps all IAM policy bindings and configuration references intact. Preventing permanent configuration loss: If an unexpected dependency arises during offboarding, a disabled account can be instantly re-enabled. If the account were deleted immediately and recreated with the exact same email address, Google Cloud assigns a completely new internal unique numerical ID, meaning all previous IAM bindings and resource attachments are permanently lost. Key Advantages and Capabilities Granular access boundaries: Dedicated service accounts ensure that permissions do not accumulate across disparate applications sharing a single default account. Precise audit trails: Cloud Audit Logs record the specific service account email executing API actions, enabling clear non-repudiation and traceability per application. Reversible offboarding: Disabling serves as a safe validation gate during decommissioning and security investigations before irreversible deletion. Maintained resource associations: Attached VMs and role grants remain intact during the temporary disabled state, allowing seamless rollback if needed. Why This Is Optimal This approach directly resolves the security vulnerabilities of over-privileged default accounts by implementing least-privilege custom identities, while following established enterprise lifecycle practices to prevent catastrophic configuration loss caused by premature service account deletion.