I’ve been studying for the AWS Solutions Architect Associate (SAA-C03) exam, and I’m honestly excited to finally sit for it. It’s been a while since I started preparing, but I’m getting the vibes now and fully locked in.

Since I learn better when I write things down, I figured I’d turn my notes into blog posts. Forces me to actually make sense of what I’ve read instead of just skimming. If it helps someone else along the way, even better.

The SAA-C03 has four domains, and Domain 1: Design Secure Architectures is the biggest one — it makes up 30% of the exam. That’s nearly a third of your score riding on identity, access control, encryption, networking, and security services. So yeah, this one matters.

There’s a lot to cover, so I’m splitting Domain 1 into three parts:

  1. Identity & Access Management (this post)
  2. Security Services & Auditing (Part 2)
  3. Data Protection & Networking (Part 3)

Let’s start with the foundation — who gets in, and what are they allowed to do.

IAM — The Gatekeeper#

IAM (Identity and Access Management) is a global service. That’s important — users, groups, roles, and policies you create in IAM are available across all AWS regions. You don’t create them per-region.

Here’s the core model:

  • Root account — created by default when you set up your AWS account. Has full access to everything. You should only use this for initial setup, then lock it away.
  • IAM users — individual identities with specific permissions. One physical person = one IAM user. Never share credentials.
  • IAM groups — collections of users. Groups make permission management easier. Important: groups can only contain users — not other groups, not roles.
  • IAM policies — JSON documents that define what actions are allowed or denied on which resources.
  • IAM roles — temporary credentials meant for AWS services, not for people.

A user doesn’t have to belong to a group, and a user can belong to multiple groups. Permissions from all sources (user-level, group memberships) are unioned together — but here’s the critical evaluation logic:

  1. By default, everything is denied (implicit deny)
  2. An explicit Allow overrides the implicit deny
  3. An explicit Deny always wins — it overrides any Allow, no matter what

This three-step logic shows up constantly in exam questions. If you remember nothing else about IAM policies, remember that an explicit Deny is king.

Policy Types#

  • AWS Managed — pre-built by AWS (AdministratorAccess, ReadOnlyAccess). Convenient, but you can’t customize them.
  • Customer Managed — policies you create yourself. Reusable across users, groups, and roles.
  • Inline — embedded directly in a single user, group, or role. Not reusable, deleted when the entity is deleted. Use sparingly.

MFA and Access Methods#

Multi-Factor Authentication (MFA) adds a second verification step beyond just a password. AWS strongly recommends enabling it on the root account and all IAM users.

MFA device options:

  • Virtual MFA device — apps like Google Authenticator, Microsoft Authenticator, or Authy
  • U2F Security Key — hardware keys like YubiKey
  • Hardware MFA device — physical token devices (key fob or display card)

MFA is configured per-user — you can’t assign it to a group.

There are three ways to access AWS resources:

Method Authentication
AWS Console (web UI) Password + MFA
AWS CLI Access keys or SSO
AWS SDK (code) Access keys, SSO, or IAM Roles

Access keys have two parts: an Access Key ID (like a username) and a Secret Access Key (like a password). The Secret Access Key is only shown once at creation — if you lose it, you generate a new key pair. Never embed access keys in code, never commit ~/.aws/credentials to Git.

AWS CloudShell is worth knowing about — it’s a web-based shell in the AWS Console that comes pre-authenticated with your current session. Free to use, includes Python, Node.js, git, and 1 GB of persistent storage. Handy for quick tasks without setting up local credentials.

IAM Roles — Temporary Trust#

AWS services need permissions to act on your behalf. You don’t give them access keys — that would be a security risk. Instead, you create an IAM Role and assign it to the service.

When a service assumes a role, it gets temporary credentials scoped to that role’s permissions. Common examples:

  • An EC2 instance assuming a role to read from S3
  • A Lambda function assuming a role to write to DynamoDB
  • CloudFormation assuming a role to create and manage resources

The flow is straightforward: create a role with the right permissions, attach it to the service (via an Instance Profile for EC2), and the service can now access resources without any stored credentials.

Permission Boundaries#

This is an advanced feature that sets the maximum permissions an IAM entity can have. Think of it as a ceiling — even if a user has AdministratorAccess attached, a permission boundary can restrict them to only S3 actions.

The effective permissions are the intersection of the identity-based policy AND the permission boundary. Both must allow the action for it to work.

Use case: you want to let a developer create IAM users, but you don’t want them to create users with more permissions than they have. Permission boundaries solve this.

STS — Borrowing Credentials#

Security Token Service (STS) generates temporary security credentials — an access key ID, a secret access key, and a session token. These credentials expire automatically (configurable from 15 minutes to 12 hours), so there’s no need to rotate them manually.

The most important STS API is AssumeRole. It lets a user or service temporarily assume an IAM Role and receive its permissions.

Same-account use case: a developer assumes an admin role for a specific task, then goes back to their normal permissions.

Cross-account access pattern — this one comes up a lot in exam questions:

  1. Account A creates a role with a trust policy that allows Account B to assume it
  2. Account B’s user calls sts:AssumeRole with the role’s ARN
  3. STS returns temporary credentials scoped to Account A’s role
  4. The user now has access to Account A’s resources using those temp credentials

