Why IAM dominates Domain 1

Almost every SAA-C03 scenario starts with who can do what on which resource. AWS Identity and Access Management (IAM) is the control plane for that decision. Your job as architect is to default to least privilege, use roles instead of long-lived keys, and layer organization guardrails when you have many accounts.

Core building blocks

Users, groups, roles, policies

• IAM users — long-lived identities for humans or apps. Prefer roles and Identity Center for people; avoid access keys on users when possible.
• IAM groups — collection of users for shared permissions (e.g. BillingReadOnly).
• IAM roles — temporary credentials via STS. Used by EC2 instance profiles, Lambda, cross-account access, and federated login.
• Policies — JSON documents. Identity-based attach to users/groups/roles. Resource-based attach to S3 buckets, KMS keys, SNS topics, etc.

Policy evaluation (exam favorite)

1. Explicit deny always wins.
2. Organization SCP can limit max permissions (never grants).
3. Identity policy + resource policy + session policy intersect; all must allow.
4. Permission boundaries cap what an identity can receive.

Remember: an allow in one policy does not help if another applicable policy denies.

Least privilege in practice

• Start with AWS managed policies for baselines, then tighten with customer managed policies.
• Use IAM Access Analyzer to find resources shared externally.
• Enable MFA for console users; require MFA for sensitive API calls via condition keys (aws:MultiFactorAuthPresent).
• Rotate or eliminate access keys; use roles for workloads.

Federation and SSO

• SAML 2.0 / OIDC federation — users authenticate with corporate IdP; AWS trusts assertion and maps to IAM roles via trust policy.
• IAM Identity Center (successor to SSO) — centralized multi-account access, permission sets, and application assignments.
• Cross-account roles — Principal in trust policy names the foreign account; ExternalId mitigates confused deputy.

AWS Organizations

• Organization root → OUs → member accounts.
• Service Control Policies (SCPs) — guardrails (e.g. deny ec2:StopInstances in prod OU, deny non-approved regions).
• SCPs do not grant permissions; they filter what identity policies can allow.

Exam traps

Quick checklist

• Human access → Identity Center or federated role, MFA on.
• Machine access → IAM role + instance profile / IRSA / Lambda execution role.
• Cross-account → role trust + ExternalId + least-privilege policy.
• Multi-account governance → Organizations + SCPs + centralized logging account.

Official reference

Exam guide Domain 1 task statements on secure access — AWS SAA-C03 exam guide.