IAM Identity Center (AWS SSO) & Federation
Recap: Where We Left Off
Control Tower gave us the automated landing zone: a management account that holds no workloads, a log-archive account that aggregates CloudTrail from everywhere, an audit account that owns the security tooling, and guardrails implemented as SCPs and Config rules. Account Factory for Terraform extended that baseline into pipeline-driven account provisioning, so a new account arrives already inside the governance envelope rather than being retrofitted into it later.
That is a story about accounts and policy. It says nothing about the humans who need to log into those accounts. Control Tower will happily provision forty accounts with impeccable guardrails and still leave you with the question of how an engineer authenticates to any of them. Today sits at the same lifecycle stage as yesterday's material — the account exists, the guardrail is attached — but the concern is entirely different: identity, not infrastructure. The distinction matters because the two concerns fail in different ways. A missing guardrail is a policy gap you can audit for. A missing identity strategy is a sprawl of long-lived IAM users that nobody can enumerate, rotate, or revoke cleanly.
Foundations You'll Need Today
Today's material assumes a handful of building blocks that the rest of this curriculum treats as background knowledge. If you have not worked hands-on with AWS identity, here is what each one actually is and what problem it solves.
IAM roles and trust policies
An IAM user is an identity with a permanent name and password or access key — it belongs to one account and exists until someone deletes it. An IAM role is different: it is an identity that nobody logs into directly. Instead, a role is something a person or a program temporarily becomes. When you assume a role, AWS hands you a short-lived set of credentials that expire on their own, and when they expire you have to assume the role again to get new ones. That is the whole point — there is no long-lived secret sitting anywhere for an attacker to steal.
The other half of a role is its trust policy. A role has two separate sets of rules attached to it, and confusing them is the single most common source of identity mistakes. The permissions policy says what the role is allowed to do once you are inside it — read this bucket, start that instance. The trust policy says who is allowed to assume the role in the first place. A role can have broad permissions and still be safe if almost nobody is trusted to assume it, and it can have narrow permissions and still be dangerous if the trust policy is wide open. Today's material leans on this distinction constantly, because Identity Center works by creating roles in your accounts and setting their trust policies to allow the Identity Center service to assume them on a user's behalf.
Temporary credentials and STS
STS stands for Security Token Service, and it is the AWS component that actually issues temporary credentials. When something assumes a role, STS is the service that validates the request, checks the trust policy, and returns a credential set with an expiration time baked in. Those credentials are what the caller uses for every subsequent API call until they expire.
The reason this matters today is that it is the mechanism underneath the entire federated login story. When a user clicks an account in the Identity Center portal, Identity Center calls STS to assume the corresponding role, and the user's browser session is backed by those temporary credentials. Nothing durable is created for that user in the target account — no password, no access key, no user object. The role is the only lasting artifact, and the credentials are ephemeral by design.
SAML 2.0 federation
Federation is the idea that you can prove who you are using an identity system that is not AWS, and then carry that proof into AWS. The identity system is called an identity provider, or IdP — Okta, Microsoft Entra ID, and Ping are the common corporate ones. Your company already runs one of these; it is what you type your work password into every morning.
SAML 2.0 is the specific protocol that carries that proof across the boundary. The flow is roughly: you authenticate to your corporate IdP, the IdP produces a signed digital document called an assertion that says "this is who this person is, and we vouch for it," and AWS verifies the signature and accepts the claim. The signature is what makes it trustworthy — AWS does not need to know your password, it only needs to trust the IdP's signing key. This is why the exam scenarios keep mentioning an "existing SAML 2.0 identity provider": it means the company already has a place where employees authenticate, and the question is how to reuse it for AWS rather than building a parallel set of credentials.
SCIM provisioning
SAML solves authentication — proving who someone is at login time. It does not solve the problem of keeping the list of users and groups in sync between the IdP and AWS. That is what SCIM does. SCIM is a separate, simpler protocol that lets the IdP push its user and group records into a downstream system automatically, so that when someone joins a team or leaves the company, the change propagates without anyone manually updating AWS.
The practical consequence is that group membership in your corporate directory becomes the thing that drives AWS access. You assign permissions to a group once, and then adding someone to that group in the IdP is what grants them access — no AWS-side action at all. The catch, which today's failure-modes section covers, is that this synchronization is not instant, so there is a window where the IdP and AWS disagree about who is in which group.
With that grounding — roles that are assumed rather than logged into, temporary credentials issued by STS, and a corporate IdP whose assertions and group records can be trusted and synchronized — here is why IAM Identity Center exists and what problem it actually solves.
1. Why This Is on the Exam
Every SAP-C02 scenario that involves more than a handful of accounts eventually has to answer the question of how people get in. The exam's design-domain questions are built around organizations that have already solved account structure and are now confronting the operational consequences of that structure: forty accounts means forty places a departing employee might still have credentials, forty places a password policy has to be enforced, and forty places an auditor will ask you to produce an access review for. The architectural problem IAM Identity Center solves is not authentication in the abstract — it is the elimination of per-account human identity as a category.
The reason this shows up repeatedly rather than once is that it intersects with almost every other governance topic. It is the delivery mechanism for the least-privilege story that SCPs and permission boundaries describe. It is the reason a multi-account landing zone is operationally survivable rather than merely well-structured. And it is the piece that most commonly gets answered wrong on practice exams, because candidates reach for the mechanism they already know — IAM users, cross-account roles, a shared credential — when the scenario is explicitly describing a centralized workforce identity problem.
Map it to the exam domains and the weight becomes clearer. It sits primarily in the organizational-complexity design domain, where the questions are about designing for governance at scale across many accounts. It also appears in the security-controls domain, where the question is how you enforce consistent authentication and authorization without duplicating configuration. And it appears in the cost and operational-excellence domains indirectly, because the alternative — per-account IAM users — carries a real operational tax that shows up as headcount and toil rather than as a line item on the bill.
The exam pattern to internalize is this: whenever a scenario mentions a corporate identity provider by name (Okta, Entra ID, Ping, or a generic "existing SAML 2.0 identity provider"), mentions a large number of accounts, and mentions a requirement that users not have separate credentials per account, the answer is IAM Identity Center. The distractors will be plausible — cross-account roles with a trust policy, a shared bastion with local users, IAM users provisioned by a script — and each of them solves a narrower version of the problem while leaving the central one intact.
2. How It Actually Works
IAM Identity Center is a service that lives in one specific account — conventionally the management account of the organization, though AWS now supports a delegated administrator account for it — and from that home it reaches into every other account in the organization. The core abstraction is the permission set. A permission set is not an IAM policy and not an IAM role; it is a template that describes a set of policies, a session duration, and optionally a permissions boundary and relay state. When you assign a permission set to a principal for a given account, Identity Center materializes it in that account as an actual IAM role, with a trust policy that allows the Identity Center service to assume it on behalf of a federated user.
The identity side of the service has two possible sources. The first is the built-in Identity Center directory, which is a lightweight user store suitable for small organizations or for a pilot. The second, and the one that matters for enterprise scenarios, is an external SAML 2.0 identity provider. In that configuration, Identity Center acts as a SAML service provider: the user authenticates against the corporate IdP, the IdP issues a signed SAML assertion, and Identity Center consumes that assertion to establish who the user is. Group membership can be synchronized from the IdP via SCIM, which is what makes group-based assignment practical at scale rather than requiring per-user assignment records.
The authorization flow after authentication is worth walking through because exam questions probe it. The user authenticates to the IdP and receives a SAML assertion. Identity Center validates the assertion and determines which accounts and permission sets that user is entitled to, based on assignments made to the user directly or to a group the user belongs to. It presents the user with a portal listing those accounts and roles. When the user selects one, Identity Center calls STS to assume the corresponding IAM role in the target account, and the user receives temporary credentials scoped to that role. The role in the target account is a normal IAM role — it appears in the account's IAM console, it can be referenced in policies, and it can be audited like any other role.
Two consequences follow from this design and both are exam-relevant. First, there are no long-lived credentials anywhere in the human access path. The user's only credential is their corporate identity, and the AWS-side credential is a temporary STS session. Second, the target account does not need to know anything about the identity provider. It only needs to trust the Identity Center service principal. That decoupling is what allows a single IdP integration to serve an arbitrary number of accounts without per-account federation configuration.
3. The Core Decision Boundary
The fork that most scenario questions hinge on is whether the human access problem is being solved centrally or per-account. Centralized means one identity source, one assignment model, one place to revoke. Per-account means each account owns its own users and roles, and the organization's access posture is the sum of forty independent decisions. The exam almost always frames the correct answer as the centralized option, but the interesting part is recognizing which distractors are actually per-account solutions wearing a centralized costume.
A cross-account role with a trust policy is the most common of these. It is a legitimate pattern and it does centralize the authorization decision in a sense — the trusting account decides who may assume the role. But it does not centralize identity. The user still needs an identity somewhere to assume the role from, and if that identity is an IAM user in a hub account, you have simply moved the long-lived credential problem rather than eliminated it. The distinction the exam is drawing is between centralizing the role and centralizing the human.
The second fork, once you have decided on centralization, is the identity source: built-in directory versus external IdP. This is less about correctness and more about fit. An organization with an existing corporate directory and a compliance requirement that all access flow through it will use federation. An organization standing up a greenfield environment with no existing IdP may reasonably start with the built-in directory and migrate later. The exam rarely tests the built-in directory as a correct answer for an enterprise scenario, but it does test whether you understand that the two are alternatives rather than layers.
| Approach | Identity source | Credential lifetime | Revocation | Scales to N accounts |
|---|---|---|---|---|
| IAM users per account | Per-account, duplicated | Long-lived access keys | Manual, per account | Poorly — N× the work |
| Cross-account role from a hub IAM user | Hub account IAM user | Long-lived at the hub | Manual at the hub | Partially — one credential, many roles |
| IAM Identity Center, built-in directory | Identity Center | Temporary STS session | Central, immediate | Yes |
| IAM Identity Center + external SAML IdP | Corporate IdP | Temporary STS session | Central, follows IdP lifecycle | Yes, and reuses existing joiner/mover/leaver |
The row that matters most for exam purposes is the last one, because it is the only row where the AWS access lifecycle is a consequence of a process the organization already runs. When an employee leaves, disabling them in the corporate IdP removes their AWS access across every account, with no AWS-side action required. That property — access that follows employment rather than being maintained in parallel with it — is what the exam is usually testing when it describes a large enterprise with an existing identity provider.
4. Permission Sets, Assignments and Their Tradeoffs
A permission set is defined once and assigned many times, and the design decisions inside it determine how much flexibility you retain later. The policies attached to a permission set can be AWS managed policies, customer managed policies that you author in the Identity Center account, or inline policies. The choice between them is a lifecycle question: an AWS managed policy like ReadOnlyAccess is maintained by AWS and updates as services are added, which is convenient but means the permission set's effective permissions can change without your involvement. A customer managed policy gives you a stable, reviewable definition at the cost of having to maintain it yourself.
Session duration is the second knob and it is a genuine security-versus-friction tradeoff. A shorter session means credentials expire sooner and a compromised session has a smaller window, but it also means users re-authenticate more often, which in practice pushes people toward keeping a browser tab open indefinitely. The default is one hour and the maximum is twelve hours, and the exam-relevant point is that the session duration is a property of the permission set, not of the user or the account. If you need different durations for different roles, you need different permission sets.
Assignments are the third dimension and the one that determines your operational load. An assignment binds a principal — a user or a group — to a permission set in a specific account. Assigning to groups rather than users is the practice that makes the model maintainable, because group membership is managed in the IdP and flows in via SCIM synchronization. An organization that assigns permission sets to individual users has recreated the per-account user management problem in a new console; an organization that assigns to groups has a model where onboarding is a group membership change and offboarding is its removal.
The relay state and permissions boundary options are less commonly tested but worth knowing. Relay state lets you send a user to a specific console URL after they assume a role, which is useful for deep-linking into a particular service. A permissions boundary attached to a permission set caps what the resulting role can do even if the attached policies are broader — the same mechanism that will occupy tomorrow's material, applied here as a guardrail on the roles Identity Center creates. Both are set at the permission set level and inherited by every assignment of that set.
5. Sizing, Limits and Quotas
The quotas that matter for Identity Center are mostly about how many of each object you can create and how quickly the service can provision roles into accounts. These are soft limits in most cases and can be raised through a support request, but the exam expects you to know the shape of the constraints and, more importantly, to know which ones are hard. The table below collects the numbers that come up in practice; each is documented in the AWS Identity Center quotas reference and the Organizations service quotas page.
| Resource | Default quota | Adjustable | Why it matters |
|---|---|---|---|
| Permission sets per Identity Center instance | Varies by region; commonly in the low hundreds | Yes, via support | Caps how finely you can slice roles |
| Accounts per organization | Governed by AWS Organizations quotas | Yes | Determines the assignment matrix size |
| Maximum session duration per permission set | 12 hours | No — hard ceiling | Bounds the blast radius of a stolen session |
| Default session duration | 1 hour | Yes, per permission set | Friction versus exposure tradeoff |
| SCIM group and user sync | Bounded by IdP and Identity Center sync quotas | Yes | Determines how fast joiner/mover/leaver propagates |
The provisioning behavior is the part that surprises people operationally. When you create an assignment, Identity Center does not create the role instantly in every case; it queues the work and provisions the role into the target account asynchronously. In a large organization where a single group assignment fans out to dozens of accounts, that fan-out takes measurable time, and a user who tries to use the role before provisioning completes will see it missing from their portal. This is not a failure — it is the normal propagation delay — but it is the reason a runbook for onboarding a new team should include a verification step rather than assuming immediate availability.
The other sizing consideration is the assignment matrix itself. If you have A accounts and P permission sets and you assign every permission set in every account, you have A×P assignments to maintain. The practical guidance is to keep the permission set count small and meaningful — a read-only set, a power-user set, an admin set, and a handful of workload-specific sets — and to let group membership carry the variation. Organizations that create a permission set per team per environment end up with an assignment matrix that nobody can review, which defeats the purpose of centralizing in the first place.
6. Failure Modes and What They Look Like in Production
The most common production failure is a broken SAML trust, and its symptom is that users can reach the IdP, authenticate successfully, and then land on an error page from Identity Center rather than the account portal. The cause is almost always a mismatch in the SAML configuration: a changed certificate on the IdP side that was not updated in Identity Center, an audience URI that does not match, or an attribute mapping that no longer produces the expected NameID. The first diagnostic move is to check the Identity Center sign-in audit events, which record the SAML response outcome and will tell you whether the assertion was rejected and why.
The second failure mode is stale group membership, and it is more insidious because it does not produce an error. A user who was removed from a group in the IdP but whose SCIM synchronization has not yet propagated will still see the accounts and roles that group granted. The symptom is an access review that shows someone with permissions they should not have, and the diagnostic is to compare the IdP's group membership against the assignments visible in Identity Center. The fix is usually to force a synchronization, but the underlying lesson is that SCIM propagation is not instantaneous and your offboarding runbook needs to account for the lag.
The third failure mode is the orphaned role. When an assignment is deleted, Identity Center removes the corresponding role from the target account, but if the role was modified manually — someone attached an extra policy directly to it in the account — that modification is lost, and if the deletion is interrupted the role can be left in an inconsistent state. The symptom is a role that exists in the account but has no corresponding assignment in Identity Center, which means nobody can assume it through the portal but it still appears in IAM listings and in access reviews. The diagnostic is to reconcile the account's roles against the Identity Center assignment list; the fix is to delete the orphan and treat the role as service-managed rather than hand-editable.
There is a fourth failure that is organizational rather than technical: the delegated administrator is not configured, so all Identity Center administration happens in the management account. This is not a failure in the sense of an outage, but it is a governance failure, because it means the account that is supposed to hold no workloads now holds the administrative surface for every human identity in the organization. The symptom is that the security team needs management-account access to do routine identity work, which is exactly the blast-radius problem the landing zone was designed to avoid.
7. The Operational and SRE Angle
Identity Center is infrastructure, and it should be monitored like infrastructure even though it has no servers you can see. The signals that matter are authentication success and failure rates, provisioning latency for new assignments, and SCIM synchronization health. CloudTrail records the Identity Center API calls, including the AssumeRole calls that result from portal logins, and those events are the raw material for both security monitoring and availability monitoring. A sudden drop in successful AssumeRole calls during business hours is an availability incident; a sudden rise in failed SAML assertions is either an IdP problem or an attack.
The SLO framing is worth thinking through explicitly because it clarifies what you are actually promising. The user-visible service is "I can log in and reach the account I need." That decomposes into the IdP being available, Identity Center being available, the assignment existing, and the role being provisioned in the target account. Each of those has a different owner and a different failure signature, and an SLO that does not decompose the dependency chain will page the wrong team. In practice, the useful alarm is a synthetic check that performs a portal login and role assumption on a schedule, because it exercises the whole chain rather than any single component.
The runbook shape follows from the failure modes above. A login failure runbook starts with the sign-in audit events, then checks the SAML certificate expiry, then checks the IdP's own health. An access-review runbook reconciles IdP group membership against Identity Center assignments and flags drift. An onboarding runbook creates the group membership, waits for synchronization, verifies the assignment appears, and confirms the role is provisioned in the target account before telling the user they are ready. An offboarding runbook removes the group membership and then verifies that the user can no longer assume any role — which is a positive test, not an assumption.
One operational detail that is easy to miss: the Identity Center instance lives in a specific region, and the portal endpoint is regional. An organization with a global workforce should be aware of which region hosts the instance and whether that creates a latency or data-residency concern. The service is highly available within its region, but it is not a global service in the way IAM is, and treating it as one is a mistake that shows up as a regional dependency nobody documented.
8. Edge Cases and Exam Gotchas
The single most common exam trap is the scenario that describes a large enterprise with an existing identity provider and then offers "create IAM users in each account" as a distractor. It is never the right answer when the scenario mentions scale, an existing IdP, or a requirement to avoid per-account credentials. The second most common trap is subtler: a scenario that describes cross-account access and offers a cross-account role as the answer. That is correct when the access is machine-to-machine or when the identity already exists in a trusted account, and incorrect when the scenario is about human users who need to authenticate. Read the scenario for whether the principal is a person or a workload.
Another gotcha is the assumption that Identity Center replaces IAM entirely. It does not. IAM roles, policies, and trust relationships still exist and still govern what the federated session can do. Identity Center is the delivery mechanism for the session; IAM is the authorization model the session operates under. A question that asks how to restrict what a federated user can do in a specific account is asking about the permission set's policies and any permissions boundary, not about Identity Center's configuration per se.
The management-account question is worth memorizing as a rule. Identity Center is enabled in the management account by default, and best practice is to delegate administration to a dedicated account so that routine identity work does not require management-account access. If a scenario asks where Identity Center should be administered in a mature organization, the answer is the delegated administrator account, not the management account. If a scenario asks where it is enabled by default, the answer is the management account. Both facts are testable and they are not contradictory.
Finally, be precise about what SCIM does and does not do. SCIM synchronizes users and groups from the IdP into Identity Center. It does not synchronize assignments — those are made in Identity Center, though they can be made to synchronized groups. A scenario that describes group membership changing in the IdP and access changing in AWS is describing SCIM plus group-based assignment, and the two halves are both required. A scenario that describes SCIM alone as the mechanism for granting access is missing the assignment step.
9. This Versus the Services It Gets Confused With
Identity Center is most often confused with three things: IAM users, cross-account roles, and Cognito. The first two are covered above in the decision-boundary section, but the comparison is worth restating as explicit rules because the exam tests the rules rather than the reasoning. Cognito is a different category entirely — it is a customer-facing identity service for applications you build, not a workforce identity service for your own employees. If the scenario is about end users of a mobile app, Cognito is in scope. If it is about employees accessing AWS accounts, it is not.
The comparison with Control Tower is also worth making explicit, because the two services are frequently mentioned together and serve different layers. Control Tower governs accounts and their guardrails; Identity Center governs the humans who access those accounts. Control Tower can provision the accounts and attach the SCPs, but it does not solve the identity problem, and Identity Center does not solve the account-structure problem. A mature landing zone uses both, and the exam will sometimes present a scenario where the correct answer requires recognizing that only one of the two is being asked about.
| Service | What it governs | Pick it when… | Do not pick it when… |
|---|---|---|---|
| IAM Identity Center | Workforce human access across accounts | Employees need SSO into many AWS accounts via a corporate IdP | The users are external customers of your application |
| IAM users | Per-account identities | A single account needs a break-glass or legacy identity with no IdP | The scenario mentions scale, an existing IdP, or avoiding long-lived credentials |
| Cross-account IAM roles | Machine or trusted-account access | A workload or a trusted account needs to assume a role in another account | The principal is a human who needs to authenticate |
| Amazon Cognito | Customer-facing application identity | You are building an app with sign-up and sign-in for end users | The users are your own employees accessing AWS |
| AWS Control Tower | Account structure and guardrails | You need automated multi-account provisioning and baseline policy | The question is specifically about how people log in |
The rule of thumb that resolves most of these: ask who the principal is and where their identity already lives. If the principal is an employee and their identity lives in a corporate directory, Identity Center with federation is the answer. If the principal is a workload, a cross-account role is the answer. If the principal is an external customer, Cognito is the answer. Most of the confusion in practice comes from scenarios that describe a human but use language that sounds like a workload, or vice versa, and the discipline of naming the principal explicitly before choosing a service is what makes the question tractable.
Hands-On Lab: Permission Sets Across Two Environments
The goal of this lab is to build the smallest configuration that demonstrates the full Identity Center model: a permission set defined once, assigned to a group, materialized as a role in a target account, and exercised through the portal. You will need an AWS Organization with at least two member accounts — one representing Production and one representing Dev — and administrative access to the management account or a delegated administrator. If you do not have an external IdP available, the built-in directory is sufficient for the mechanics; the federation-specific steps are called out separately.
Work through the steps in order and verify at each stage rather than at the end. The verification steps are where the learning is, because they show you what the service actually created rather than what the console claims it created.
- Enable IAM Identity Center in the organization. Note which account it lands in and confirm whether you are using the management account or a delegated administrator. Record the region, because the portal endpoint is regional and you will need it later.
- If you have an external IdP, configure it as a SAML 2.0 identity provider: exchange the metadata, set the audience URI to the Identity Center ACS URL, and map the NameID to a stable, unique attribute such as email or an immutable employee identifier. If you are using the built-in directory, create two test users instead and note that the federation steps do not apply.
- Enable SCIM provisioning from the IdP if you are federating, and create two groups in the IdP: one for engineers who need read-only Production access, and one for engineers who need power-user access in Dev. Confirm the groups appear in Identity Center after synchronization.
- Create a permission set named
ProductionReadOnly. Attach the AWS managedReadOnlyAccesspolicy. Set the session duration to one hour. Do not attach a permissions boundary yet — you will add one in a later step to see the effect. - Create a second permission set named
DevPowerUser. Attach the AWS managedPowerUserAccesspolicy. Set the session duration to four hours, and note in your lab notes why a longer duration is defensible in Dev but not in Production. - Assign
ProductionReadOnlyto the read-only group in the Production account. AssignDevPowerUserto the power-user group in the Dev account. Watch the provisioning status and record how long it takes for the assignment to move from pending to provisioned. - In the Production account, open the IAM console and find the role that Identity Center created. Inspect its trust policy and confirm it trusts the Identity Center service principal. Inspect its attached policies and confirm they match the permission set. This is the step that makes the abstraction concrete.
- Log in to the Identity Center portal as a user in the read-only group. Confirm you see only the Production account and only the read-only role. Assume it and run a read operation such as listing S3 buckets. Then attempt a write operation and confirm it is denied.
- Log in as a user in the power-user group and confirm the portal shows only the Dev account. This asymmetry — one user, one account, one role — is the property that makes the model auditable.
- Add a permissions boundary to
DevPowerUserthat denies IAM and Organizations actions. Re-assume the role and confirm that the previously permitted IAM actions are now denied even thoughPowerUserAccessstill allows them. This demonstrates the ceiling behavior that tomorrow's material covers in depth. - Remove a user from the read-only group in the IdP. Wait for synchronization and confirm the Production account disappears from their portal. Record the elapsed time — this is your organization's effective offboarding latency.
- Clean up: delete the assignments, delete the permission sets, and confirm the roles are removed from the target accounts. If any role remains, investigate why before deleting it manually.
The deliverable is a short written record of three numbers: the provisioning latency you observed for a new assignment, the SCIM synchronization latency you observed for a group change, and the session duration you chose for each permission set with a one-sentence justification. Those three numbers are the operational characteristics of your identity layer, and knowing them is what separates a configuration that works from one you can defend in an incident review.
Scenario Question Drills
Q1. An enterprise wants engineers to log in once via their corporate Okta and assume the correct role in any of 40 AWS accounts without individual IAM users. What is the best-practice solution?
Q2. A security team wants to know exactly what Identity Center creates in a target account when a permission set is assigned. What appears in that account?
Q3. An organization has 200 accounts and wants to grant a new class of access to 30 of them. What is the most maintainable way to do this?
Q4. Users report that after authenticating successfully at the corporate IdP they land on an error page instead of the AWS access portal. What is the first diagnostic step?
Q5. A departing employee was removed from all groups in the corporate IdP an hour ago, but an access review still shows them able to assume a Production role. What is the most likely explanation?
Q6. A scenario describes a workload running in Account A that needs to read an S3 bucket in Account B. Which mechanism is appropriate?
Q7. Where is IAM Identity Center enabled by default, and where should it be administered in a mature organization?
Q8. A team wants a federated user's session to expire after 30 minutes to limit exposure. What must they change?
Q9. What is the maximum session duration that can be configured on an Identity Center permission set?
Q10. An access review finds an IAM role in a member account that has no corresponding assignment in Identity Center, but the role still appears in IAM listings. What is this and what should be done?
Q11. What does SCIM synchronization actually do in an Identity Center deployment?
Q12. A company is building a consumer mobile app and needs sign-up, sign-in, and social login for its end users. Which service is appropriate?
Q13. A permission set has PowerUserAccess attached, but the organization wants to ensure the resulting role can never modify IAM or Organizations regardless of future policy changes. What should be configured?
Q14. An organization wants a synthetic check that exercises the entire login path — IdP, Identity Center, assignment, and role assumption — rather than monitoring each component separately. What is the most direct approach?
Q15. A new engineer is added to a group in the IdP, but when they open the access portal the target account is not listed. The assignment was created ten minutes ago. What is the most likely cause?
Peek Into Tomorrow
Today's model has a hole in it that is easy to miss until you try to delegate. Identity Center gives a user a role, and the role's policies determine what they can do — but nothing in that chain stops a sufficiently privileged user from creating a new role for themselves with broader permissions. If a delegated administrator can call iam:CreateRole and iam:AttachRolePolicy, they can escalate past whatever the permission set intended, and the permission set's policies are no defense because the escalation happens through a different role entirely.
We touched the edge of this when we attached a permissions boundary to a permission set in the lab, but we did not explain what a boundary actually is or why it is the standard answer to delegated-administration scenarios. Tomorrow's material covers permission boundaries as a ceiling on an IAM entity's maximum permissions, and the condition-based pattern that forces every role a delegate creates to carry one — which is the mechanism that makes delegation safe rather than merely convenient. It also covers STS directly: the AssumeRole call that Identity Center makes on the user's behalf, the AssumeRoleWithSAML variant that federation uses, and AssumeRoleWithWebIdentity, which is how Kubernetes workloads get AWS credentials without any long-lived secret at all. The question to hold onto is this: if the session is temporary and the role is the only durable object, what stops the role from being replaced by a broader one?
Sources
- AWS IAM Identity Center User Guide — What is IAM Identity Center?
- Permission sets — concepts and configuration
- IAM Identity Center quotas and limits
- SAML 2.0 federation with IAM Identity Center
- Automatic provisioning (SCIM) with IAM Identity Center
- Delegated administration for IAM Identity Center
- IAM policy evaluation logic
- AWS Well-Architected Framework — Security Pillar