AWS IAM Policies & Roles Explained: Free Tutorial + Practice Exam

What is AWS IAM?

AWS Identity and Access Management (IAM) is the security foundation of every AWS deployment. It controls who can authenticate (sign in) and who is authorized (has permissions) to use AWS resources. Every API call made to AWS is evaluated by IAM to determine whether the request should be allowed or denied.

IAM is a global service, meaning it is not region-specific. When you create an IAM user, role, or policy, it is available across all AWS regions in your account. This is different from most other AWS services such as EC2 or S3, which operate within specific regions. The global nature of IAM means that a single set of credentials works regardless of which region you are operating in.

One of the most important things to know about IAM is that it is completely free. There is no charge for creating users, groups, roles, or policies. You only pay for the AWS resources that your IAM principals actually consume. This makes IAM one of the first services you should configure when setting up any AWS account.

The core security principle that governs IAM is the principle of least privilege. This means you should grant only the minimum permissions necessary for a user, group, or role to perform their required tasks. If a developer only needs to read objects from a specific S3 bucket, you should not grant them full S3 access or, worse, full AWS administrator access. Overly permissive policies are one of the most common security vulnerabilities in cloud environments.

IAM consists of several key components that work together: users (individual identities), groups (collections of users), roles (temporary identities for services or cross-account access), and policies (JSON documents that define permissions). Understanding how these components interact is essential for both real-world AWS administration and the SAA-C03 exam.

IAM Users and Root Account

When you first create an AWS account, you start with a single identity known as the root account. The root account is created using the email address and password you provided during account signup. This account has unrestricted, complete access to every service and resource in the AWS account. The root account cannot be limited by IAM policies - it always has full administrative privileges.

Because the root account has unlimited power, it represents a significant security risk if compromised. AWS strongly recommends that you never use the root account for everyday tasks. Instead, you should immediately create IAM users with appropriate permissions and use those for daily operations. The root account should be reserved for the small number of tasks that require root credentials, such as changing account-level settings, closing the account, or restoring IAM user permissions when locked out.

IAM users are individual identities that represent people or applications that need to interact with AWS. Each IAM user has a unique name within the AWS account and can be granted specific permissions through policies. Unlike the root account, IAM users start with zero permissions by default. You must explicitly grant them access to any AWS resource.

IAM users can have two types of access credentials:

• Console access - A password for signing into the AWS Management Console through a web browser. You should always enable Multi-Factor Authentication (MFA) for console access to add a second layer of security beyond the password.
• Programmatic access - An access key ID and secret access key pair for making API calls through the AWS CLI, SDKs, or direct HTTP requests. Access keys are long-term credentials and should be rotated regularly. When possible, prefer IAM roles over access keys.

Each AWS account can have up to 5,000 IAM users. If your organization has more than 5,000 people who need AWS access, you should use IAM Identity Center (formerly AWS SSO) or federation with an external identity provider rather than creating individual IAM users.

IAM Groups

IAM groups are logical collections of IAM users. Groups let you manage permissions for multiple users at once rather than attaching policies to each user individually. When you attach a policy to a group, every user in that group automatically inherits those permissions.

Groups are a best practice for managing permissions at scale. Instead of attaching the same policy to 50 individual developers, you create a "Developers" group, attach the policy once, and add all 50 developers to the group. When a new developer joins the team, you simply add them to the group. When someone leaves, you remove them. This approach is easier to manage and less error-prone than managing per-user policies.

There are several important rules about IAM groups that you must know for the exam:

• Users inherit group policies - When a user belongs to a group, they receive all permissions defined by the group's attached policies. If a user belongs to multiple groups, they receive the combined permissions from all groups.
• A user can belong to multiple groups - An IAM user can be a member of up to 10 groups simultaneously. For example, a DevOps engineer might belong to both the "Developers" group and the "Operations" group.
• Groups cannot contain other groups - IAM groups can only contain users, not other groups. There is no concept of nested groups or group hierarchies in IAM.
• Groups are not identities - You cannot reference a group as a principal in a resource-based policy. Groups exist solely for organizing users and attaching policies. You cannot "log in" as a group.
• There is no default "all users" group - Unlike some other identity systems, IAM does not automatically create a group that includes all users. If you want a policy to apply to everyone, you must create a group and explicitly add all users to it.

Here are common group patterns used in real-world AWS environments:

