An enterprise already federates its workforce into AWS through IAM Identity Center connected to Azure AD, with permission sets assigned per account. New project teams spin up frequently, and each new project means authoring another permission set and re-assigning it across accounts, which is becoming a bottleneck. Identity attributes such as project and cost-centre already exist in Azure AD. The team wants access to follow these attributes so a single reusable definition grants the right scope without a new permission set per project. Which approach MOST reduces this ongoing assignment overhead?
- AContinue creating one permission set per project but script the assignments with infrastructure as code, so the templated automation provisions each new permission set across the relevant accounts whenever a project starts.
- BReplace IAM Identity Center with per-account SAML federation roles whose trust policies branch on Azure AD attributes, recreating the equivalent set of roles in every member account so the attributes drive which role each user is allowed to assume.
- CEnable attribute-based access control in IAM Identity Center, pass the project and cost-centre attributes from Azure AD as session tags, and write permission set policies that allow actions only on resources tagged to match those session attributes. Correct
- DKeep static permission sets and instead attach a permission boundary per project that references the project attribute, deploying the matching boundary into each account as projects are created and retired.
Why A is wrong: Automating assignment reduces clicks, but it still mints and maintains a distinct permission set for every project, so the underlying proliferation that causes the bottleneck remains.
Why B is wrong: Per-account SAML roles can read identity attributes, but abandoning Identity Center reintroduces duplicated role management in every account, which is plainly more overhead than the current model rather than less.
Why C is correct: Attribute-based access control lets one reusable permission set scope access dynamically by comparing Azure AD session tags to resource tags, so new projects need no new permission set or reassignment.
Why D is wrong: Permission boundaries cap permissions but must be authored and deployed per project per account, so they add a parallel artefact to maintain rather than removing the per-project assignment work.