SAA-C03
Deep Dive
IAM is the most important security pillar in SAA-C03. 30% of the exam (D1) revolves around controlling access correctly. You need to understand how permissions are evaluated, when to use roles vs users, and how SCPs limit an entire account.
Contents
AWS IAM (Identity and Access Management) controls who can authenticate to AWS and what they can do once authenticated. It is global — it doesn't belong to any region.
Fundamental exam principle: least privilege — grant only the permissions strictly necessary for an identity to do its job.
Permission evaluation (priority order)
Explicit Deny
If a Deny exists in ANY policy, access is denied. It always wins.
SCPs (Organizations)
If the account is in an OU with an SCP, the SCP caps the maximum that IAM can allow.
Resource-based policies
Policies on the resource itself (S3 bucket policy, SQS queue policy).
Identity-based policies
Policies attached to a user, group or role.
Permission Boundaries
The maximum limit of what permissions an identity can receive.
IAM Users
A permanent identity with long-lived credentials (password + access keys).
When to use
Human users accessing the console. Avoid for applications.
Exam trap
Exposed access keys = long-lived credentials. Higher risk.
IAM Groups
A collection of IAM users. Policies attached to the group apply to all its members.
When to use
Organize users by function (Developers, Admins, Ops) and assign permissions in bulk.
Exam trap
Groups CANNOT be members of other groups. No nesting.
IAM Roles
A temporary identity that services, applications or accounts can assume. No permanent credentials.
When to use
EC2, Lambda, ECS. Also for cross-account access or identity federation.
Exam trap
ALWAYS prefer roles over access keys for AWS services. That is the correct answer.
Policies are JSON documents that define permissions. Each statement contains: Effect (Allow/Deny), Action (e.g. s3:GetObject), Resource (resource ARN), and optionally Condition.
AWS Managed Policies
Created and maintained by AWS. E.g.: AdministratorAccess, ReadOnlyAccess. Cannot be modified.
Customer Managed Policies
Created by you. Reusable across multiple identities. Versioned — you can roll back changes.
Inline Policies
Embedded directly in an identity (1:1). Deleted along with the identity. Avoid — hard to audit.
Resource-based Policies
Attached to the resource (S3 bucket policy, SQS policy). Allow cross-account access without assuming a role.
JSON structure of a policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::my-bucket/*",
"Condition": {
"StringEquals": {"aws:RequestedRegion": "us-east-1"}
}
}
]
}AWS Organizations lets you manage multiple AWS accounts from a master account. Service Control Policies (SCPs) are applied to OUs and accounts to limit the maximum possible permissions.
SCPs — what they are and what they are NOT
They do not grant permissions — they only limit them (they are the maximum ceiling)
They do not affect the root user of the member account
They do not replace IAM Policies in the account
They define the MAXIMUM limit of possible permissions for an account
They cascade: parent OU → child OU → member accounts
For an action to be possible, it must be allowed by the SCP AND by IAM
A Permission Boundary is a policy attached to a user or role that defines the maximum permissions that entity can have, regardless of the policies assigned to it.
How it works — permission intersection: the effective permission is the intersection between what the Identity Policy allows and what the Permission Boundary allows.
Main use case
Delegating administration with safe limits. E.g.: allowing developers to create IAM roles for their Lambda functions, but with a boundary that prevents those roles from having more permissions than the developer themselves.
IAM Identity Center (SSO)
Centralized SSO access management with IAM Identity Center for multiple AWS Organizations accounts and SaaS applications.
When to use
For organizations with multiple accounts. Replaces manual per-account user management.
Cognito User Pools
A user directory for web/mobile applications. Supports OAuth 2.0, OIDC, SAML.
When to use
B2C applications with external users. Handles sign-up, login, MFA for end users.
Cognito Identity Pools
Delivers temporary AWS credentials to authenticated users (from a User Pool or another IdP).
When to use
Mobile applications that need direct access to AWS services (S3, DynamoDB).
Use roles, not access keys
EC2, Lambda, ECS, EKS: always attach an IAM Role to the service. Access keys in code = an architecture mistake on the exam.
Explicit Deny always wins
A Deny in any policy (Identity, Resource, SCP) overrides all Allows. It doesn't matter how many policies grant Allow.
SCPs limit, they don't grant
Even if the SCP allows s3:*, if the user doesn't have an IAM policy with that permission, they can't access it. SCP is the ceiling, IAM is the floor.
IAM is global
Users, groups, roles and policies exist at the account level, not the region level. A role created in us-east-1 can be used in eu-west-1.
Prefer Customer Managed Policies
They are reusable, versioned and easier to audit than Inline Policies. AWS Managed policies are fine but cannot be customized.
Visualize how AWS evaluates each API request step by step.
Did you get this topic?
Test what you just learned
A company has AWS Organizations with several accounts. The security team applies an SCP to the production OU that denies ec2:TerminateInstances. A developer in that OU has an IAM policy with Allow on ec2:*. Can they terminate EC2 instances?
Put what you learned to the test with original SAA-C03 exam questions.
Start SAA-C03 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.