• Admins - Full administrative access (AdministratorAccess managed policy). Reserved for a small number of trusted users.
• Developers - Access to development resources like Lambda, API Gateway, DynamoDB, S3, and CloudWatch. Restricted from production resources.
• ReadOnly - Read-only access across the account for auditors, managers, or new team members who need visibility without the ability to make changes.
• DatabaseAdmins - Access to RDS, DynamoDB, ElastiCache, and related monitoring tools. No access to networking or compute resources.
• NetworkAdmins - Access to VPC, Route 53, CloudFront, and related networking services. Useful for network teams in larger organizations.

IAM Roles

IAM roles are one of the most important concepts in AWS security. A role is an IAM identity that you can create with specific permissions, but unlike a user, a role does not have permanent long-term credentials (no password, no access keys). Instead, when a principal assumes a role, AWS Security Token Service (STS) provides temporary security credentials that expire automatically after a configurable period (from 15 minutes to 12 hours).

Roles are designed to be assumed by trusted entities. These entities can include:

• AWS services - An EC2 instance that needs to access S3, a Lambda function that needs to read from DynamoDB, or an ECS task that needs to push to an SQS queue. The service assumes the role and receives temporary credentials automatically.
• IAM users in another AWS account - Cross-account access is one of the most common role use cases. A user in Account A can assume a role in Account B to access resources, without needing separate credentials in Account B.
• Federated users - Users authenticated through an external identity provider (such as Active Directory via SAML 2.0, or Google/Facebook via OIDC) can assume a role to gain temporary AWS access without needing an IAM user.
• IAM users in the same account - Users can assume roles within their own account to temporarily elevate their privileges for specific tasks (similar to "sudo" in Linux).

Every IAM role has two key components:

1. Trust policy - A JSON document that specifies which principals are allowed to assume the role. This acts as a gatekeeper: only the entities listed in the trust policy can request temporary credentials for the role.
2. Permissions policy - One or more JSON policy documents that define what the role can do once assumed. These work exactly like identity-based policies attached to users or groups.

Here are the most common role use cases you will encounter on the exam:

EC2 Instance Role for S3 Access: Instead of storing AWS access keys on an EC2 instance (which is insecure and difficult to rotate), you create an IAM role with S3 permissions and attach it to the instance through an instance profile. The EC2 instance automatically receives temporary credentials that are rotated by AWS. Applications running on the instance can use the AWS SDK without any explicit credential configuration.

Lambda Execution Role: Every Lambda function requires an execution role that grants it permission to access AWS resources. When Lambda invokes your function, it assumes this role and passes the temporary credentials to your function code. At minimum, a Lambda execution role needs permission to write logs to CloudWatch Logs.

Cross-Account Access with AssumeRole: Organization A wants to grant Organization B read access to an S3 bucket. Organization A creates a role with S3 read permissions and a trust policy that allows Organization B's account to assume it. Users in Organization B call sts:AssumeRole to get temporary credentials, then use those credentials to access the S3 bucket. No credentials are shared between accounts.

Federation with SAML/OIDC: A company uses Active Directory for their corporate identity management. They configure SAML 2.0 federation so that employees can sign in with their corporate credentials and be mapped to IAM roles based on their AD group membership. Developers get the "DeveloperRole" and finance staff get the "FinanceReadOnlyRole" - without creating individual IAM users for each employee.

IAM Policies Deep Dive

IAM policies are JSON documents that define permissions. A policy specifies which actions are allowed or denied on which AWS resources, and optionally under which conditions. Policies are the mechanism through which you implement the principle of least privilege in AWS.

Every IAM policy follows a specific JSON structure. Here is a complete example that grants read access to a specific S3 bucket, restricted to requests originating from a corporate IP range:

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

Let us break down each field in this policy:

