Multi-Account Strategy and Federated Access

A multi-account strategy on AWS means you deliberately split workloads across more than one AWS account, then knit those accounts together with AWS Organizations, guardrails called service control policies (SCPs), automated landing zones from AWS Control Tower, centralized workforce sign-in via AWS IAM Identity Center, and cross-account access through IAM roles assumed with AWS STS. Multi-account federation is the SAA-C03 umbrella topic that ties all of these services together: it is how a real enterprise isolates blast radius, applies compliance guardrails at scale, lets employees sign in once to reach dozens of AWS accounts, and still honors least privilege everywhere.

On the SAA-C03 exam, multi-account federation sits squarely inside Task Statement 1.1 ("Design secure access to AWS resources"). You will be asked to distinguish IAM policies from service control policies, pick between IAM Identity Center and plain IAM users, recognize when to use SAML 2.0 or OIDC federation to a corporate identity provider, and match the right cross-account IAM role pattern to a scenario. This guide walks every multi-account federation construct in plain English, hits every common trap, and pins down the numbers you will need on exam day.

What is Multi-Account Strategy on AWS?

Multi-account strategy is the AWS-recommended practice of running workloads in many isolated AWS accounts instead of cramming every environment, team, and compliance boundary into one. Each AWS account is a hard security and billing boundary — an IAM policy, resource, or API call inside account A cannot by default reach account B. Multi-account federation is the tooling AWS provides to make that separation practical: AWS Organizations groups accounts into a hierarchy, SCPs apply preventive guardrails across those accounts, AWS Control Tower automates the landing zone, IAM Identity Center provides single sign-on across accounts, and cross-account IAM roles plus AWS RAM let accounts share access and resources safely when they need to cooperate.

The mental shift for SAA-C03 is from "one AWS account with many IAM users" to "many AWS accounts with federated identities, SCP guardrails, and short-term role credentials." Almost every real SAA-C03 scenario that mentions "an enterprise with multiple business units", "production vs non-production isolation", "central security team", or "workforce sign-in" is pointing you toward the multi-account federation model.

Why multi-account federation matters for SAA-C03

Task 1.1 is the highest-weighted security task on the SAA-C03 blueprint, and multi-account federation is the area where AWS-style answers diverge the most from naïve answers. A candidate who only knows single-account IAM will pick "create IAM users in every account" when the right answer is "federate through IAM Identity Center". Multi-account federation also intersects with cost (Task 4.2 via Savings Plans sharing across accounts), networking (Task 3.4 via Transit Gateway sharing), and resilience (Task 2.2 via isolated production accounts). Getting multi-account federation right lifts your scores across multiple domains, not just security.

Plain-Language Explanation: Multi-Account Federation — Plain-Language Analogies

Multi-account federation is abstract. Three concrete analogies make it stick.

Analogy 1: The Corporate Office Park

Picture a single company that owns an office park of many buildings. Each building is one AWS account: finance in Building 1, engineering in Building 2, marketing in Building 3, production workloads in Building 4, development sandboxes in Building 5. Because finance and production each sit in their own building, a fire in the sandbox cannot burn the ledger. That is the blast-radius isolation multi-account strategy gives you.

The office park HQ is AWS Organizations. HQ keeps a master roster of every building, collects rent centrally (consolidated billing), and can issue park-wide rules called service control policies — for example, "no building may allow smoking". SCPs are the rules posted at HQ; every building must honor them, and no individual tenant inside a building can override them.

AWS Control Tower is the general contractor that hands you a brand-new building pre-wired with electricity, alarms, sprinklers, and a standardized layout — you don't have to lay foundations by hand for every new AWS account. IAM Identity Center is the shared lobby reception — one badge-swipe at the main gate and a friendly guide escorts you to whichever buildings you are cleared for, no re-badging. A cross-account IAM role is a visitor lanyard at a specific building's front desk: Engineering needs to pop over to Finance for one task, borrows the lanyard (calls sts:AssumeRole), does the task, gives it back. AWS RAM is the shared gym and parking garage — buildings share infrastructure without each one having to build its own.

Analogy 2: A Hotel Chain Loyalty Program

