IAM Fundamentals — Users, Groups, Roles, and Policies

Quick Answer: IAM is AWS's identity and access management service. It controls WHO can do WHAT on WHICH resources. Use users for human identities, groups to organize users, roles for temporary credentials (EC2, Lambda, cross-account), and policies to define permissions. Always follow the principle of least privilege and never use root for daily operations.

IAM Overview

AWS Identity and Access Management (IAM) is a global service that controls authentication (who are you?) and authorization (what can you do?) for AWS resources. IAM is free — you pay only for the resources your users access.

Key Characteristics

• Global — IAM is not Region-specific; users/roles work across all Regions
• Free — No charge for IAM itself
• Eventually consistent — Changes propagate globally but may take seconds
• Integrated with all AWS services — Every AWS API call checks IAM permissions

IAM Users

An IAM user represents a person or application that interacts with AWS.

Best Practices:

• Create individual users for each person — never share credentials
• Enable MFA for all users, especially those with console access
• Rotate access keys regularly
• Delete unused users and credentials promptly

IAM Groups

An IAM group is a collection of IAM users. Groups let you specify permissions for multiple users at once, making it easier to manage permissions.

Key rules:

• A user can belong to multiple groups (up to 10)
• Groups cannot be nested (no groups within groups)
• Groups cannot be used as principals in resource-based policies
• There is no default group — you must create them

Example structure:

IAM Roles

An IAM role is an identity with specific permissions that can be assumed by users, applications, or AWS services. Roles provide temporary credentials via AWS Security Token Service (STS).

When to Use Roles (Critical for Exam)

How Role Assumption Works

1. A principal (user, service, or application) calls sts:AssumeRole
2. STS verifies the role's trust policy allows the principal
3. STS returns temporary credentials (access key, secret key, session token)
4. Credentials expire after a configurable duration (15 min to 12 hours)
5. The principal uses temporary credentials to make API calls

On the Exam: If a question mentions an EC2 instance needing to access another AWS service (e.g., S3, DynamoDB), the answer is almost always "attach an IAM role to the EC2 instance." NEVER store access keys on EC2 instances.

IAM Policies

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

Policy Structure

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

Policy Elements

Types of Policies

Policy Evaluation Logic

When a principal makes an API request, IAM evaluates policies in this order:

1. Explicit Deny — If ANY policy says Deny, the request is denied (Deny always wins)
2. Organization SCPs — Must allow the action (if applicable)
3. Permission Boundaries — Must allow the action (if applicable)
4. Session Policies — Must allow the action (if applicable)
5. Identity-based Policies — At least one must allow the action
6. Resource-based Policies — Can grant access independently

Key Rule: An explicit Deny in ANY policy overrides any Allow. If no policy explicitly allows an action, it is implicitly denied.

The Root Account

The root account is the email address used to create the AWS account. It has unrestricted access to everything.

Root account best practices:

• Enable MFA immediately
• Do NOT create access keys for root
• Do NOT use root for daily tasks
• Use root only for tasks that require it (e.g., changing account settings, closing the account, enabling certain features)

IAM Best Practices Summary