A security team uses AWS IAM Identity Center to give cloud engineers access across 50 accounts. Today they maintain dozens of nearly identical permission sets that differ only by which projects an engineer may touch, and adding a new project means editing many permission sets in every assignment. They want to collapse this into a small number of permission sets whose access scope is decided dynamically from the engineer's directory attributes, so a project change requires no new permission set. Which approach delivers this?
- AEnable attribute-based access control in IAM Identity Center, pass directory attributes such as project as session tags, and write permission set policies that allow actions only where the resource tag matches the aws:PrincipalTag value. Correct
- BCreate one permission set per project as before but generate them automatically with a CloudFormation StackSet, so the proliferation is at least produced from a single template and applied uniformly across accounts.
- CReplace the permission sets with a single service control policy that reads each engineer's project from their identity and restricts the account accordingly, centralising the project logic in the organisation guardrail.
- DKeep one broad permission set and have engineers call AWS STS AssumeRole with a session policy they construct from their own project list each time they sign in, so the scoping happens client-side per session.
Why A is correct: Attribute-based access control in Identity Center passes the engineer's directory attributes into the session as principal tags, and permission set policies that compare a resource tag to aws:PrincipalTag grant access based on those attributes, so a few permission sets cover every project and a project change is just a directory attribute update with no new permission set.
Why B is wrong: Templating the permission sets still leaves a separate one per project to assign and maintain, so it reduces drift but not the count, and adding a project still means generating and assigning new permission sets, which is the proliferation the team wants to eliminate.
Why C is wrong: Service control policies cannot read a user's directory attributes or grant access, they only cap permissions account-wide, so they cannot implement per-engineer project scoping and are the wrong mechanism for attribute-driven workforce access.
Why D is wrong: Letting engineers build their own session policies puts the access decision in the user's hands rather than driving it from trusted directory attributes, which is fragile and unsafe and does not centralise the project mapping in the identity source.