A global hotel chain captures workforce federation perfectly. Each individual hotel is an AWS account. The chain's head office is AWS Organizations. The loyalty program is IAM Identity Center — you sign up once, get a single loyalty profile, and then check in at any of the 200 properties with the same credentials, without opening a new guest account at each hotel. When you arrive, the front desk gives you a room keycard (an IAM role materialized by IAM Identity Center as a permission set) that expires at checkout.

Federating to an external SAML 2.0 or OIDC identity provider (Microsoft Entra ID, Okta, Ping, Google Workspace) is like using your driver's license at the hotel — the hotel chain trusts the state DMV's identity assertion, verifies the license, then issues you a room keycard. Your hotel keycard (short-term AWS STS credentials) expires; your driver's license (your corporate identity) keeps on living at the DMV. This is why federation avoids long-term AWS credentials: the long-lived identity stays at the corporate IdP, and AWS only ever sees a temporary assertion exchanged for temporary credentials.

Analogy 3: A School District with Many Schools

Think of a public school district. The district office is AWS Organizations; each school is an AWS account. The district office can impose district-wide rules (no tobacco, mandatory fire drills) — those are SCPs attached to the root or an OU. Individual schools can tighten rules further for their own students (that's local IAM policy inside a member account), but they can never loosen a district rule. If the district says "no social media on school Wi-Fi", no individual teacher's IAM policy can re-grant it.

AWS Control Tower is the district's standard blueprint for opening a new school: pre-built classrooms, AV kits, fire safety, grade book software. You press "create a new school" in the account factory and get a compliant landing zone, not an empty lot. IAM Identity Center is the district-wide staff ID card — one card opens the doors at whichever schools the teacher is assigned to teach at, and it expires at the end of every school day so a lost card isn't catastrophic. Cross-account roles are substitute-teacher passes — a teacher from School A drops into School B for one afternoon (calls sts:AssumeRole), gets a temporary pass, teaches the class, and leaves no persistent access behind.

AWS Organizations — OUs, Management Account, and Member Accounts

AWS Organizations is the backbone of multi-account federation. It groups many AWS accounts into one tree, consolidates billing, and applies SCPs.

The Organization tree

An AWS Organization has exactly one root. Under the root you create organizational units (OUs); inside OUs you place AWS accounts. OUs can be nested up to 5 levels deep under the root. A typical SAA-C03-friendly structure looks like this:

• Root
  • Security OU (Log archive account, Audit/security tooling account)
  • Infrastructure OU (Shared networking account, Shared services account)
  • Workloads OU
    • Production OU (Prod app accounts)
    • Non-production OU (Dev, Test, Staging accounts)
  • Sandbox OU (Individual developer sandbox accounts)

Management account vs member accounts

The management account (sometimes still called "payer" or "master" in older docs) is the account that created the organization. It pays the consolidated bill and is the only account that can administer AWS Organizations — creating OUs, attaching SCPs, inviting or creating member accounts. Member accounts are every other account in the organization. Critically, SCPs do not apply to the management account's root user, which is one reason AWS recommends you run no workloads in the management account and treat it as a thin administrative-only account.

Consolidated billing

Every account in an organization rolls up to one monthly bill. Volume discounts (Savings Plans, Reserved Instances, tiered data transfer pricing) apply across the whole organization, which is a huge cost-optimization lever. On SAA-C03 you will see scenarios where "sharing Savings Plans across business units" is the clue that points to consolidated billing under AWS Organizations.

Service Control Policies (SCPs) — Guardrails vs IAM Permissions

SCPs are the most-tested AWS Organizations feature on SAA-C03. Get the mental model right and several exam traps disappear.

How SCPs work

An SCP is a JSON policy in the same format as an IAM policy, but it is attached to an AWS Organizations entity — the root, an OU, or a specific AWS account. SCPs define the maximum set of permissions any IAM principal (IAM user, IAM role, even the account's root user for member accounts) in that scope is allowed to exercise. SCPs never grant permissions by themselves — they only cap what IAM policies can grant. For an API call to succeed, it must be allowed by both the applicable IAM policy and every applicable SCP from root down to the account.

The SCP inheritance model is intersect-down: the effective maximum permissions of an account equal the intersection of the root SCP, every intermediate OU's SCPs, and the SCPs attached directly to the account. Adding a restrictive SCP up the tree always takes effect immediately on every account below.

SCP vs IAM policy — the canonical trap

The trap shows up like this: "An IAM policy attached to a user grants s3:DeleteBucket, but when the user tries to delete the bucket they get an explicit-deny error. Why?" The correct answer is that an SCP at the OU or account level denies s3:DeleteBucket. The IAM policy's grant is silently capped by the SCP.

The reverse is also true and often missed: an SCP that allows s3:DeleteBucket does not grant the permission by itself. Without a matching IAM policy in the member account, the user still cannot delete the bucket.

SCP examples you will see

Common SCP patterns that pop up in SAA-C03 scenarios:

• Region restriction: deny every action whose aws:RequestedRegion is not in an allow-list — used to force workloads into approved regions only.
• Service deny-list: deny every iam:*CreateUser and iam:*AccessKey* API to force the entire org onto IAM Identity Center instead of IAM users.
• Data-perimeter SCP: deny s3:PutBucketPublicAccessBlock removal, or deny any unencrypted S3 PutObject.
• Compliance-oriented SCP: deny cloudtrail:StopLogging so no member account can disable CloudTrail.

SCP types: allow-list vs deny-list

By default a new organization has one SCP attached at the root: FullAWSAccess, an allow-list that permits everything. From there, you either add deny-list SCPs (preferred for most orgs, because deny is explicit) or switch the root SCP to an allow-list of only the services you permit (higher effort, tighter default posture). Deny-list is the usual SAA-C03 answer when a scenario says "block a specific action across all accounts".

AWS Control Tower — Landing Zone Automation and Guardrails

AWS Control Tower is a higher-level AWS service that sits on top of AWS Organizations and automates the creation of a compliant, multi-account landing zone.

What Control Tower sets up

When you enable Control Tower it creates:

• An AWS Organizations organization (if you don't already have one).
• A Security OU with a log archive account (centralized CloudTrail + Config S3 logs) and an audit/security tooling account (centralized security dashboards, cross-account read access).
• A Sandbox OU for developer accounts.
• AWS IAM Identity Center pre-configured for workforce sign-in.
• An Account Factory — a self-service portal (backed by AWS Service Catalog) to vend new AWS accounts with standard guardrails pre-applied.
• A set of guardrails: preventive guardrails implemented as SCPs, plus detective guardrails implemented as AWS Config rules. Guardrails are labeled Mandatory (always on, such as "disallow public write access to S3 buckets"), Strongly Recommended, or Elective.

Control Tower vs raw AWS Organizations

Raw AWS Organizations gives you primitives — OUs, SCPs, accounts, consolidated billing — and leaves the landing-zone design up to you. Control Tower is an opinionated, automated deployment of those primitives, plus pre-built guardrails and an account factory. For the SAA-C03 exam, if a scenario mentions "landing zone", "automated multi-account setup", "account factory", or "guardrails" together, the answer is AWS Control Tower, not "design it yourself with Organizations and SCPs".

IAM Identity Center (SSO) — Workforce Federation Across Accounts

AWS IAM Identity Center is the workforce single-sign-on service for multi-account AWS environments. AWS recommends it over creating IAM users per account, and SAA-C03 consistently expects it as the answer for workforce access scenarios.

What IAM Identity Center provides

• A user portal where each employee logs in once and sees tiles for every AWS account and SaaS app they are entitled to.
• Federation with an external identity provider via SAML 2.0 or OIDC — common integrations are Microsoft Entra ID, Okta, Ping, Google Workspace, and on-premises Active Directory via AWS Directory Service. Alternatively, IAM Identity Center can run as its own directory for organizations without an existing IdP.
• Permission sets — reusable templates (managed policies, inline policies, permissions boundaries) that IAM Identity Center materializes as IAM roles in target AWS accounts on demand.
• Account assignment — you map a user or a group to a permission set in a specific AWS account. The first time a user exercises that assignment, IAM Identity Center creates the underlying IAM role in the target account automatically.
• Short-term credentials for AWS CLI v2 via aws sso login, so engineers never store long-term access keys on their laptops.
• Attribute-based access control (ABAC) via SAML attributes or SCIM-provisioned user attributes that get passed as session tags.

Federation flow with IAM Identity Center

The user experience in SAA-C03 scenarios is:

1. Employee opens the IAM Identity Center portal URL.
2. IAM Identity Center redirects to the corporate IdP (SAML 2.0 or OIDC).
3. Employee authenticates at the IdP (with MFA).
4. IdP returns a SAML assertion (or OIDC token) to IAM Identity Center.
5. IAM Identity Center shows the portal of all AWS accounts the user can enter.
6. User clicks an account tile and a permission set; IAM Identity Center calls AWS STS to assume the underlying IAM role in that member account and hands the user a short-term session in the AWS Management Console or AWS CLI.

SAML 2.0 and OIDC Federation — Connecting a Corporate IdP to AWS

Under the hood of IAM Identity Center and many direct integrations is the standard federation plumbing: SAML 2.0 and OIDC. SAA-C03 expects you to recognize both.

SAML 2.0 federation

SAML 2.0 is the enterprise federation standard. Microsoft Entra ID, Active Directory Federation Services (AD FS), Okta, Ping, and on-premises Shibboleth installations all speak SAML.

For direct SAML-to-IAM federation (without IAM Identity Center in the middle), the setup is:

1. Create a SAML 2.0 identity provider object in AWS IAM, uploading the IdP's metadata XML.
2. Create one or more IAM roles whose trust policy trusts that SAML provider and optionally filters on SAML attributes (saml:aud, user attributes).
3. Configure the IdP to include an AWS role attribute in the SAML assertion — a string that identifies the IAM role ARN and SAML provider ARN.
4. At sign-in, the IdP returns the SAML assertion to the AWS sign-in endpoint.
5. AWS STS exchanges the assertion via sts:AssumeRoleWithSAML and returns short-term credentials tied to the selected IAM role.

OIDC (web identity) federation

OIDC (OpenID Connect) is the modern, OAuth 2.0-based federation standard. Google, Apple, Facebook, Amazon, GitHub Actions, and Kubernetes service accounts all speak OIDC.

Direct OIDC-to-IAM federation works like SAML but uses sts:AssumeRoleWithWebIdentity and an OIDC provider object in IAM. The two most-tested OIDC patterns on SAA-C03 are:

• Amazon EKS IRSA (IAM Roles for Service Accounts) — a Kubernetes pod's service account is federated to an IAM role via the cluster's OIDC issuer.
• GitHub Actions / CI systems — a workflow swaps a short-lived GitHub OIDC token for an IAM role's credentials, removing the need for long-term IAM access keys in secrets.

When to federate directly vs via IAM Identity Center

Federate directly to IAM when you have a single AWS account or a narrow service-to-service pattern (EKS IRSA, GitHub Actions). Federate via IAM Identity Center when you have multiple AWS accounts and human workforce users — it wraps the SAML/OIDC plumbing, manages permission sets across accounts, and provides the portal UX.

Cognito User Pools vs Identity Pools — Auth vs Federation Boundary

Amazon Cognito is where workforce federation and customer-app federation diverge. The SAA-C03 exam loves this distinction.

Cognito User Pools — authentication

A Cognito user pool is a managed user directory for your application's end users. It handles sign-up, sign-in, password reset, MFA, account recovery, and optionally social/SAML sign-in. The output of a user pool is a JWT token (ID token, access token) that your app uses to authenticate API Gateway or AppSync calls. A user pool is about authentication — "who is this user?".

Cognito Identity Pools — federation to AWS credentials

A Cognito identity pool takes a token from any supported identity source — a Cognito user pool, a SAML IdP, an OIDC IdP, Google/Apple/Facebook/Amazon — and exchanges it for short-term AWS credentials tied to an IAM role. An identity pool is about federation to AWS — "what IAM role does this authenticated user assume so they can call AWS APIs directly?"

Typical SAA-C03 pattern: a mobile app lets users log in with Google, then uploads photos directly to Amazon S3 and writes metadata directly to Amazon DynamoDB. The app signs in via a Cognito user pool (or uses Google directly as an OIDC IdP), then exchanges the token at a Cognito identity pool for short-term AWS credentials scoped to an IAM role that allows s3:PutObject on the user's own prefix and dynamodb:PutItem on their own items.

Cross-Account Role Switching — The Switch-Role Pattern

The classic cross-account pattern predates IAM Identity Center and is still on SAA-C03. A user (or AWS service) in account A needs access to resources in account B.

How cross-account role assumption works

1. In account B, create an IAM role with the permissions the task needs (for example, read-only access to an S3 bucket).
2. Attach a trust policy to that role whose Principal names account A (either the whole account, or a specific IAM user or role inside it). The trust policy is a resource-based policy on the IAM role itself.
3. In account A, give the calling IAM principal (IAM user, IAM role, or IAM Identity Center permission set) an IAM policy that allows sts:AssumeRole on the role ARN in account B.
4. The principal in account A calls sts:AssumeRole and receives short-term credentials — access key ID, secret access key, session token — valid for up to 12 hours.
5. Using those credentials, the principal calls AWS APIs in account B as if they were a principal in account B.

ExternalId for third-party access

When a third party (for example, a SaaS security vendor) needs to assume a role in your AWS account, AWS recommends the trust policy require an ExternalId — a shared secret that the caller must pass to sts:AssumeRole. This mitigates the confused deputy problem, where another customer of the same SaaS could trick the SaaS into assuming the wrong customer's role.

Switch-role in the AWS Management Console

The console has a built-in Switch Role UI. An IAM Identity Center user or IAM user can switch to a role in another AWS account by providing the target account ID and role name. The console stores the last five roles in history for quick re-entry. On the CLI, engineers usually put the cross-account role into a profile in ~/.aws/config and use aws --profile prod.

IAM Identity Center vs manual cross-account roles

For workforce access across many accounts, IAM Identity Center is the modern replacement — it manages cross-account roles as permission sets under the hood. For service-to-service or partner-to-you access, the manual cross-account role pattern is still the answer.

AWS Resource Access Manager (RAM) — Sharing Resources Across Accounts

Some resources don't need role-based cross-account access — they need to be shared so that multiple AWS accounts use the exact same resource. AWS Resource Access Manager (AWS RAM) is the service for that.

What RAM shares

AWS RAM can share a growing list of AWS resources with other AWS accounts or with an entire OU inside your AWS Organizations:

• VPC subnets — a central networking account owns a VPC, and workload accounts launch EC2 instances, Lambda ENIs, or RDS into shared subnets.
• AWS Transit Gateway — attach many VPCs from many AWS accounts to one shared Transit Gateway.
• AWS License Manager configurations.
• Route 53 Resolver rules and Outposts.
• Amazon Aurora clusters for cross-account reads.
• Many more — the list grows over time.

RAM vs cross-account IAM role vs VPC peering

The distinction is easy to miss. Three patterns, three different tools:

• Cross-account IAM role — principal in account A calls AWS APIs in account B, resources stay in B.
• AWS RAM — a resource owned by account A is shared into account B so account B uses it natively, no role assumption needed.
• VPC peering / Transit Gateway — two VPCs get network connectivity. Peering is for two VPCs; Transit Gateway is the hub for many VPCs across many accounts and often shared through RAM.

On SAA-C03, a classic scenario is: "A central networking team wants to own the VPC and let other business-unit accounts launch workloads inside the same VPC's subnets. What should they use?" The answer is AWS RAM sharing the subnets, not cross-account roles and not VPC peering.

When to Federate vs When to Use IAM Users

SAA-C03 routinely asks you to pick the right identity construct for a scenario. Use this decision framework:

• Workforce (employees, contractors) across one or more AWS accounts → IAM Identity Center, federated to the corporate IdP. Never create IAM users per employee in production.
• Application-level end users of your SaaS product → Amazon Cognito user pool (and an identity pool if they need to call AWS APIs directly).
• AWS service assuming an identity (EC2 to S3, Lambda to DynamoDB, ECS task to SQS) → IAM role attached to the service (instance profile, execution role, task role). Never long-term access keys on an EC2 instance.
• Cross-account access between your AWS accounts → cross-account IAM role assumed via sts:AssumeRole. Consider IAM Identity Center permission sets if this is a workforce use case.
• Third party / SaaS partner accessing your AWS account → cross-account IAM role with ExternalId in the trust policy.
• CI/CD pipeline (GitHub Actions, GitLab CI) → OIDC federation to an IAM role via sts:AssumeRoleWithWebIdentity. No long-term access keys in CI secrets.
• On-premises server that cannot assume a role → IAM Roles Anywhere (issues short-term credentials based on X.509 certificates) is preferred; IAM user access keys are a last resort.

Creating long-term IAM users should be rare in a modern AWS environment. Most SAA-C03 "correct" answers avoid IAM users whenever an alternative exists.

Multi-Account vs Single Account — Design Trade-offs

SAA-C03 sometimes asks you to justify or oppose a multi-account design. Know the trade-offs:

Advantages of multi-account

• Hard security boundary — a compromise in one account cannot by default reach resources in another.
• Blast-radius isolation — a runaway Lambda, a recursive S3 loop, or a billing spike in account A does not affect account B.
• Service-quota isolation — every AWS account has its own service quotas; multi-account lets you scale past per-account limits.
• Per-account cost attribution — each business unit sees its own AWS bill, tagging is simpler, chargeback is trivial.
• Compliance partitioning — PCI workloads in a PCI-scoped account, HIPAA in a HIPAA-scoped account, development in sandbox accounts.
• SCP-driven compliance — preventive guardrails enforced org-wide.

Costs and complexity of multi-account

• More setup overhead — you need AWS Organizations, Control Tower, IAM Identity Center, a networking strategy (Transit Gateway + RAM), and a logging strategy.
• Cross-account networking — workloads in different accounts often need to talk, which means VPC peering, Transit Gateway, or PrivateLink.
• Cross-account data sharing — S3 bucket policies, KMS key policies, and resource-based policies all need to be set up for cross-account access.
• Higher minimum operational cost — at very small scale, a single-account architecture is simpler. Multi-account pays off once you have multiple teams, environments, or compliance boundaries.

For SAA-C03, the right answer is almost always multi-account once the scenario mentions "business units", "production isolation", "compliance", or "central security team".

Key Numbers to Memorize for Multi-Account Federation

Expect one or two questions on these. Internalize them.

Common Exam Traps — Multi-Account Federation

Trap 1: SCP vs IAM policy

"An IAM policy grants s3:*; why can't the user delete the bucket?" Because an SCP higher up in AWS Organizations denies s3:DeleteBucket. Remember, SCPs never grant — they cap. An SCP that allows an action does not by itself grant permission.

Trap 2: IAM Identity Center vs IAM user per account

If the scenario says "employees need to sign in to multiple AWS accounts", the answer is IAM Identity Center, not "create IAM users in every account and share them". Creating IAM users per account is a classic wrong answer on SAA-C03.

Trap 3: Cognito user pool vs identity pool

User pool = authentication of end users. Identity pool = federation to short-term AWS credentials. The trap is scenarios that say "mobile app users upload to S3 directly" — you need both, or a user pool + identity pool wired together (or an identity pool directly federating Google/Apple/Facebook).

Trap 4: SAML vs OIDC

SAML 2.0 = enterprise workforce IdPs (Entra ID, ADFS, Okta, Ping). OIDC = modern app/CI/Kubernetes federation (Google, Apple, Amazon Cognito user pools, GitHub Actions, EKS IRSA). If the scenario says "corporate workforce SSO", it's SAML (often via IAM Identity Center). If it says "mobile social sign-in" or "GitHub Actions CI", it's OIDC.

Trap 5: Management account workloads

If a scenario has workloads running in the organization's management account, that is a bad-practice setup — the management account should be thin. The SAA-C03 answer often involves "move the workload to a dedicated member account" and/or "apply SCPs to the workload's OU".

Trap 6: Cross-account role needs both sides

A cross-account IAM role assumption fails unless the trust policy in the target account names the caller as a trusted principal and the caller's IAM policy allows sts:AssumeRole on the target role ARN. Missing either side breaks the pattern.

Trap 7: RAM vs cross-account role vs VPC peering

Sharing an AWS resource (subnet, Transit Gateway) into another account is AWS RAM, not cross-account role and not VPC peering. Recognizing RAM is a common SAA-C03 differentiator.

Trap 8: AWS Control Tower vs raw AWS Organizations

If the scenario says "automated landing zone", "account factory", or "pre-built guardrails", the answer is AWS Control Tower. If it only mentions "group accounts into OUs and apply SCPs", raw AWS Organizations is sufficient.

Multi-Account Federation vs Single-Account IAM — Scope Boundary

Multi-account federation and single-account IAM identity management (the sibling topic) overlap but have distinct scopes. Single-account IAM (topic: iam-identity-access-control) is about IAM users, IAM roles, IAM policies, and policy evaluation inside one AWS account — the low-level primitives. Multi-account federation (this topic) is about how you stitch many of those accounts together — AWS Organizations, SCPs, Control Tower, IAM Identity Center, cross-account roles, RAM. Task 1.1 expects you to understand both, and SAA-C03 questions often require you to combine them (for example, "use IAM Identity Center and an SCP to restrict developer access to non-production accounts only").

Practice Question Links — Multi-Account Federation Scenarios

• "A company has 20 AWS accounts and wants employees to sign in once and access all accounts with least privilege. Which service?" → AWS IAM Identity Center federated to the corporate SAML 2.0 identity provider.
• "A central security team wants to prevent any AWS account in the organization from disabling AWS CloudTrail. What should they use?" → Service Control Policy attached at the root or the appropriate OU, denying cloudtrail:StopLogging and cloudtrail:DeleteTrail.
• "A company wants to automate creation of new AWS accounts with standard guardrails and a centralized logging account. Which service?" → AWS Control Tower with its Account Factory and Mandatory guardrails.
• "A central networking account owns a VPC and wants several business-unit accounts to launch EC2 into the same subnets. What should they use?" → AWS Resource Access Manager (AWS RAM) sharing the VPC subnets with the target AWS accounts.
• "A third-party SaaS vendor needs read-only access to a customer's AWS account. What's the most secure pattern?" → Cross-account IAM role in the customer account with the vendor's AWS account as the trusted principal, plus an ExternalId condition in the trust policy.
• "GitHub Actions needs to deploy to AWS without long-term access keys. What should be configured?" → OIDC identity provider in IAM pointing to GitHub's issuer, plus an IAM role assumed via sts:AssumeRoleWithWebIdentity.
• "A mobile app authenticates users with Google and needs to upload photos directly to Amazon S3. Which services?" → Amazon Cognito identity pool federated to Google (or to a Cognito user pool that federates to Google), exchanging tokens for short-term IAM role credentials scoped to the user's own S3 prefix.

FAQ — Multi-Account and Federated Access Top Questions

Q1: What's the difference between AWS Organizations and AWS Control Tower?

AWS Organizations provides the raw primitives: a root, OUs, member accounts, consolidated billing, and SCPs. AWS Control Tower is an opinionated, automated layer on top of AWS Organizations that deploys a complete multi-account landing zone — security and audit accounts, centralized CloudTrail and Config logging, IAM Identity Center, and pre-built guardrails (Mandatory, Strongly Recommended, Elective) implemented as SCPs and AWS Config rules. Use AWS Organizations when you want to hand-craft the structure; use AWS Control Tower when you want a compliant landing zone in an afternoon. On SAA-C03, "automated landing zone" and "account factory" almost always point to AWS Control Tower.

Q2: How does an SCP differ from an IAM policy?

An SCP is an AWS Organizations policy attached to the root, an OU, or an account, and it defines the maximum permissions any principal in that scope is allowed to exercise. An IAM policy attached to an IAM user, group, or role inside a member account grants permissions. For an API call to succeed, both must allow the action — SCP at every level from root to account, plus IAM policy in the member account. SCPs never grant; they cap. IAM policies grant (or explicitly deny). A common exam trap is "I attached an SCP to give the dev team admin access" — wrong; SCPs can't grant.

Q3: When should I use IAM Identity Center instead of SAML federation directly to IAM?

For multi-account workforce access, always prefer IAM Identity Center. It wraps the SAML/OIDC federation plumbing and adds permission sets, an account portal, cross-account provisioning of IAM roles, and AWS CLI v2 integration. Direct SAML-to-IAM federation (with a SAML provider object in IAM and manually configured IAM roles) is still valid for narrow single-account use cases or legacy setups. On SAA-C03, if the scenario says "multiple AWS accounts" and "workforce sign-in", IAM Identity Center is the answer.

Q4: What's the right way to give a CI/CD pipeline (GitHub Actions) permission to deploy to AWS?

Configure an OIDC identity provider in AWS IAM pointing at GitHub's issuer (https://token.actions.githubusercontent.com). Create an IAM role whose trust policy trusts that OIDC provider, filtered by sub claim to only the specific GitHub repository and branch. In the GitHub Actions workflow, use aws-actions/configure-aws-credentials to call sts:AssumeRoleWithWebIdentity, which exchanges the short-lived GitHub OIDC token for short-term AWS credentials. No long-term access keys are ever stored in GitHub secrets. This same pattern applies to GitLab CI, CircleCI, and other OIDC-compatible CI systems.

Q5: What's a cross-account IAM role and how does sts:AssumeRole work?

A cross-account IAM role is an IAM role in AWS account B whose trust policy names an entity in account A (the whole account, or a specific user or role) as a trusted principal. The caller in account A must have an IAM policy that allows sts:AssumeRole on that role's ARN. When the caller invokes sts:AssumeRole, AWS STS returns short-term credentials (access key ID, secret access key, session token) valid for up to 12 hours. The caller then uses those credentials to call AWS APIs in account B. This is the standard pattern for cross-account access when the caller isn't human workforce (for workforce, use IAM Identity Center permission sets instead).

Q6: What does AWS RAM do that cross-account IAM roles can't?

AWS Resource Access Manager shares specific AWS resources (VPC subnets, Transit Gateway attachments, License Manager configurations, Route 53 Resolver rules, Aurora clusters, and more) across AWS accounts. The shared resource physically stays owned by one AWS account, but other accounts can consume it natively — launch EC2 into a shared subnet, attach a VPC to a shared Transit Gateway — without needing to assume a cross-account role for every API call. Cross-account IAM roles are about letting a principal perform API actions in another account; AWS RAM is about letting another account consume a shared resource as if it were local.

Q7: Should I run any workloads in the AWS Organizations management account?

No, AWS best practice is to keep the management account empty of workloads. The management account is the only account that can administer AWS Organizations (create OUs, attach SCPs, invite members) and its root user is not meaningfully restricted by SCPs. Running workloads there means any compromise could reach the entire organization's guardrails. Use the management account only for AWS Organizations administration and consolidated billing, and deploy workloads to dedicated member accounts inside appropriate OUs (Workloads/Production, Workloads/Non-production, Sandbox, etc.).

Q8: How do I restrict AWS workloads to specific AWS regions across all accounts?

Attach an SCP at the root of AWS Organizations (or at an OU) that denies every action whose aws:RequestedRegion is not in an allow-list. For example, deny everything unless the region is us-east-1 or eu-west-1. Because SCPs cap IAM policy grants, no member account can launch or operate workloads in disallowed regions, no matter how permissive their IAM policies are. Exempt global services (IAM, CloudFront, AWS Organizations itself) in the SCP condition, since they don't have a regional context. This is a common SAA-C03 answer to "how do we keep the whole organization in approved regions for data sovereignty?".

Q9: What's the difference between Amazon Cognito User Pools and Identity Pools?

Cognito user pools are a managed user directory for your application — sign-up, sign-in, password reset, MFA, optional social and SAML federation. A user pool's output is a JWT token your app uses for authentication. Cognito identity pools take any supported token (from a user pool, a SAML IdP, Google, Apple, Facebook, Amazon) and exchange it for short-term AWS credentials tied to an IAM role, so authenticated users can call AWS APIs like S3 and DynamoDB directly. User pool = authentication; identity pool = federation to AWS credentials. Many mobile-app scenarios need both: a user pool for sign-in and an identity pool to get AWS credentials.

Further Reading

• AWS Organizations User Guide
• Service Control Policies (SCPs)
• AWS Control Tower User Guide
• AWS IAM Identity Center User Guide
• SAML 2.0 Federation with IAM
• OIDC Federation with IAM
• AWS STS AssumeRole API
• AWS STS AssumeRoleWithSAML API
• Cross-Account Access Using IAM Roles
• AWS Resource Access Manager (RAM) User Guide
• Amazon Cognito User Pools vs Identity Pools
• AWS SAA-C03 Exam Guide (PDF)