STS also supports federation:

  • SAML 2.0 Federation — enterprise users authenticate through their corporate IdP (Active Directory, Okta) and receive temporary AWS credentials
  • Web Identity Federation — app users authenticate with a social provider (Google, Facebook) and exchange the token for AWS credentials. AWS recommends using Cognito for this rather than calling STS directly.

Amazon Cognito — Auth for Apps#

Cognito handles authentication and authorization for your web and mobile applications. It has two main components, and understanding the difference is key.

User Pools = authentication (“who are you?”)

  • A user directory for your app — handles sign-up, sign-in, and account recovery
  • Returns JWT tokens after successful authentication
  • Supports MFA, email/phone verification, password policies
  • Social sign-in with Google, Facebook, Apple, or Amazon accounts
  • SAML/OIDC federation for enterprise identity providers
  • Comes with a built-in hosted UI, or you can build your own

Identity Pools = authorization (“what can you do?”)

  • Also called Federated Identities
  • Provides temporary AWS credentials so app users can access AWS services directly (S3, DynamoDB)
  • Maps authenticated users to IAM roles
  • Supports unauthenticated (guest) access with a separate, limited IAM role

They’re often used together: User Pool authenticates the user and produces a JWT, then Identity Pool exchanges that JWT for AWS credentials so the user can access backend resources.

If an exam question mentions “mobile app authentication”, “social login”, or “user sign-up/sign-in” — think Cognito.

IAM Identity Center — One Login to Rule Them All#

IAM Identity Center (formerly AWS SSO) is the modern recommended approach for managing human access to AWS. Instead of creating IAM users in every account and juggling access keys, you get one login for all your AWS accounts and business applications.

Key features:

  • Integrates with external identity providers (Okta, Azure AD) via SAML 2.0, or use AWS’s built-in identity store
  • Uses Permission Sets to define what users can do in each account — these map to IAM policies behind the scenes
  • Integrates with AWS Organizations to manage access across all accounts in the org
  • Replaces long-lived access keys for human users

If a question mentions “single sign-on” or “centralized access to multiple accounts” — the answer is IAM Identity Center.

AWS Organizations & SCPs#

When you have multiple AWS accounts (and most real-world setups do), AWS Organizations lets you manage them centrally.

  • Management Account — the account that creates the organization. Full control, only one per org.
  • Member Accounts — all other accounts. Each can only belong to one organization.
  • Organizational Units (OUs) — logical groupings of accounts (Dev, Prod, Finance). OUs can be nested.
  • Consolidated Billing — all member usage bills to the management account. Aggregated usage unlocks volume discounts.

Service Control Policies (SCPs)#

This is where it gets interesting. SCPs are guardrails that set the maximum permissions for all users and roles in an account — including the root user of that account.

Key rules:

  • SCPs don’t grant permissions — they only restrict what’s allowed. You still need IAM policies to actually grant access.
  • Applied to OUs or individual accounts
  • The management account is never affected by SCPs
  • SCPs follow inheritance: if a parent OU denies an action, no child OU or account can allow it

Example: you can attach an SCP to the Dev OU that prevents anyone from launching expensive EC2 instance types or deleting CloudTrail logs. Even if someone in a Dev account has AdministratorAccess, the SCP blocks it.

AWS Control Tower#

Control Tower automates the setup of a multi-account environment following AWS best practices. It creates a landing zone with pre-configured OUs, accounts, and guardrails. It uses both preventive guardrails (SCPs) and detective guardrails (AWS Config rules), and provides a dashboard to monitor compliance across all accounts.

RAM — Sharing Without Duplicating#

Resource Access Manager (RAM) lets you share AWS resources across accounts without creating duplicates. The resource stays in the owner’s account — single source of truth.

How it works: the resource owner creates a resource share in RAM and specifies which accounts or OUs can access it. The receiving account sees the resource in their console and can use it as if it were their own.

Shareable resources include:

  • VPC Subnets — multiple accounts can launch resources into the same VPC
  • Transit Gateway — centralized networking across accounts
  • Route 53 Resolver Rules — shared DNS rules
  • License Manager Configurations — shared software license configs
  • Aurora DB Clusters, AWS Outposts, and more

RAM itself has no additional cost — you only pay for the resources being shared. It works with AWS Organizations (share with an entire OU) or with specific account IDs.

Quick Exam Tips#

A few patterns I’ve noticed while studying this section:

  • “Temporary credentials” → STS AssumeRole
  • “Cross-account access” → STS with trust policy, or RAM for resource sharing
  • “Mobile app sign-in” or “social login” → Cognito User Pools
  • “App needs to access S3/DynamoDB” → Cognito Identity Pools (for app users) or IAM Roles (for services)
  • “Single sign-on across accounts” → IAM Identity Center
  • “Restrict what accounts can do” → SCPs (remember: restrict, not grant)
  • “Share VPC subnets across accounts” → RAM
  • “Explicit Deny” → always wins, no exceptions
  • “Permission boundary” → maximum permissions (intersection, not union)
  • “Management account” → exempt from SCPs

The identity and access side of Domain 1 turned out to be denser than I expected. There’s a lot of overlap between services — STS, Cognito, and Identity Center all deal with some form of “give someone temporary access” — but they each solve it at a different level. STS is the low-level mechanism, Cognito is for app users, and Identity Center is for workforce access. Once that clicked, the rest fell into place.

Next up: Guarding the Cloud: Security Services & Auditing, where I’ll cover WAF, Shield, GuardDuty, Inspector, Macie, and the IAM tools that help you audit everything we set up here.