AWS IAM for the SAA-C03 Exam: Policies, Roles, and Best Practices

AWS Identity and Access Management (IAM) is the security foundation of every AWS architecture. On the SAA-C03 exam, IAM concepts appear in the Design Secure Architectures domain, which carries the highest weight at 30 percent. Beyond that domain, IAM questions are woven into scenarios across resilience, performance, and cost optimization. If you cannot answer IAM questions confidently, passing the SAA-C03 becomes extremely difficult.

This guide covers every IAM concept tested on the exam, from the fundamentals of users and groups to advanced topics like identity federation, permission boundaries, and service control policies. Each section explains the concept, its exam relevance, and common scenarios you will encounter.

For a structured study approach, combine this guide with our SAA-C03 study plan and exam topics overview.

IAM Fundamentals

Users

An IAM user represents a person or application that interacts with AWS. Each user has a unique name within the AWS account and can have:

A password for AWS Management Console access
Access keys (access key ID + secret access key) for programmatic access via CLI or API
MFA device for additional authentication security

Key points for the exam:

A new IAM user has no permissions by default
Users can belong to multiple groups
Users can have policies attached directly (inline policies) or inherit them from groups
The root user has unrestricted access and should never be used for daily tasks

Groups

IAM groups are collections of IAM users. Groups simplify permission management by allowing you to assign policies to a group rather than individual users. All users in the group inherit the group’s policies.

Key points:

A user can belong to multiple groups (up to 10)
Groups cannot be nested (a group cannot contain another group)
Groups are not identities and cannot be referenced in resource-based policies
There is no default “all users” group; you must create one if needed

Roles

IAM roles are identities with permissions that can be assumed by trusted entities. Unlike users, roles do not have permanent credentials. Instead, they provide temporary security credentials through the AWS Security Token Service (STS).

Roles are assumed by:

EC2 instances — Through instance profiles, applications on EC2 get temporary credentials automatically
Lambda functions — Execution roles define what AWS services the function can access
Other AWS services — Like CloudFormation, ECS tasks, or CodeBuild
IAM users in other accounts — Cross-account access
Federated users — External identities from SAML, OIDC, or social identity providers

Exam Tip: Whenever a question asks how an application on EC2 should access other AWS services (like S3 or DynamoDB), the answer is always an IAM role attached to the EC2 instance. Never use access keys stored on the instance.

Policies

IAM policies are JSON documents that define permissions. They specify which actions are allowed or denied on which resources and under what conditions.

Policy structure:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "192.168.1.0/24"
        }
      }
    }
  ]
}

Key elements:

Effect — Allow or Deny
Action — The API actions the statement applies to (e.g., s3:PutObject)
Resource — The AWS resources the statement applies to (specified by ARN)
Condition — Optional conditions that must be true for the statement to apply

Policy Types and Evaluation Logic

Understanding the different policy types and how AWS evaluates them is critical for the exam. This is where many candidates get tripped up.

Identity-Based Policies

Attached to IAM users, groups, or roles. They define what the identity can do.

AWS Managed Policies — Created and maintained by AWS for common use cases (e.g., AmazonS3ReadOnlyAccess). Convenient but may grant broader permissions than needed.
Customer Managed Policies — Created by you for specific organizational needs. Can be attached to multiple users, groups, or roles. Recommended for production environments.
Inline Policies — Embedded directly within a single user, group, or role. Cannot be reused. Use only when you want to ensure the policy is deleted when the identity is deleted.

Resource-Based Policies

Attached to AWS resources (like S3 buckets, SQS queues, or KMS keys). They define who can access the resource and what they can do with it. Resource-based policies include a Principal element specifying the identity that is granted or denied access.

Key difference from identity-based policies: resource-based policies can grant cross-account access directly. When Account A’s S3 bucket policy grants access to a role in Account B, users in Account B can access the bucket without needing to assume a role in Account A.

Policy Evaluation Logic

AWS evaluates policies in the following order:

Explicit Deny — If any applicable policy explicitly denies the action, the request is denied. This always wins.
Service Control Policies (SCPs) — If an SCP does not allow the action, it is denied (in AWS Organizations).
Permission Boundaries — If set, the action must be allowed by the boundary.
Session Policies — For assumed roles with session policies, the action must be allowed.
Identity-Based Policies — The action must be allowed by at least one identity-based policy.
Resource-Based Policies — Can independently grant access (cross-account scenario).
Default Deny — If no policy explicitly allows the action, it is denied.

