Design Secure Architectures
Identity, Federation, and Multi-Account Authorization
CoreChoose principals, federation, roles, policy layers, SCP guardrails, and multi-account access patterns.
Aligned to the current SAA-C03 exam guide, verified August 16, 2026.
Why this matters
An architect must put each access decision at the correct trust and policy layer. The winning design gives people and workloads temporary, least-privilege access across the required accounts while keeping guardrails separate from permissions that actually grant access.
Must Know
- Start with the principal: workforce user, application user, AWS workload, AWS service, or external account. That identity and its trust boundary determine the access mechanism.
- Protect the root user for break-glass tasks, require MFA, avoid root access keys, and use administrative roles for routine work.
- Prefer temporary credentials from roles and federation. IAM users and long-term keys are a last resort when roles cannot be used.
- A role trust policy controls who may assume the role; its permissions control what the resulting session may do. Both sides must allow the intended path.
- Identity policies govern principals; resource policies govern supported resources and are often decisive across accounts. SCPs cap member-account permissions but never grant them.
- IAM Identity Center centralizes workforce assignments; Organizations supplies accounts, OUs, and SCPs; Control Tower establishes and governs an opinionated landing zone.
Compare and Distinguish
- IAM user vs role: a user is a persistent IAM identity; a role wins for workloads, federation, cross-account access, and temporary privilege.
- Cognito vs Identity Center vs IAM roles: Cognito serves customer/application end users; Identity Center serves workforce access to AWS accounts and business applications; roles give AWS workloads, services, and cross-account sessions temporary authorization.
- Identity vs resource policy: choose a principal-side grant when governing a principal broadly; choose a supported resource policy when the owner must name who can use that resource.
- Cross-account role vs resource policy: assume a role to operate as a target-account principal; use a resource policy when the caller should retain its identity while accessing one resource.
- SCP vs permissions boundary vs identity policy: SCPs cap accounts/OUs, boundaries cap principals, and identity policies contribute grants. A cap never grants access.
- Organizations vs Control Tower vs Identity Center: account hierarchy and SCPs, landing-zone governance, and workforce assignments are separate jobs.
Scenario examples
- Scenario: Employees need one portal and assigned access to many accounts. Think: workforce principal plus temporary multi-account sessions points to IAM Identity Center.
- Scenario: An EC2 workload reads an S3 bucket in another account. Think: decide whether it should assume a target role or be named in the bucket policy based on the desired operating identity.
- Scenario: Security must prevent member accounts from disabling controls. Think: apply an SCP maximum, while retaining workload permission policies.
Exam traps
- An SCP never grants permission, even when it contains Allow.
- A role trust policy does not authorize resource access by itself.
- Accounts in one organization do not automatically trust each other.
- An explicit deny in any applicable policy layer can defeat otherwise valid allows.
Key takeaways
- Choose identity mechanics from the principal, account boundary, and access lifetime.
- Prefer federation and roles to long-term credentials.
- Keep grants, resource trust, and organization guardrails conceptually separate.
- Combine centralized workforce assignments, account roles, and SCPs for multi-account access.
How it works
- A person federates from an identity source into an assigned role session.
- A workload receives credentials from its execution, task, node, or instance role.
- For cross-account role access, the target trusts the source and the source may request the session.
- Organizations evaluates SCP guardrails around member-account authorization.
When to use it
- Use Identity Center for centralized workforce access across accounts.
- Use roles for workloads, federation, services, and cross-account delegation.
- Use resource policies when a supported resource must define trusted principals.
- Use Control Tower for governed landing-zone workflows and Organizations for the underlying hierarchy.
Security and governance implications
- Require MFA and tightly restrict root and privileged access.
- Keep long-term credentials out of code, images, and user data.
- Use accounts and OUs as ownership/security boundaries, then scope guardrails carefully.
- Record access activity and review unused or broad permissions.
Operational and diagnostic signals
- For denied access, identify the actual principal, then inspect trust, grants, resource policy, boundaries, SCPs, and explicit denies.
- For wrong federated access, inspect identity-source mapping and account assignments before creating IAM users.
- For cross-account differences, compare target trust and organization guardrails before broadening permissions.
More detail
- Authorization can include identity and resource policies, session policies, permissions boundaries, SCPs, and explicit denies; the request context decides which apply.
- Under shared responsibility, AWS secures the IAM service while customers configure identities, trust, permissions, credentials, and monitoring.
- Least privilege is iterative: scope required actions and resources, observe legitimate use, and reduce broad permissions.
Ready for the quiz?
- Why does a workload role reduce risk compared with an IAM user's access keys?
- What must agree for cross-account role assumption?
- When does a resource policy fit better than a role?
- Why can an SCP block but never authorize?
- How do Organizations, Control Tower, and Identity Center divide responsibility?
Related objectives
- D1.1.K1
- D1.1.K2
- D1.1.K3
- D1.1.K4
- D1.1.K5
- D1.1.S1
- D1.1.S2
- D1.1.S3
- D1.1.S4
- D1.1.S5
- D1.1.S6