A county workforce must sign in to many AWS accounts using Microsoft Entra ID without creating long-lived IAM users in each account. Which approach best meets this requirement?
Select an answer to reveal the explanation.
Short Explanation
Nobody wants a separate badge printer in every county building. IAM Identity Center plus Entra ID gives one workforce login and permission sets into many accounts. Cloning IAM users everywhere is the password-sprawl special.
Full Explanation
County workforce access across many AWS accounts should federate through AWS IAM Identity Center with Microsoft Entra ID as the external identity provider. Employees authenticate to Entra ID, Identity Center maps groups to permission sets, and those permission sets are assigned across Organization accounts. That model eliminates the need to create long-lived IAM users in every account, centralizes joiner/mover/leaver lifecycle in the corporate directory, and produces temporary, auditable console and CLI sessions aligned to least privilege.
Creating matching IAM users and access keys in every account for each employee recreates credential sprawl, annual-only rotation is too weak, and it directly violates the “no long-lived IAM users per account” goal. Sharing a single root user password across departments is a critical anti-pattern that destroys accountability and MFA boundaries. Disabling federation and mailing hardware tokens per account without an IdP may add MFA devices but still fails to provide scalable, directory-backed multi-account workforce access.
Exam caveat: IAM Identity Center (successor to AWS SSO) is the multi-account workforce answer; Amazon Cognito is for application/customer identity—do not swap them on SAP-C02. Operational check: connect Entra ID, provision a pilot group to a permission set on two accounts, confirm users sign in via the Identity Center portal without local IAM users, verify CloudTrail shows AssumeRoleWithSAML/Identity Center events, and revoke a group membership to prove access disappears.