IAM — Cheat Sheet

Tags: iam, security, auth, oauth2, rbac, abac, aws

Level: intermediate

TL;DR: Core IAM concepts: authentication vs authorization, RBAC vs ABAC models, least privilege enforcement, and secure token lifecycle management.

Key concepts

Authentication verifies user identity; authorization defines accessible resources and permitted operations.

Principle of Least Privilege: grant only the minimum permissions required for a specific task.

RBAC assigns permissions to fixed roles and assigns roles to users.

ABAC evaluates policies dynamically using user, resource, action, and environment attributes.

IAM Identities: Users (humans/long-lived), Groups (collections of users), and Roles (temporary credentials).

Federated Identity allows external IdPs (SAML 2.0, OIDC) to authenticate enterprise users.

Explicit Deny always overrides an Allow decision in policy evaluation engines.

Service accounts and machine identities require short-lived tokens instead of hardcoded long-term credentials.

Typical questions and ready answers

Q: How do you decide between RBAC and ABAC in an application architecture?R: I start with RBAC for predictable, hierarchical permissions like admin or editor. I introduce ABAC when authorization depends on dynamic contexts, such as tenant tenancy, department, or document ownership.

Q: How do you eliminate hardcoded cloud credentials in production environments?R: I leverage short-lived IAM roles attached to execution environments like ECS tasks, Kubernetes service accounts, or EC2 instance profiles via metadata services.

Q: What is the difference between an inline policy and a managed policy?R: Managed policies are standalone entities reusable across multiple identities. Inline policies are strictly embedded within a single identity and get deleted if the identity is removed.

Pitfalls and common mistakes

Assigning wildcard permissions (*) on critical resources during debugging and leaving them in production.

Attaching policies directly to users instead of groups or roles, causing permission sprawl.

Treating authentication tokens (like OAuth id_token) as authorization credentials instead of checking the access_token.

Confusing trust policies (who can assume the role) with permission policies (what the role can execute).

Snippets and commands

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadScopedToBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::app-storage-bucket",
        "arn:aws:s3:::app-storage-bucket/*"
      ]
    }
  ]
}

Bash

# Assume an IAM role and retrieve temporary session credentials
aws sts assume-role \
  --role-arn "arn:aws:iam::123456789012:role/DeployerRole" \
  --role-session-name "DeploySession"

To review

[ ] Policy evaluation logic order (Explicit Deny > SCP > RBAC/Permissions > Session limits)

[ ] OpenID Connect (OIDC) core token flows and claims

[x] Principle of Least Privilege enforcement

Jarvis Interviews
Jarvis