A freight company with 8,000 staff uses Okta for workforce login and just acquired a carrier using Microsoft Entra ID. Both groups need SSO to 40 AWS accounts with joiner-mover-leaver provisioning without managing IAM users. Which identity federation design centralizes AWS access with automated lifecycle management?
Select an answer to reveal the explanation.
Short Explanation
You want one front door with automatic badges. Central SSO plus directory sync grants the right accounts on day one and revokes them on exit, and SCIM keeps membership fresh without manual work.
Full Explanation
The correct design works because IAM Identity Center accepts a single external identity source, so the two workforce directories must be consolidated upstream, for example by making Okta the hub that federates the acquired carrier's Entra ID tenant. That one IdP connects to Identity Center with SAML for SSO, and SCIM automates joiner-mover-leaver provisioning and deprovisioning of users and groups at 8,000-user scale, while permission sets assigned to groups apply across all 40 accounts without creating IAM users. Federating via SAML with manual assignments gives SSO but fails lifecycle automation because, without SCIM, moves and leavers need help-desk updates that drift and leave orphaned access. Connecting only Okta with SCIM and keeping Entra ID accounts separate automates one population but fails centralization, since the acquired carrier keeps siloed administration and inconsistent audit. Synchronizing both directories to AWS Managed AD and federating to IAM roles reintroduces directory infrastructure and per-account roles and trust policies instead of centrally managed permission sets. On the exam, remember Identity Center has one identity source, so multi-IdP scenarios imply a hub IdP or migration upstream. In practice, verify SCIM attribute mappings and group-to-permission-set assignments in a sandbox, test joiner-mover-leaver events end to end, and confirm CloudTrail shows only short-term federated sessions.