IAM

1. What Is It?

AWS Identity and Access Management (IAM) is the system that controls who (or what) can do what in your AWS account. It defines identities (users, groups, roles) and attaches policies — JSON documents that grant or deny specific API actions on specific resources.

Without IAM, every person and every service would have unlimited access to every resource in your account. A compromised developer machine would mean full access to production databases. A bug in a Lambda function could accidentally delete S3 buckets. IAM is the mechanism that enforces least-privilege access across everything in AWS — it is consulted on every single API call.

2. How It Works

The core model

Every AWS API call goes through a 4-step authorization check:

-+ResetFullscreen

Default is deny. If no policy explicitly allows an action, it is denied. An explicit Deny always overrides any Allow.

Identities

Roles are how services authenticate. A Lambda function doesn't log in with a username and password — it runs under a role. When it calls S3 or DynamoDB, IAM checks the permissions attached to that role.

Policies

A policy is a JSON document listing what actions are allowed or denied:

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

Policy types:

• AWS Managed Policies — pre-built by AWS (e.g., AmazonS3ReadOnlyAccess). Convenient but often broader than needed.
• Customer Managed Policies — you write and maintain them. Recommended for production.
• Inline Policies — embedded directly on a user/role. Avoid — hard to audit and reuse.
• Resource-based Policies — attached to a resource (S3 bucket policy, SQS queue policy) rather than an identity. Used for cross-account access.

Assuming a Role

Roles are not credentials you use directly — you assume them. Assuming a role calls AWS STS (Security Token Service), which returns temporary credentials (access key, secret, session token) that expire in 15 minutes to 12 hours.

-+ResetFullscreen

AWS SDKs do this automatically. You rarely call STS directly in application code.

3. What Backend Engineers Actually Need to Know

Use roles for everything that isn't a human. EC2 instances, Lambda functions, ECS tasks, CodeBuild jobs — all of them should run under an IAM role. Never embed access keys in application code or environment variables if you can avoid it.

The ARN (Amazon Resource Name) is how you identify resources in policies. Format: arn:aws:<service>:<region>:<account-id>:<resource-type>/<resource-id>. In policy Resource fields, * is a wildcard: arn:aws:s3:::my-bucket/* means all objects in the bucket.

Common misunderstandings:

• "I'll just give my Lambda AdministratorAccess to make it work." — This works, but it means a single compromised function or bug can delete any resource in your account. Always scope to the minimum required.
• "IAM is only for humans." — Most IAM complexity in production systems involves service-to-service authentication, not human users.
• "Permissions are additive." — Mostly true, but explicit Deny always wins. A Deny anywhere in the evaluation chain blocks the action, even if another policy allows it. Service Control Policies (SCPs) in AWS Organizations can also deny actions at the organization level.
• "Cross-account access requires creating IAM users in each account." — No. Use cross-account role assumption: the Lambda in Account A assumes a role in Account B. The role in Account B has a trust policy allowing Account A to assume it.

4. Tradeoffs & Decisions

IAM User vs. IAM Role:

• IAM Users have long-term credentials. If the access key leaks, it's valid until rotated. Roles use temporary credentials that expire automatically — far safer.
• Use IAM Users only for: human console access (when SSO/Identity Center isn't set up) and legacy CI/CD systems that can't assume roles.
• Prefer AWS IAM Identity Center (formerly SSO) for human access and role assumption for everything else.

Broad managed policies vs. narrow custom policies:

• AdministratorAccess and PowerUserAccess are convenience policies that have no place in production workloads. They exist for bootstrapping and dev accounts.
• Writing narrow policies takes time but shrinks your blast radius when credentials are compromised.
• "If you see X, it usually means Y": if a developer says "I just gave it S3 full access," it likely means the policy allows s3:* on * — meaning it can delete any bucket in the account. Scope by action and by Resource ARN.

Trust policies:

• A role has two parts: the permissions policy (what the role can do) and the trust policy (who can assume the role). A role with AmazonS3FullAccess but a trust policy that only allows ec2.amazonaws.com can only be assumed by EC2 — not Lambda, not a human.

5. Interview Cheat Sheet

Key sentences:

1. "IAM is consulted on every AWS API call — the default is deny, and a single explicit Deny overrides any number of Allow statements."
2. "Services authenticate using IAM Roles, not long-term credentials — the EC2 metadata service or Lambda runtime automatically fetches temporary credentials from STS."
3. "Least privilege isn't just a best practice — it's the difference between a misconfigured Lambda deleting one table vs. every table in the account."
4. "Resource-based policies (like S3 bucket policies) enable cross-account access without creating IAM users in every account."

Common follow-ups:

Q: How does a Lambda function get permissions to write to DynamoDB? A: You attach an execution role to the Lambda with a policy that allows dynamodb:PutItem (and other needed actions) on the specific table ARN. The Lambda runtime fetches temporary credentials for that role from the EC2 metadata service equivalent, and the AWS SDK uses them automatically.

Q: What's the difference between an identity-based policy and a resource-based policy? A: Identity-based policies are attached to a principal (user, role, group) and say what that principal can do. Resource-based policies are attached to a resource (S3 bucket, SQS queue) and say who can access that resource. Both must allow the action for cross-account access to work.

Q: Why should you avoid long-term IAM access keys? A: Long-term keys don't expire. If they're leaked in a git commit, log file, or environment variable, an attacker has permanent access until you manually rotate or delete the key. Roles produce temporary credentials that expire automatically (15 min to 12 hours), limiting the window of exposure.