How to reassign resource ownership before someone’s last day

This article outlines a strategy for identifying stale resource ownership before it becomes an issue, whether someone leaves the company or changes teams. The goal is to address infrastructure ownership changes, which often go unnoticed. Marcus, who used to manage platform engineering for two years, was later promoted into a data platform position.

Despite HR updating his title and IT updating his badge access, over forty environments were still tagged with his email address. No one updated the infrastructure ownership, as it wasn't considered part of the job.

When a promotion, lateral move, or departure occurs, infrastructure ownership often gets neglected. The article emphasizes that a simple query, policy, and an extra step in the existing process for transferring someone off a team can help keep tags accurate. By mapping owner emails to IAM usernames and cross-referencing them against IAM user activity logs, stale tags can be identified. Queries can be applied to AWS, Azure, and GCP, with slight variations in syntax.

Once stale tags are identified, ownership must be reassigned through the existing role-based access control system. Instead of merely relying on a label, the ownership should be an actual role assignment in the governing system. This can be achieved by adding a policy that denies resources without an active owner. The policy enforcement can be integrated into CI pipelines, platforms like env zero, or any existing policy system.

Finally, the article stresses the importance of including a step in the offboarding checklist to verify what resources the departing team still owns. This simple step can prevent orphaned environments from remaining unmanaged for extended periods.