A city maps Active Directory groups to AWS IAM Identity Center permission sets for Management Console access across multiple accounts. What is the main advantage of this design?
Select an answer to reveal the explanation.
Short Explanation
One city directory group can unlock the right AWS doors in many accounts without minting a new IAM user everywhere. Identity Center permission sets are that mapping layer. You keep MFA and logging; you just stop cloning IAM users account by account.
Full Explanation
Mapping Active Directory groups to AWS IAM Identity Center permission sets gives a city one workforce identity plane across many AWS accounts. Employees sign in once through the corporate directory; Identity Center assigns permission sets that become short-term roles in selected accounts. That avoids minting unique IAM users in every member account, keeps joiner-mover-leaver processes in AD, and supports least-privilege sets such as NetworkOps or BillingReadOnly instead of cloned AdministratorAccess users.
Requiring a unique IAM user in each member account recreates sprawl and password fatigue. Forcing all users to share one AdministratorAccess IAM user per account destroys accountability. Claiming Identity Center replaces MFA and CloudTrail is false—SSO should strengthen MFA via the IdP, and CloudTrail remains mandatory for API accountability.
Exam caveat: permission sets are templates; assignments are per user/group and account. SCPs still constrain what those sessions can do. Operational check: place a pilot user in an AD group mapped to a read-only set on the parks account only; confirm console access works there and fails on finance; remove AD group membership and confirm access ends; verify no permanent IAM users were created in member accounts for that employee.