A company already manages employee identities and groups in an external SAML 2.0 identity provider and wants staff to sign in once and assume roles across 40 AWS Organizations accounts without creating IAM users. Group membership in the external provider should drive the AWS permissions each person receives. Which design meets this with the least operational overhead?
- ACreate an IAM SAML identity provider and matching IAM roles in each of the 40 member accounts and have users assume roles through the AWS sign-in federation endpoint.
- BSynchronise the external groups into Amazon Cognito user pools and exchange Cognito tokens for temporary credentials in each account using identity pools.
- CEnable IAM Identity Center with the external provider as the SAML identity source, define permission sets, and assign access by syncing the external groups. Correct
- DCreate individual IAM users in a central account, federate them through the external provider, and grant cross-account roles by attaching policies that map to each external group.
Why A is wrong: Per-account SAML providers and roles work but duplicate trust and role configuration across 40 accounts, which is high maintenance rather than the least overhead.
Why B is wrong: Cognito targets application and customer sign-in rather than workforce access to the AWS console, so it does not cleanly map workforce groups to account roles.
Why C is correct: IAM Identity Center connects one external SAML source, provisions accounts through permission sets, and maps synced groups to access in one place, minimising per-account work.
Why D is wrong: Creating IAM users contradicts the no-IAM-users requirement and still leaves manual group-to-policy mapping, increasing long-term administrative effort.