A SaaS company runs 200 project environments where engineers change teams monthly, each project uses resources tagged ProjectID, and engineers carry matching job-project attributes from Identity Center. Which authorization strategy should the IAM architect implement to grant project access without updating policies on every transfer?

The correct strategy succeeds because attribute-based access control evaluates aws:PrincipalTag against aws:ResourceTag/ProjectID at request time, with Identity Center passing the engineer's project attribute as a session tag via the role trust, so one role provides isolated least-privilege access across 200 tagged environments and team changes take effect automatically without editing policies. Assigning dedicated Identity Center permission sets per ProjectID is a standard and effective isolation pattern, but it fails the operational requirement because administrators must remove and add assignments on every monthly transfer. Creating a single shared role that can access all ProjectID values also avoids monthly policy work and is operationally simple, but it fails least privilege and project separation by allowing engineers to affect projects outside their assignment. Building ABAC on manually maintained IAM user tags uses correct tag-matching logic and is common for small teams, but it fails the stated identity fact because it ignores Identity Center attributes and still requires manual tag updates on each move, reintroducing delay and stale-access risk. For the exam, treat no policy updates combined with principal and resource tags as a strong signal for federated ABAC rather than permission-set reassignment or broad roles, and watch whether isolation or automation is sacrificed. Before deployment, confirm Identity Center attribute mappings, enforce mandatory ProjectID tags, and test with the policy simulator using different principal values to verify only matching projects are accessible.