Module 2 · AWS IAM Deep Dive 🔒

AWS IAM is the single largest source of cloud misconfigurations. It’s also AWS’s most powerful feature. Master it and you can architect least-privilege cleanly; fumble it and you ship the kind of blast radius that makes every new access key a production-impacting event.

This module is the concrete IAM practitioner’s guide. You’ve seen the mental models in Module 1. Now we write actual policies, understand how AWS evaluates them, and cover the patterns that Indian fintech auditors, SOC 2 assessors, and your pen-testers actually look for.

The four core objects

• User — a named identity (typically human). Has long-lived credentials. Use sparingly; prefer SSO-federated access
• Group — a collection of users. Attach policies here; users inherit via membership
• Role — an assumable identity. No long-lived credentials; temporary credentials via STS. Used by workloads (EC2, Lambda) and humans (via AssumeRole)
• Policy — a JSON document describing permissions. Attached to users, groups, or roles (identity-based), or directly to resources (resource-based)

Policy anatomy

An IAM policy is a JSON document with one or more Statement blocks:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadFromSpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::ringsafe-app-data",
        "arn:aws:s3:::ringsafe-app-data/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

Five key elements per statement:

• Effect — Allow or Deny
• Action — one or more service:API calls
• Resource — ARNs affected
• Condition — optional constraints (IP range, MFA presence, time of day, tags, etc.)
• Principal — only in resource-based policies, defines who the policy applies to

Policy evaluation logic

When a request arrives, AWS evaluates multiple policies in a specific order:

1. Organizational Service Control Policies (SCPs) — guardrails at the org level. If an SCP denies, the request is denied regardless of any other policy
2. Identity-based policies attached to the requesting principal
3. Resource-based policies attached to the target resource
4. Permission boundaries — maximum permissions a principal can have
5. Session policies — passed at AssumeRole time

The logic:

• Explicit Deny wins. If any applicable policy says Deny, the request is denied
• Explicit Allow required. For the request to succeed, at least one applicable policy must explicitly Allow. Default is Deny
• SCPs and permission boundaries cap maximum permissions; they don’t grant

Most real-world confusion: “I have AdministratorAccess but can’t access this bucket.” Likely because an SCP at the org level denies, or the bucket’s resource policy doesn’t include the caller’s account.

# Role trust policy — who can assume
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::111111111111:user/priya"},
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": {"aws:MultiFactorAuthPresent": "true"},
      "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"}
    }
  }]
}

# Role's permission policy — what the role can do
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "*",
    "Resource": "*"
  }]
}