• Version - Always set to "2012-10-17", which is the current and recommended policy language version. The older version "2008-10-17" does not support all features (such as policy variables). Always use 2012-10-17.
• Statement - An array of one or more permission statements. Each statement defines a specific permission rule. A single policy can contain multiple statements.
• Sid (optional) - A statement identifier. A human-readable label that helps you identify what the statement does. It has no functional effect on the policy evaluation.
• Effect - Either "Allow" or "Deny". This determines whether the statement grants or blocks access. There is no default effect; every statement must explicitly specify Allow or Deny.
• Action - The specific API operations that the statement applies to. Actions follow the format service:operation, such as s3:GetObject or ec2:StartInstances. You can use wildcards: s3:Get* matches all S3 Get operations, and s3:* matches all S3 operations.
• Resource - The specific AWS resources the statement applies to, identified by their Amazon Resource Name (ARN). In the example above, the policy applies to the bucket itself (arn:aws:s3:::my-bucket for ListBucket) and all objects within it (arn:aws:s3:::my-bucket/* for GetObject). Using * as the resource means "all resources."
• Condition (optional) - Additional constraints that must be met for the statement to apply. The example restricts access to requests coming from the 10.0.0.0/8 IP range. Conditions can test IP addresses, MFA status, time of day, tags, and many other attributes.

Understanding ARN (Amazon Resource Name) patterns is critical for writing effective policies. ARNs follow this format:

arn:partition:service:region:account-id:resource-type/resource-id

For S3, the ARN format omits region and account because S3 bucket names are globally unique: arn:aws:s3:::bucket-name. For DynamoDB, you include the region and account: arn:aws:dynamodb:us-east-1:123456789012:table/MyTable. You can use wildcards in ARNs: arn:aws:s3:::* matches all S3 buckets, and arn:aws:dynamodb:*:*:table/* matches all DynamoDB tables in all regions and accounts.

Types of IAM Policies

AWS has several categories of policies, and understanding the distinctions is essential:

Identity-based policies are attached to IAM principals (users, groups, or roles). They define what that principal is allowed to do. The S3 read policy example above is an identity-based policy. These come in three subtypes:

• AWS managed policies - Predefined policies created and maintained by AWS. Examples include AmazonS3ReadOnlyAccess, AdministratorAccess, and AmazonDynamoDBFullAccess. AWS updates these when new features are released. They are convenient but may grant more permissions than needed.
• Customer managed policies - Policies you create and manage yourself. These allow you to tailor permissions precisely to your requirements. You can version them and reuse them across multiple principals. This is the recommended approach for production environments.
• Inline policies - Policies embedded directly in a single user, group, or role. They have a strict one-to-one relationship with the principal. Inline policies are deleted when the principal is deleted. AWS generally recommends using customer managed policies instead of inline policies because managed policies are reusable and easier to audit.

Resource-based policies are attached to AWS resources rather than to IAM principals. The most common example is an S3 bucket policy. Resource-based policies specify who (which principal) can access the resource and what actions they can perform. They are particularly useful for granting cross-account access because they allow you to specify principals from other AWS accounts directly.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountRead",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::shared-data-bucket/*"
    }
  ]
}

Notice that resource-based policies include a Principal field that identity-based policies do not. The Principal specifies who is granted or denied access. In this example, the entire AWS account 111122223333 is granted read access to objects in the bucket.

Policy Evaluation Logic

Understanding how AWS evaluates policies is one of the most critical skills for the SAA-C03 exam. When an IAM principal makes a request to AWS, the IAM engine evaluates all applicable policies to determine whether to allow or deny the request. The evaluation follows a precise order with clear rules.

The three fundamental rules of IAM policy evaluation:

1. Default deny - By default, all requests are denied. If no policy explicitly allows a request, it is denied. A newly created IAM user with no policies attached cannot do anything.
2. Explicit allow - An explicit Allow statement in an applicable policy overrides the default deny. The request is allowed if at least one policy grants the necessary permission.
3. Explicit deny always wins - An explicit Deny statement in any applicable policy overrides any Allow statement, regardless of where the Allow is defined. If any policy says Deny, the request is denied, period. This is the single most important rule in IAM policy evaluation.

Policy evaluation order for requests within a single account:

1. Organization Service Control Policies (SCPs) - If the account is part of AWS Organizations, SCPs are evaluated first. SCPs set the maximum permissions that identity-based policies in the account can grant. Even if an IAM policy allows an action, the SCP must also allow it. SCPs do not grant permissions themselves; they only restrict what can be granted.
2. Resource-based policies - Policies attached to the resource being accessed (such as S3 bucket policies or SQS queue policies). If a resource-based policy allows the request and there is no explicit deny, the request is allowed - even if no identity-based policy grants access.
3. Identity-based policies - Policies attached to the IAM user, group, or role making the request. These include managed policies and inline policies.
4. Permissions boundaries - An advanced feature that sets the maximum permissions an IAM user or role can have. Like SCPs, permissions boundaries do not grant permissions; they restrict what identity-based policies can grant. The effective permissions are the intersection of the identity-based policy and the permissions boundary.
5. Session policies - Optional policies passed when assuming a role or federating. They further restrict the permissions of the session to be a subset of the role's permissions.

Text-based evaluation flow:

REQUEST ARRIVES
    |
    v
Is there an EXPLICIT DENY in any applicable policy?
    |
    YES --> DENIED (final, no override possible)
    |
    NO
    |
    v
Is the account in an AWS Organization?
    |
    YES --> Does the SCP ALLOW this action?
    |           |
    |           NO --> DENIED
    |           |
    |           YES --> continue
    |
    NO --> continue
    |
    v
Is there an applicable RESOURCE-BASED policy that allows access?
    |
    YES --> ALLOWED (for same-account requests)
    |
    NO --> continue
    |
    v
Is there an IDENTITY-BASED policy that allows access?
    |
    NO --> DENIED (default deny)
    |
    YES --> Is there a PERMISSIONS BOUNDARY?
                |
                NO --> ALLOWED
                |
                YES --> Does the boundary also allow it?
                            |
                            NO --> DENIED
                            |
                            YES --> ALLOWED

Common IAM Scenarios

The SAA-C03 exam tests IAM through real-world scenarios. Here are four common patterns with complete policy examples that appear frequently on the exam.

Scenario 1: EC2 Instance Accessing S3 via IAM Role

An application running on an EC2 instance needs to read objects from an S3 bucket named app-data-bucket. The correct approach is to create an IAM role with the necessary S3 permissions and attach it to the EC2 instance via an instance profile.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::app-data-bucket",
        "arn:aws:s3:::app-data-bucket/*"
      ]
    }
  ]
}

The role also needs a trust policy that allows the EC2 service to assume it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

With this configuration, the EC2 instance automatically receives temporary credentials. The AWS SDK running on the instance retrieves these credentials from the instance metadata service (IMDS) without any manual credential configuration. AWS rotates these credentials automatically before they expire.

Scenario 2: Cross-Account Access with AssumeRole

Company A (account 111111111111) has an S3 bucket with data that Company B (account 222222222222) needs to read. Company A creates a role that Company B can assume:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::222222222222:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "CompanyB-Audit-2026"
        }
      }
    }
  ]
}

The ExternalId condition is a security best practice for cross-account access. It prevents the "confused deputy" problem, where a malicious third party could trick a service into accessing resources it should not. The external ID acts as a shared secret between the two parties.

Scenario 3: MFA Enforcement Policy

This policy denies all actions except IAM self-service actions unless the user has authenticated with MFA. It is commonly attached to all users to enforce MFA usage:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSelfServiceMFA",
      "Effect": "Allow",
      "Action": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ChangePassword"
      ],
      "Resource": "arn:aws:iam::*:user/${aws:username}"
    },
    {
      "Sid": "DenyAllWithoutMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ChangePassword",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

This policy uses NotAction in the Deny statement, which means "deny everything EXCEPT these specific actions" when MFA is not present. This allows users to set up their MFA device and change their password, but blocks all other AWS operations until MFA is enabled and used.

Scenario 4: IP-Based Access Restriction

This policy restricts all AWS operations to requests originating from the corporate network IP range. It is useful for organizations that want to ensure employees can only access AWS from the office or VPN:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessOutsideCorporateIP",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            "203.0.113.0/24",
            "198.51.100.0/24"
          ]
        }
      }
    }
  ]
}

This uses a Deny with NotIpAddress pattern. It explicitly denies all actions from any IP address that is NOT in the specified ranges. Because explicit deny always wins, this blocks access from unauthorized locations even if other policies grant broad permissions. This pattern is commonly applied as a Service Control Policy (SCP) at the organization level for maximum effectiveness.

IAM Best Practices

AWS publishes a set of IAM best practices, and the SAA-C03 exam expects you to know them. Following these practices reduces your attack surface and helps maintain a secure AWS environment.

1. Enable MFA on the root account and all IAM users - MFA adds a critical second factor beyond passwords. Use hardware MFA tokens or authenticator apps. At minimum, the root account must always have MFA enabled. For production environments, require MFA for all users, especially those with elevated permissions.
2. Use IAM roles instead of access keys - For any application running on AWS infrastructure (EC2, Lambda, ECS, EKS), always use IAM roles rather than embedding access keys. Roles provide temporary credentials that rotate automatically. Access keys are long-term credentials that can be leaked through code repositories, logs, or configuration files. If you must use access keys for external applications, rotate them regularly and never embed them in code.
3. Apply the principle of least privilege - Start with zero permissions and grant only what is needed. Use specific resource ARNs rather than wildcards when possible. For example, granting s3:GetObject on arn:aws:s3:::specific-bucket/* is far more secure than granting s3:* on *. Periodically review and tighten permissions using IAM Access Analyzer.
4. Use AWS Organizations SCPs for guardrails - If you manage multiple AWS accounts, use Service Control Policies to enforce organization-wide restrictions. SCPs can prevent accounts from using certain regions, disabling CloudTrail, or creating resources without encryption. SCPs are evaluated before identity-based policies and cannot be overridden by account-level administrators.
5. Rotate credentials regularly - AWS recommends rotating access keys every 90 days. Use IAM credential reports and AWS Config rules to identify stale credentials. Disable or delete access keys that have not been used in 90 days. For passwords, enforce a strong password policy with minimum length, complexity requirements, and expiration.
6. Use IAM Access Analyzer - Access Analyzer continuously monitors your resource-based policies to identify resources that are shared with external entities. It flags S3 buckets, IAM roles, KMS keys, Lambda functions, and SQS queues that have policies allowing access from outside your account or organization. Use it to identify unintended public or cross-account access.
7. Avoid inline policies - Prefer customer managed policies over inline policies. Managed policies are reusable across multiple principals, versioned (up to 5 versions), and easier to audit. Inline policies are hidden within individual users, groups, or roles, making them harder to discover and manage at scale.
8. Use policy conditions for additional security - Conditions add context-based controls that go beyond simple allow/deny. Common conditions include requiring MFA (aws:MultiFactorAuthPresent), restricting source IP (aws:SourceIp), requiring encryption in transit (aws:SecureTransport), and enforcing tag-based access control (aws:ResourceTag).
9. Monitor IAM activity with CloudTrail - AWS CloudTrail logs every API call in your account, including all IAM operations. Monitor for unusual activity such as access from unfamiliar IP addresses, failed authentication attempts, privilege escalation, or creation of new IAM users outside normal processes.
10. Use IAM Identity Center for workforce access - For organizations with many employees, use IAM Identity Center (formerly AWS SSO) to manage workforce access centrally. It integrates with external identity providers like Active Directory and Okta, and supports single sign-on across multiple AWS accounts and applications.

IAM for the SAA-C03 Exam

IAM appears on the SAA-C03 exam in several forms. Here is what the exam specifically tests and how to prepare for IAM-related questions.

Core topics the exam tests:

• Policy evaluation logic - Expect questions that describe multiple overlapping policies (identity-based + resource-based + SCP) and ask whether a specific action is allowed or denied. Apply the evaluation rules: explicit deny wins, then check for explicit allow, then default deny.
• Roles vs. users - Questions about the "most secure" way to provide access to AWS services always point to IAM roles. If you see access keys, hardcoded credentials, or storing credentials in environment variables as answer options, those are always wrong for service-to-service access within AWS.
• Cross-account access - Understand both approaches: cross-account IAM roles (with trust policies and AssumeRole) and resource-based policies (like S3 bucket policies that name an external account as principal). Know when to use each approach.
• Federation - Know the difference between SAML 2.0 federation (for enterprise identity providers like Active Directory), OIDC federation (for web identity providers like Google or Amazon Cognito), and IAM Identity Center. Understand that federation maps external identities to IAM roles.
• Permissions boundaries - Understand that boundaries set the maximum permissions a user or role can have. The effective permissions are the intersection of the identity-based policy and the permissions boundary. This is a frequent exam topic for delegation scenarios.

Common question patterns:

• "A company needs the MOST secure way to..." - Answer involves IAM roles, MFA, or least privilege policies.
• "An application on EC2 needs to access DynamoDB..." - Answer is an IAM role attached via instance profile, not access keys.
• "A third party needs temporary access to..." - Answer involves a cross-account role with external ID or a resource-based policy.
• "Users should only be able to manage their own resources..." - Answer involves policy conditions using ${aws:username} or tag-based access control.
• "Prevent any IAM user from disabling CloudTrail..." - Answer involves an SCP in AWS Organizations.

Trap answers to watch for:

• Sharing access keys between applications or team members - always wrong.
• Using the root account for any operational task - always wrong.
• Storing credentials in code, environment variables, or EC2 user data - wrong when a role is an option.
• Using S3 ACLs instead of bucket policies or IAM policies - ACLs are a legacy mechanism and almost never the correct answer.
• Granting * (wildcard) permissions and then trying to restrict with conditions - while technically possible, this is not least privilege and is usually the wrong answer.

AWS IAM Policies & Roles Practice Questions

Test your understanding of IAM with these 5 expert-created questions. Each includes a detailed explanation to reinforce your learning and prepare you for the SAA-C03 exam.