The critical rule to remember: An explicit deny always overrides any allow. By default, everything is denied. Permissions must be explicitly granted.

Exam Scenario: A user has an IAM policy that allows s3:* on all resources, but the bucket policy explicitly denies their account. Can the user access the bucket? No. The explicit deny in the bucket policy overrides the allow in the IAM policy.

IAM Roles for EC2, Lambda, and Cross-Account Access

IAM Roles for EC2

When an application running on EC2 needs to access AWS services, attach an IAM role to the instance through an instance profile. The application uses the AWS SDK or CLI, which automatically retrieves temporary credentials from the instance metadata service.

Benefits:

No access keys to manage or rotate
Credentials are temporary and automatically rotated
Role can be changed on a running instance
Credentials are never stored on disk

Exam Tip: If a question describes access keys stored in environment variables or configuration files on EC2, the correct remediation is to replace them with an IAM role.

IAM Roles for Lambda

Every Lambda function must have an execution role that grants it permissions to access AWS resources. The function assumes this role when it runs. Additionally, Lambda can be configured with a resource-based policy that defines which services or accounts can invoke the function.

Common patterns:

Lambda reading from DynamoDB: execution role needs dynamodb:GetItem, dynamodb:Query
Lambda writing to S3: execution role needs s3:PutObject
S3 triggering Lambda: Lambda resource-based policy allows s3.amazonaws.com to invoke the function

Cross-Account Access with Roles

Cross-account access allows users in one AWS account to access resources in another account by assuming a role.

The setup involves:

Trusting account (where resources exist): Create an IAM role with a trust policy that allows the other account to assume it. Attach permission policies defining what the role can do.
Trusted account (where users exist): Grant IAM users or roles permission to call sts:AssumeRole for the cross-account role’s ARN.

When a user assumes the cross-account role, they receive temporary credentials scoped to the role’s permissions. Their original permissions are replaced for the duration of the session.

Exam Scenario: A development team in Account A needs read-only access to an S3 bucket in Account B. Create a role in Account B with S3 read permissions and a trust policy allowing Account A. Users in Account A assume the role to access the bucket.

Identity Federation

Identity federation allows external identities to access AWS resources without creating IAM users for each person.

SAML 2.0 Federation

Connects your existing corporate identity provider (like Microsoft Active Directory) to AWS. Users authenticate with the corporate IdP, receive a SAML assertion, and exchange it for temporary AWS credentials through STS.

Use cases:

Enterprise single sign-on to the AWS Console
Allowing corporate users to access AWS resources using existing credentials
Centralized identity management

Amazon Cognito

Provides authentication, authorization, and user management for web and mobile applications. It has two components:

User Pools — User directory that handles sign-up, sign-in, and token management. Returns JWT tokens for authentication.
Identity Pools (Federated Identities) — Grants temporary AWS credentials to users (authenticated or guest) so they can access AWS services directly (like S3 or DynamoDB).

Exam Scenario: A mobile app needs to allow users to sign in with their Google or Facebook accounts and then upload photos to S3. Use Cognito User Pools for authentication with social identity providers and Cognito Identity Pools to grant temporary S3 credentials.

AWS IAM Identity Center (formerly AWS SSO)

The recommended service for managing workforce access to multiple AWS accounts and business applications. It integrates with AWS Organizations and external identity providers. Users sign in once and can access all their assigned AWS accounts through a unified portal.

Key points for the exam:

Centralized access management for all AWS accounts in an organization
Supports SAML 2.0 identity providers and built-in identity store
Integrates with AWS Organizations for multi-account management
Preferred over SAML federation for new implementations

Permission Boundaries

Permission boundaries set the maximum permissions that an identity-based policy can grant to an IAM entity (user or role). They do not grant permissions themselves; they only limit what identity-based policies can allow.

How They Work

A permission boundary is an IAM policy attached to a user or role as a boundary, not as a permissions policy. The effective permissions are the intersection of the identity-based policy and the permission boundary. Even if the identity-based policy allows an action, the action is denied if the permission boundary does not allow it.

Use Cases

