What's changed: Service coverage: added a catalog section (s4) for governance/security/end-user services
1.2Cross-Account Access and Identity Federation
Understand secure access across accounts—cross-account IAM roles, IAM Identity Center (SSO), SAML/OIDC federation, and Resource Access Manager (RAM). Design org-wide access with least privilege.
Across accounts, role assumption (AssumeRole) and centralized identity are key. Avoid long-lived keys; use temporary credentials.
1.2.1Cross-account and federation
- Cross-account IAM role: assume another account’s role via sts:AssumeRole for temporary credentials; the trust policy defines who may assume it.
- IAM Identity Center (formerly AWS SSO): centralizes single sign-on and permission sets across accounts/apps.
- Federation: integrate a corporate IdP (SAML 2.0/OIDC) so existing identities access AWS.
- Resource Access Manager (RAM): shares resources like VPC subnets and Transit Gateways across accounts.
Common on SAP-C02: SSO for many accounts with existing corporate identities = IAM Identity Center, assume another account’s role = sts:AssumeRole + trust policy, resource sharing (subnets, etc.) = AWS RAM, external IdP = SAML/OIDC federation. Avoid distributing long-lived keys; use temporary credentials.
A cross-account role needs both a trust policy (who can assume) and a permissions policy (what they can do). Use an ExternalId condition for third parties to prevent the confused-deputy problem.
Org-wide access splits into “humans” and “workloads.” For humans, connect an external IdP to IAM Identity Center (SAML 2.0; user sync via SCIM), assign permission sets (job-function permission templates) to OUs/accounts, and SSO from the portal. For workloads/cross-account, assume an IAM role via sts:AssumeRole with both a trust policy (who may assume) and a permissions policy (what they can do). Don’t distribute long-lived keys—use temporary credentials, and let EC2/Lambda be credential-less via instance profiles/execution roles. For third parties (e.g., external SaaS), prevent the confused deputy with ExternalId, and scope to the org with an aws:PrincipalOrgID condition. For fine-grained delegation use permissions boundaries (a cap on grantable permissions) and ABAC (tag-based authorization). Share resources with AWS RAM (subnets, Transit Gateways, Route 53 Resolver rules, catalogs). Centralized identity (Identity Center) + temporary credentials (AssumeRole) + least privilege is the rule.
| Need | Use | Point |
|---|---|---|
| Human SSO (many accounts) | IAM Identity Center + permission sets | External IdP via SAML/SCIM |
| Access another account | Cross-account IAM role | AssumeRole + trust/permissions |
| Third-party assumption | ExternalId condition | Prevents confused deputy |
| Resource sharing | AWS RAM | Share subnets/TGW, etc. |
Scenario: safely give an external monitoring vendor read-only access to your account. → Create a cross-account IAM role, allow the vendor’s account in the trust policy with an ExternalId condition (prevents confused deputy), and scope the permissions policy to read-only. Hand over no long-lived keys; the vendor assumes the role for temporary credentials.
FAQ: Q. How to separate human vs workload access? → A. Humans use IAM Identity Center (SSO + permission sets); workloads/cross-account use IAM role AssumeRole. Both yield temporary credentials. Q. Why ExternalId? → A. A shared secret that prevents the confused-deputy attack when a third party assumes your role.
Trap: “hand over long-lived access keys for cross-account integration” is wrong—use AssumeRole + trust policy for temporary credentials. Also “create IAM users per account for human access across accounts” is wrong—centralize with IAM Identity Center.
1.2.2Section summary
- Cross-account = AssumeRole + trust policy (temporary credentials)
- Central identity = IAM Identity Center / external IdP = SAML/OIDC / sharing = RAM
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want employees to use existing corporate identities for SSO across multiple AWS accounts. What?
Q2. How should an app in account A access account B’s resources securely with temporary credentials?
Q3. You want to share VPC subnets created in a central network account with other member accounts. What?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.