aws

IAM - Identity and Access Management

IAM controls who can do what in AWS. It provides users, roles, and policies to enforce the principle of least privilege.

awssecurityiamaccess-control

What is AWS IAM (Identity and Access Management)?

IAM (Identity and Access Management) is AWS's system for controlling access to AWS resources. It answers: who (identity) can do what (actions) on which resources (conditions). IAM is global - it applies across all regions.

Core Entities

Users

Long-lived identity for a human or application. Has a username + password (console) and/or access key + secret (programmatic). Avoid long-lived access keys - use roles instead.

Groups

Collection of users. Attach policies to groups rather than individual users for easier management.

Roles

Identity without credentials that can be assumed by AWS services, EC2 instances, Lambda functions, or other AWS accounts. Roles issue temporary credentials via STS (Security Token Service) - they expire (15 min to 12 hours). Use roles instead of access keys for EC2/Lambda.

Policies

JSON documents that define permissions. Attached to users, groups, or roles.

Policy Structure

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": { "aws:RequestedRegion": "us-east-1" }
      }
    }
  ]
}

Key fields:

Effect: Allow or Deny. Explicit Deny always wins.
Action: AWS API call (e.g., s3:GetObject, ec2:*)
Resource: ARN of the resource the action applies to
Condition: optional constraints (IP, MFA required, time of day)

Policy Types

Type	Description
Identity-based	Attached to user/group/role - what that identity can do
Resource-based	Attached to a resource (S3 bucket policy, Lambda resource policy) - who can access that resource
Service Control Policies (SCP)	AWS Organizations - maximum permissions for an entire account
Permission Boundaries	Cap on the max permissions an identity can have

Evaluation Logic

Default: implicit deny on everything
Any applicable explicit Deny overrides all Allows
Any applicable explicit Allow grants the permission

For cross-account: both the caller's identity policy AND the target resource policy must Allow.

Roles in Practice

EC2 Instance Profile: attach a role to an EC2 instance. The instance metadata service (169.254.169.254/latest/meta-data/iam/security-credentials/) provides temporary credentials that the AWS SDK uses automatically.

Lambda Execution Role: every Lambda function has an execution role defining what it can access (write to S3, query DynamoDB, publish to SNS).

Cross-account roles: Account A's Lambda assumes a role in Account B to read Account B's S3 bucket. Enables multi-account architectures.

Least Privilege in Practice

Start with zero permissions; add only what is needed
Use IAM Access Analyzer to identify unused permissions in existing policies
Enable MFA for the root account and all human users
Never use root for day-to-day operations
Rotate access keys; prefer roles over keys

IAM Policy Simulator

AWS console tool that evaluates whether a specific user/role can perform specific actions, given their current policies. Invaluable for debugging access denied errors.

Interview Angle

For production architectures, mention: EC2 instance profiles / Lambda execution roles (never hardcode access keys), principle of least privilege (narrow Action and Resource), and SCPs in multi-account setups to enforce guardrails at the org level. Knowing explicit deny overrides allow and the cross-account evaluation logic (both sides must allow) distinguishes a thorough answer from a surface-level one.