Delegated administration — Allow developers to create IAM roles for their applications but restrict those roles to only access specific services. The permission boundary prevents developers from creating overly permissive roles.
Limiting service access — Ensure a team can only use specific AWS services regardless of what policies they attach.

Exam Scenario: A company wants to allow developers to create IAM roles for their Lambda functions but ensure those roles can only access DynamoDB and S3. Set a permission boundary that allows only DynamoDB and S3 actions. Even if developers attach AdministratorAccess to their roles, the boundary limits effective permissions to DynamoDB and S3.

Service Control Policies (SCPs)

SCPs are policies that manage permissions across an AWS Organization. They are attached to organizational units (OUs) or individual accounts and define the maximum permissions for accounts within the organization.

Key Characteristics

SCPs do not grant permissions; they set guardrails (maximum allowed permissions)
They affect all users and roles in the account, including the root user
They do not affect service-linked roles
The management account is never affected by SCPs
SCPs use the same JSON syntax as IAM policies
They follow an inheritance model through the OU hierarchy

Common SCP Patterns

Deny specific Regions — Prevent resources from being created outside approved Regions
Deny specific services — Block access to services not approved by the organization
Require encryption — Deny creating unencrypted resources
Prevent leaving the organization — Deny the organizations:LeaveOrganization action
Protect audit trails — Deny disabling CloudTrail or deleting logs

Exam Scenario: A company needs to ensure no resources are created outside of eu-west-1 and us-east-1 across all AWS accounts. An SCP with a deny statement for all actions where aws:RequestedRegion is not in the allowed list, applied to the root OU, achieves this.

IAM Best Practices

These best practices appear frequently in exam questions, often as the differentiator between correct and incorrect answers.

Root Account Security

Enable MFA on the root account immediately after account creation
Do not create access keys for the root account
Use the root account only for tasks that specifically require it (like changing the support plan or enabling certain S3 features)
Store root account credentials securely with limited access

Principle of Least Privilege

Start with minimum permissions and add more as needed
Use AWS managed policies for common roles but customize when possible
Regularly review and remove unused permissions
Use IAM Access Analyzer to identify resources shared with external entities and unused permissions

Credential Management

Rotate access keys regularly (90-day maximum is a common organizational standard)
Use IAM roles instead of long-term access keys wherever possible
Never embed credentials in application code or commit them to version control
Use AWS Secrets Manager or Systems Manager Parameter Store for application secrets
Delete access keys that have not been used in 90 days

MFA (Multi-Factor Authentication)

Enable MFA for all IAM users, especially those with console access
Enable MFA for the root account as a top priority
Consider hardware MFA devices for the root account for maximum security
Use MFA conditions in policies for sensitive operations (e.g., require MFA to delete S3 objects)

Access Key Management

Each user can have a maximum of two access keys (to support rotation)
Rotation process: create second key, update applications, verify the new key works, deactivate the old key, delete the old key
Use the IAM credential report to identify users with old access keys

IAM Access Analyzer

IAM Access Analyzer helps you identify resources that are shared with external entities and validate that your policies grant only the intended permissions.

Resource Analysis

Continuously monitors resource-based policies (S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues) and reports any that grant access to external principals. This helps identify unintended public or cross-account access.

Policy Validation

Validates IAM policies against best practices and reports warnings, errors, and suggestions. Checks for overly permissive policies, incorrect syntax, and security anti-patterns.

Unused Access Analysis

Identifies IAM roles, access keys, and permissions that have not been used within a specified time period. This supports the principle of least privilege by highlighting permissions that can be safely removed.

Exam Scenario: A security team needs to identify all S3 buckets accessible by external AWS accounts. IAM Access Analyzer configured with the account as the zone of trust will generate findings for any S3 bucket with a policy granting cross-account access.

Common IAM Exam Scenarios

Scenario 1: Application on EC2 Accessing S3

Problem: An application on EC2 needs to read and write to an S3 bucket. Solution: Create an IAM role with a policy allowing s3:GetObject and s3:PutObject on the specific bucket. Attach the role to the EC2 instance through an instance profile. The application uses the AWS SDK, which automatically retrieves temporary credentials.

Wrong answers to watch for: Storing access keys in environment variables, embedding credentials in the application, or creating an IAM user for the application.

Scenario 2: Restricting Access to Specific Regions

