Security makes up roughly 30% of the SAA-C03 exam. The first challenge is designing "who can access what." If you think of IAM as just a user management tool, you will get exam questions wrong. IAM is the security backbone of all of AWS.
What Is IAM?
Think of a company building security system. To enter the building, you need an ID badge. Each badge has different access rules — "lobby and cafeteria OK, server room on the 3rd floor off limits." AWS IAM works exactly this way.
IAM (Identity and Access Management) controls access to AWS resources. It answers the question: "Can this person (or service) perform this action on this resource?"
IAM has four main components:
User: Represents one real human. Like a personal ID badge. Group: A department-style grouping of users. Give permissions to the "Dev Team" group and every member inherits them. Role: A temporary badge issued to services or applications, not to people. When an EC2 instance needs to access S3, it uses a role. Policy: A JSON document containing the actual permission rules. For example, "allow reading S3 buckets."
Four Types of IAM Policies
Policies differ based on what they are attached to.
Identity-based policies are attached directly to users, groups, or roles. "This employee can read S3" — you are granting permission to the identity.
Resource-based policies are attached to the resource itself. An S3 bucket policy is the classic example. "Only users from this specific account can access this bucket" — the rule lives on the resource.
Permission Boundaries cap the maximum permissions an identity can ever have. Even if someone grants a user full admin, a permission boundary can limit what that user can actually do.
SCPs (Service Control Policies) are master rules applied at the organizational level. They apply to all accounts under an AWS Organizations OU. If an SCP blocks an action, no IAM policy in that account can override it.
!4 types of IAM policies
Policy Evaluation Logic — How AWS Decides
When an access request arrives, AWS evaluates it in this order:
Step 1: If there is an explicit Deny anywhere, access is immediately blocked. No Allow can override a Deny.
Step 2: If there is an explicit Allow, access is granted.
Step 3: If neither is found, the default is Implicit Deny. AWS blocks everything by default.
Key rule: Explicit Deny always wins over any Allow, no exceptions.
Multi-Account Management — AWS Organizations
Large enterprises run multiple AWS accounts — development, production, security, finance. AWS Organizations lets you manage all of them as a single organization.
An OU (Organizational Unit) groups accounts like departments. You might have a "Dev OU" and a "Prod OU" with different rules.
SCPs applied to an OU set the maximum permissions for every account in that group. For example: "accounts in the Dev OU can never delete production databases" — no matter what IAM policies say.
AWS Control Tower builds on Organizations to automatically set up a multi-account environment following AWS best practices. It enforces guardrails (mandatory and recommended rules) to maintain governance across the whole organization.
Cross-Account Access — STS AssumeRole
Imagine a Lambda function in Account A needs to read an S3 bucket in Account B. You solve this with cross-account roles and STS (Security Token Service).
The process works like this:
Step 1: In Account B (where the S3 bucket lives), create an IAM role. In its trust policy, specify "Account A is allowed to assume this role."
Step 2: The Lambda in Account A calls STS AssumeRole and receives temporary credentials (valid 15 minutes to 36 hours).
Step 3: Use those temporary credentials to access Account B's S3 bucket.
Temporary credentials expire automatically, making this far safer than sharing long-term access keys.
Federation — Connecting External Login Systems
It is tedious for employees to log into the AWS console separately from their company accounts. If they already have an Active Directory account, they should be able to use it for AWS too. This is federation.
IAM Identity Center (formerly AWS SSO) provides single sign-on across multiple AWS accounts. It integrates with external identity providers like Microsoft Active Directory and Google Workspace.
Amazon Cognito handles user authentication for mobile and web apps. User Pools manage user sign-up and login. Identity Pools grant authenticated users access to AWS resources.
Exam Key Points
"Least privilege principle" — the foundation of all access design; allow only what is needed
"Block a specific service in member accounts" — SCP (even if IAM allows it, SCP overrides)
"Both SCP and IAM must allow for access to work" — policy intersection evaluation
"Access resources in another account" — cross-account role + STS AssumeRole
"SSO across multiple AWS accounts" — IAM Identity Center
"User authentication for mobile/web apps" — Amazon Cognito
"EC2 needs to access S3" — IAM role via instance profile; never hardcode access keys
"Cap the maximum permissions for an IAM user" — Permission Boundary
Explicit Deny always wins over any Allow, no exceptions