On the SAP-C02 exam, “who can do what, in which account” is a design problem, not an IAM-user problem. The Design Solutions for Organizational Complexity domain is full of scenarios where a company has dozens of accounts, thousands of employees, an existing corporate directory, and partners who need scoped access — and the wrong answer is always “create IAM users in each account.” Long-lived IAM users and their access keys don’t scale, don’t centralize, and become an audit nightmare. The exam wants you to reach for federation and centralized access instead: identities live in one authoritative source, and AWS hands out short-lived credentials on demand.
This guide covers the identity and access patterns SAP-C02 tests most often — IAM Identity Center, SAML/OIDC federation, and cross-account roles — and how to tell them apart in a scenario question. If you want the broader exam picture first, start with the AWS Solutions Architect Professional guide for 2026 and sequence your prep with the SAP-C02 study plan. This piece pairs naturally with the multi-account architecture guide, which covers the account and Organizations structure that identity sits on top of.
Two Kinds of Identity: Workforce vs Workload
Before choosing a service, classify the identity in the scenario. The exam almost always signals which one it wants.
- Workforce identities are humans — employees, contractors, partners — who need to sign in to AWS accounts or applications. They typically already exist in a corporate directory (Active Directory, Okta, Entra ID) and should keep signing in there.
- Workload identities are machines — an EC2 instance, a Lambda function, an on-premises server, a container — that need AWS credentials to call APIs. These should never carry static keys; they assume roles.
The right answer depends on which one you’re dealing with. Workforce → IAM Identity Center or SAML federation. Workload → IAM roles (instance profiles, IRSA, IAM Roles Anywhere). Getting this classification right eliminates half the distractor answers immediately.
The Foundation: sts:AssumeRole and Temporary Credentials
Every federation and cross-account pattern in AWS is built on one primitive: AWS STS issuing temporary credentials when a trusted principal assumes a role. An IAM role has two halves:
- A trust policy (who is allowed to assume it) — this is the
AssumeRolePolicyDocument. - A permissions policy (what the role can do once assumed).
// Trust policy on a role in the Workload (target) account,
// allowing a specific role in the Management account to assume it
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:role/CentralAdmin" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "sts:ExternalId": "acme-partner-9d1f" }
}
}]
}When the principal calls sts:AssumeRole, STS returns an access key, secret key, and session token that expire (default one hour, up to twelve). Nothing long-lived is minted. Every design below is a variation on “who is trusted to assume which role, and what does that role allow.”
The External ID (a favourite exam detail)
When you grant a third party (a SaaS vendor, an MSP) the ability to assume a role in your account, you add an external ID condition to the trust policy, and the third party must supply that value on every AssumeRole call. This defeats the confused deputy problem — where a multi-tenant vendor could be tricked into using its own credentials to act against the wrong customer’s account. If a scenario mentions granting a third-party vendor cross-account access, the external ID is almost certainly part of the correct answer.
IAM Identity Center: Centralized Workforce Access
AWS IAM Identity Center (formerly AWS SSO) is the exam’s default answer for giving humans access across many accounts in an AWS Organization. It sits at the organization level and solves the “one login, many accounts” problem cleanly.
The building blocks:
- Identity source — where users and groups come from. Options: the built-in Identity Center directory, an external IdP via SAML/SCIM (Okta, Entra ID, Ping), or AWS Managed Microsoft AD.
- Permission sets — reusable collections of IAM policies that define what a user can do. A permission set becomes an IAM role provisioned into each assigned account.
- Assignments — the mapping of group → permission set → account(s).
The elegance is in how these compose. You assign the group Developers the PowerUserAccess permission set across the Dev and Staging accounts, and Identity Center provisions the matching roles everywhere automatically. Users get a single access portal, pick an account and role, and receive short-lived credentials — no IAM users, no per-account setup.
Corporate IdP (Okta / Entra ID / AD)
│ SAML sign-in + SCIM user/group sync
▼
IAM Identity Center (org-level)
├─ Permission set: AdminAccess → assigned to Platform group → Prod account
├─ Permission set: PowerUser → assigned to Devs group → Dev, Staging
└─ Permission set: ReadOnly → assigned to Auditors group → ALL accounts
│ provisions IAM roles into each target account
▼
Short-lived credentials per session (no IAM users)When the exam wants Identity Center: multiple AWS accounts under Organizations, human users, a desire to centralize access and avoid per-account IAM users, and often an existing corporate directory to connect. It replaces the older pattern of building your own SAML federation into each account by hand.
SAML 2.0 and OIDC Federation
Sometimes the scenario predates or sits outside Identity Center — a single account, a custom application, or a requirement to federate directly. Two standards matter.
SAML 2.0 Federation
SAML 2.0 federates an enterprise IdP (ADFS, Okta, Entra ID) directly to IAM. You create a SAML identity provider in IAM and IAM roles whose trust policy trusts that provider. Users authenticate at the corporate IdP, receive a SAML assertion, and exchange it via sts:AssumeRoleWithSAML for temporary credentials. The assertion’s attributes (like group membership) map to which roles the user may assume.
Use SAML when: an enterprise workforce with an existing SAML IdP needs access, and either you’re not using Identity Center or you’re federating into a specific application/account directly.
OIDC and Web Identity Federation
OIDC (OpenID Connect) federation trusts an OIDC provider and exchanges its tokens via sts:AssumeRoleWithWebIdentity. Two big exam contexts:
- Application/consumer identity — a mobile or web app where end users sign in with Google, Apple, or a custom OIDC provider. For consumer-scale apps, Amazon Cognito identity pools are the managed answer, brokering OIDC logins into scoped temporary AWS credentials.
- Workload federation without static keys — GitHub Actions, Kubernetes service accounts (IRSA on EKS), and other CI/CD or compute systems present an OIDC token and assume a role. This eliminates long-lived access keys in pipelines, a pattern the exam increasingly rewards.
| Mechanism | STS call | Best for |
|---|---|---|
| IAM Identity Center | (managed) | Workforce access across many org accounts |
| SAML 2.0 federation | AssumeRoleWithSAML | Enterprise IdP → IAM roles, direct federation |
| OIDC / web identity | AssumeRoleWithWebIdentity | Consumer app logins (via Cognito), CI/CD & workload federation |
| Cross-account role | AssumeRole | One AWS account/principal accessing another |
| IAM Roles Anywhere | (X.509 → STS) | On-prem servers getting AWS creds via certificates |
Integrating an Existing Active Directory
Many SAP-C02 scenarios include an on-premises Active Directory the company refuses to abandon. You have three integration paths, and the exam distinguishes them:
- AWS Managed Microsoft AD — a fully managed AD in AWS. Establish a trust relationship with on-prem AD so users authenticate against their existing directory while AWS-side resources (RDS for SQL Server, WorkSpaces, EC2 domain joins) use the managed directory. Best when you need real AD features in AWS.
- AD Connector — a proxy that redirects directory requests to your on-prem AD without caching or replicating. No directory lives in AWS; it’s a pass-through. Best when you want to use existing on-prem AD for AWS access (including as an Identity Center source) without running a directory in the cloud.
- Simple AD — a small, standalone Samba-based directory for basic needs and no on-prem dependency. Rarely the “professional” answer.
The decision hinges on whether you need AD replicated/managed in AWS (Managed Microsoft AD), just proxied (AD Connector), or a lightweight standalone directory (Simple AD).
Attribute-Based Access Control (ABAC)
For large, fast-changing organizations, ABAC scales better than creating a role per team. Instead of enumerating roles, you tag principals and resources and write policies that grant access when tags match — for example, allow a user to manage only resources tagged with their own project. Identity Center and SAML can pass identity attributes (department, project) as session tags, and IAM policies use aws:PrincipalTag and aws:ResourceTag conditions to make decisions:
{
"Effect": "Allow",
"Action": "ec2:StartInstances",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/project": "${aws:PrincipalTag/project}"
}
}
}When a scenario describes hundreds of teams or projects and a desire to avoid an explosion of roles/policies, ABAC with session tags is the design the exam is fishing for.
Guardrails: SCPs Bound the Whole Thing
Federation controls who gets in and as what. Service Control Policies (SCPs) in AWS Organizations set the maximum permissions any principal in an account can ever have — including Identity Center roles and cross-account roles. Even an admin permission set cannot exceed what the account’s SCPs allow. On the exam, remember the layering: SCP (org boundary) → permission set / role permissions → session policy. The effective permission is the intersection. SCPs are covered in depth in the multi-account architecture guide; here it’s enough to know they cap everything federation grants.
Reading the Scenario: A Decision Guide
The exam rarely asks “what is IAM Identity Center.” It gives a situation and asks for the best design. Map the signal to the pattern:
| Scenario signal | Correct pattern |
|---|---|
| Many org accounts + employees + “centralize access, no IAM users” | IAM Identity Center with permission sets |
| Existing corporate SAML IdP, federate into AWS | SAML 2.0 federation (or Identity Center using the IdP as source) |
| Mobile/web app, end users sign in with Google/Apple | Cognito identity pools (OIDC/web identity) |
| CI/CD pipeline needs AWS access without static keys | OIDC federation → AssumeRoleWithWebIdentity |
| Third-party vendor needs access to your account | Cross-account role + external ID |
| On-prem servers need AWS credentials, no keys | IAM Roles Anywhere (X.509 certificates) |
| On-prem AD must remain source of truth | AD Connector or Managed Microsoft AD trust |
| Hundreds of teams, avoid role explosion | ABAC with session tags |
Common Mistakes on This Domain
| Mistake | Why it’s wrong |
|---|---|
| Creating IAM users per account | Doesn’t scale, no central control, long-lived keys to rotate and audit |
| Using access keys for EC2/Lambda | Workloads should assume roles; keys are a leak risk |
| Omitting the external ID for third-party access | Leaves you open to the confused-deputy attack |
| Confusing AD Connector with Managed Microsoft AD | Connector proxies; Managed AD is a real directory in AWS |
| Forgetting SCPs cap federated access | Even admin permission sets are bounded by the SCP intersection |
| Building custom per-account SAML when Organizations is in play | Identity Center centralizes this with far less effort |
Practising the Scenarios
Reading these patterns is one thing; recognising them under exam pressure — with four plausible-looking answers and a 75-minute-per-half clock — is another. SAP-C02 questions are long, layered, and designed so two answers are technically workable but only one is best. The skill is elimination: classify the identity, spot the signal word (external ID, existing directory, many accounts), and match it to the pattern.
That timed pattern-recognition is exactly what the AWS Solutions Architect Professional (SAP-C02) Mock Exam Bundle is built to drill. It puts you through realistic, scenario-length questions with detailed explanations, so you practise separating the best answer from the merely-correct one across identity, multi-account, and migration domains. Pair it with the security & compliance scenarios guide for the adjacent controls, and the tips for passing SAP-C02 on the first attempt to sharpen exam technique.
Frequently Asked Questions
When should I use IAM Identity Center vs SAML federation on the SAP-C02 exam?
Use IAM Identity Center when the scenario involves multiple accounts under AWS Organizations and wants centralized human access without per-account IAM users — it provisions permission sets as roles across accounts automatically. Use direct SAML 2.0 federation when you’re federating an enterprise IdP into a specific account or application, or when Organizations/Identity Center isn’t in play. Note that Identity Center can itself use an external SAML IdP as its identity source, combining both.
What is the external ID and when do I need it?
The external ID is a shared secret placed in a role’s trust policy Condition that a third party must supply on every sts:AssumeRole call. It prevents the confused-deputy problem, where a multi-tenant vendor could be induced to act against the wrong customer’s account. Any scenario granting a third-party SaaS or MSP cross-account access should include an external ID.
What is the difference between AD Connector and AWS Managed Microsoft AD?
AD Connector is a proxy that forwards directory requests to your existing on-premises Active Directory without storing or replicating any directory data in AWS — good for using on-prem AD as an AWS access source. AWS Managed Microsoft AD is a real, fully managed Active Directory running in AWS that can form a trust with on-prem AD and supports AD-dependent AWS services like RDS for SQL Server, WorkSpaces, and EC2 domain joins.
How do workloads get AWS access without long-lived keys?
They assume roles. EC2 uses instance profiles, EKS pods use IAM Roles for Service Accounts (IRSA) via OIDC, CI/CD systems like GitHub Actions federate through OIDC with AssumeRoleWithWebIdentity, and on-premises servers can use IAM Roles Anywhere with X.509 certificates. All of these yield short-lived STS credentials instead of static access keys.
Do SCPs affect federated and cross-account access?
Yes. Service Control Policies set the maximum permissions available to any principal in an account, including IAM Identity Center permission sets and assumed cross-account roles. The effective permission is the intersection of the SCP boundary, the role/permission-set policy, and any session policy — so an admin permission set can still be blocked by a restrictive SCP.
Is ABAC or role-per-team better for large organizations?
For organizations with many teams or projects that change frequently, attribute-based access control (ABAC) scales better. Instead of creating a distinct role and policy per team, you tag principals (often via session tags passed from the IdP) and resources, then write policies that grant access when aws:PrincipalTag matches aws:ResourceTag. This keeps the number of policies small and lets access follow tags automatically.