Problem: An organization needs to prevent any resources from being created outside of us-east-1. Solution: Create an SCP with a deny statement for all actions where aws:RequestedRegion does not equal us-east-1. Attach the SCP to the appropriate OU. Note: exclude global services like IAM, CloudFront, and Route 53 from the deny.

Scenario 3: Temporary Access for External Contractor

Problem: An external contractor needs access to specific AWS resources for a limited time. Solution: Create an IAM role with the necessary permissions and a trust policy allowing the contractor’s AWS account (or use IAM Identity Center). The contractor assumes the role to get temporary credentials. The role’s maximum session duration limits access time. No IAM user needs to be created in your account.

Scenario 4: Lambda Function Processing SQS Messages

Problem: A Lambda function needs to read messages from an SQS queue and write results to DynamoDB. Solution: Create an IAM execution role for the Lambda function with permissions for sqs:ReceiveMessage, sqs:DeleteMessage, sqs:GetQueueAttributes on the SQS queue, and dynamodb:PutItem on the DynamoDB table. Attach the role as the function’s execution role.

Problem: A mobile application needs to authenticate users with Google and allow them to upload files to S3. Solution: Use Cognito User Pools configured with Google as a social identity provider for authentication. Use Cognito Identity Pools to exchange the authentication token for temporary AWS credentials with S3 PutObject permission. Each user’s uploads can be scoped to a user-specific S3 prefix using IAM policy variables.

Scenario 6: Preventing Privilege Escalation

Problem: Developers need to create IAM roles for their services but should not be able to create roles with more permissions than they have. Solution: Use permission boundaries. When developers create roles, require them to attach a specific permission boundary. The boundary limits the maximum permissions of any role they create, preventing escalation beyond what the organization allows.

Solidify Your IAM Knowledge with Practice

IAM concepts form the backbone of the SAA-C03 exam’s security domain, which at 30 percent carries the highest weight. The nuances of policy evaluation, cross-account access, and federation require practice with realistic scenarios to master.

Sailor.sh’s SAA-C03 mock exams include detailed IAM scenarios that test policy evaluation logic, role configuration, and federation patterns. Each question includes a thorough explanation of the correct answer and why alternative options are wrong, helping you build the security thinking the exam demands.

For additional study guidance, see our exam tips and information on exam costs.

Frequently Asked Questions

How many IAM questions are on the SAA-C03 exam?

IAM concepts appear directly in approximately 15 to 20 percent of exam questions and indirectly in many more. The Design Secure Architectures domain (30% of the exam) relies heavily on IAM knowledge. Additionally, many questions in other domains include IAM components, such as configuring the correct role for a Lambda function or granting cross-account access.

Do I need to memorize IAM policy JSON syntax?

You do not need to write policies from memory, but you must be able to read and understand policy documents presented in exam questions. Know the key elements (Effect, Action, Resource, Condition, Principal) and understand how they interact. The exam may show you a policy and ask what it permits or denies.

What is the difference between IAM roles and IAM users for the exam?

The critical distinction is that users have permanent credentials (password, access keys) while roles provide temporary credentials through STS. For the exam, the best practice is always to use roles for applications and services, and use users only for human console and CLI access. When a question asks about granting AWS access to an application, EC2 instance, or Lambda function, the answer is always a role.

How does IAM relate to AWS Organizations?

AWS Organizations manages multiple AWS accounts. IAM manages identities and permissions within a single account. SCPs in Organizations set the maximum permissions for all identities in member accounts, creating guardrails that IAM policies within the account cannot exceed. IAM Identity Center provides centralized access management across all accounts in the organization.

Can an IAM role have multiple policies?

Yes. A role can have multiple identity-based policies attached (both managed and inline). The effective permissions are the union of all attached policies, subject to any permission boundary and SCPs. If any policy denies an action, it is denied regardless of other policies.

What is the most commonly tested IAM topic on the SAA-C03?

IAM roles for EC2 instances and Lambda functions are the most frequently tested IAM topic. The principle of least privilege, cross-account access using roles, and the distinction between identity-based and resource-based policies are also very common. Understanding policy evaluation order (explicit deny wins) is essential for answering tricky scenario questions correctly.

AWS IAM for the SAA-C03 Exam: Policies, Roles, and Best Practices