You are connecting an existing corporate identity provider such as Okta or Entra ID to AWS IAM Identity Center for an organization of forty accounts. How do you wire identities in, and how do you make sure someone who leaves loses AWS access?

## Choosing the identity source An Identity Center instance has exactly one identity source: its own built-in directory, AWS Managed Microsoft AD or AD Connector, or an external identity provider over SAML 2.0. With a corporate IdP already in place, the external provider is the obvious choice — you do not want a second population of users, a second MFA policy, or a second offboarding checklist. Changing the identity source later is disruptive, so this is a decision worth making once and deliberately. ## Two protocols, two jobs The most common misunderstanding is thinking SAML alone is enough. - **SAML 2.0 is the authentication path.** At sign-in the IdP produces an assertion; Identity Center validates it and starts a portal session. It says nothing about who exists tomorrow. - **SCIM 2.0 is the provisioning path.** The IdP pushes create, update and deactivate operations for users and groups into Identity Center over a provisioning endpoint with a bearer token. Identity Center holds a synchronised *copy* of those principals. The copy is necessary because an account assignment is a persistent record that binds a principal to a permission set and an account. That principal must exist in Identity Center before you can assign anything to it, so a user who has never been provisioned cannot be granted access, no matter what their SAML assertion says. Operationally, SCIM has its own failure modes worth pre-empting: the provisioning token expires and must be rotated on a schedule, only the groups explicitly put in scope on the IdP side sync, and group renames on the IdP side can create surprises for assignments. Alarm on SCIM sync failures — a silently broken sync means leavers stop being deprovisioned while everything else keeps working. ## Assignments belong to groups With forty accounts, per-user assignment is unmanageable and unauditable. The design that holds: - A modest catalogue of job-shaped permission sets, reused across accounts. - Groups in the IdP named for the access they represent, one group per (job function, environment) pair, owned by whoever should be approving that access. - Assignments binding group to permission set to account. Joiners, movers and leavers then never touch AWS. Access review becomes a review of group membership in the system where HR-driven lifecycle already runs, and the question "who can deploy to production?" has one place to look. Attribute-based access control is available for finer slicing — attributes from the identity source become principal tags that permission-set policies can reference — but it is an addition to this structure, not a replacement for it. ## What actually happens when someone leaves The honest answer, and the one interviewers are listening for, has three stages: 1. **The IdP deactivates the user.** New sign-ins fail immediately. 2. **SCIM propagates the change**, disabling the user in Identity Center. Their portal session ends and no further role credentials can be issued for any account. 3. **Credentials already in hand keep working until they expire.** A session minted twenty minutes earlier with an eight-hour duration is valid for another seven hours and forty minutes. Nothing about disabling the user retroactively invalidates it. That third point drives real decisions. Set permission-set session durations to the shortest that people can work with — the revocation lag equals the duration you chose. For genuinely urgent revocation you can attach a deny to the affected role or revoke sessions issued before a timestamp, but that is incident response, not the routine path. Confirm the mechanics of SCIM propagation and session expiry against current AWS documentation before quoting timings. ## The parts you keep outside the IdP - **Break-glass.** If the identity provider is down or misconfigured, federated access to every account is down with it. Keep a very small number of emergency credentials with hardware MFA, stored physically, unused in normal operation, and alarmed loudly on any use. - **Workload identity.** Applications and pipelines never appear in the IdP; they take roles from their compute or federate over OIDC. Do not let a human-shaped identity become an automation account. - **Organization-level guardrails.** The policies that cap what any principal in an account can do are a separate control layer from who signs in, and they should be designed independently. ## The shape of a good answer Separate the two protocols, insist on group-based assignment as the lifecycle mechanism, and be explicit that deprovisioning is not instantaneous. Candidates who claim access is cut off the moment the user is disabled have not operated this.