AWS IAM: Users, Roles, Policies, and Least Privilege

IAM core concepts

IAM manages authentication (who are you?) and authorisation (what can you do?).

# IAM Identity types:
# User    — a person or application with long-term credentials
# Group   — collection of users, attach policies to group
# Role    — temporary credentials, assumed by users or AWS services

# Policy types:
# Identity-based  — attached to users/groups/roles
# Resource-based  — attached to resources (S3, SQS, etc.)
# Service Control Policies (SCP) — AWS Organizations guardrails

# Key rule: default DENY everything
# Explicit Allow: required to grant access
# Explicit Deny: always wins, even if there's an Allow

IAM policies

Policies are JSON documents that define permissions.

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

# Policy elements:
# Effect: Allow or Deny
# Action: API actions (e.g., "ec2:StartInstances")
# Resource: ARN of the resource (* = all)
# Condition: optional, further restricts when policy applies

IAM roles

Roles provide temporary credentials. Services assume roles to access other AWS services.

# Common role use cases:
# - EC2 instance role: allows app on EC2 to access S3/DynamoDB
# - Lambda execution role: allows Lambda to write to CloudWatch
# - Cross-account role: allow another AWS account to access your resources
# - Federated identity: allow corp users (Active Directory) to assume role

# Why roles instead of access keys for services:
# - No long-term credentials stored on instance
# - Credentials auto-rotate
# - No risk of keys being committed to code

# Trust policy: who CAN assume the role
{
  "Principal": { "Service": "ec2.amazonaws.com" },
  "Action": "sts:AssumeRole"
}

IAM best practices

These best practices appear in every IAM exam question.

# 1. Least Privilege: grant minimum permissions needed
#    Start with nothing, add only what's required

# 2. Never use root account for daily operations
#    Root has unlimited access with no restrictions
#    Enable MFA on root immediately

# 3. Use groups to manage permissions
#    Attach policies to groups, not individual users

# 4. Enable MFA for all users (especially privileged)

# 5. Use roles for applications and services (not access keys)

# 6. Rotate credentials regularly

# 7. Use IAM Access Analyzer to identify over-permissive policies

# 8. Use Permission Boundaries for delegated administration

# 9. Enforce strong password policy

Exam tip

The principle of least privilege is the most-tested IAM concept: grant only the permissions needed to perform a task, nothing more. Also know: explicit Deny always overrides Allow, and root should only be used for tasks that literally require root (billing setup, account closure).