Napman's Notes

IAM

Properties1
tagsreview/aws

6 min read

IAM

Summary: IAM is AWS’s global service for controlling who can access what in your account - it manages users, groups, roles, and permission policies for both humans and AWS services. IAM users/groups are internal (developers, CI/CD pipelines), NOT end-user customers of your app (that’s Cognito). IAM is foundational: every AWS service interaction goes through it.

Key Concepts

Users & Groups

  • Root account is created by default with unrestricted access; only use it for initial account setup, then lock it away
  • Users are people (or services) within your org; can belong to multiple groups
  • Groups only contain users, not other groups; a user doesn’t have to belong to any group

Policies

  • Users or groups are assigned JSON documents called policies
  • Policies define what actions are allowed or denied on which resources
  • If a user has both group policies and a direct (inline) policy, all are merged (union); explicit Deny always overrides any Allow
  • Apply the least privilege principle: don’t grant more permissions than a user needs

Policy Inheritance

  • Inline policy: a policy attached directly to a single user with no group
  • Users inherit all policies from every group they belong to
    • Ex: Erwin is in Group A, Baldwin is in Group B, both are also in Group C -> Group C’s policy is inherited by both

Policy Structure

  • Version: policy language version (always "2012-10-17")
  • Id: optional policy identifier
  • Statement: one or more permission rules, each with:
    • Sid: optional statement identifier
    • Effect: Allow or Deny
    • Principal: account/user/role this policy applies to, identified by an ARN (Amazon Resource Name) (e.g. arn:aws:iam::123456789012:user/Alice)
    • Action: actions to allow or deny (format: service:Action, e.g. s3:GetObject, ec2:StartInstances, iam:CreateUser; * wildcards all actions)
    • Resource: resources the actions apply to, by ARN (e.g. arn:aws:s3:::my-bucket/*, a specific EC2 instance ARN, or * for all)
    • Condition (optional): when the policy is in effect - e.g. restrict by IP range, require MFA, match a specific S3 path prefix

IAM Roles

  • AWS services sometimes need to perform actions on your behalf - they can’t use a username/password
  • IAM Roles assign permissions to AWS entities (services, not people)
  • Common roles: EC2 Instance Roles, Lambda Function Roles, Roles for CloudFormation

Configuration & Limits

How Users Access AWS

  1. AWS Management Console - web GUI; protected by password + MFA
  2. AWS CLI - direct access to AWS public APIs via terminal; protected by access keys
    • AWS CloudShell: browser-based CLI that uses your Console session’s credentials; no local setup needed
  3. AWS SDK - programmatic access from your application code; protected by access keys

Access keys are generated through the Console; users manage their own - never share them

Password Policy & MFA

  • Password policy enforces minimum standards across all IAM users (length, complexity, expiry, reuse prevention); necessary because a weak password on any user account exposes your entire AWS infrastructure
  • MFA device options:
    1. Virtual MFA device - authenticator app (e.g. Google Authenticator); multiple tokens on one device
    2. U2F Security Key - physical USB-like device (e.g. YubiKey); one key supports multiple root and IAM users
    3. Hardware Key Fob MFA Device
    4. Hardware Key Fob MFA Device for AWS GovCloud

Exam Tips & Gotchas

Explicit Deny always wins

An explicit Deny overrides any Allow, no matter where it comes from (group policy, inline policy, etc.). This is the single most tested IAM rule.

  • Root account = break-glass only; create an IAM admin user for daily work
  • One physical person = one IAM user - never share credentials
  • Attach permissions to groups, not individual users - easier to manage at scale
  • IAM Roles are for services, not people; EC2, Lambda, CloudFormation each get a role
  • The AWS Console GUI writes JSON policies under the hood - they’re the same thing
  • Access keys are for CLI/SDK only; never hardcode them in source code

Don't confuse: Credentials Report vs Last Accessed

  • Credentials Report = account-wide audit (who has MFA? whose keys are stale?)
  • Last Accessed = per-user least-privilege enforcement (what permissions are actually being used?)

Integrations

  • EC2 - EC2 Instance Roles let EC2 call other AWS services without hardcoded credentials
  • Lambda - Lambda Function Roles grant Lambda access to services like DynamoDB and S3
  • CloudFormation - Roles allow CloudFormation to create/modify resources on your behalf
  • Cognito - handles end-user (customer) identity; IAM handles internal (developer/service) identity

Shared Responsibility Model

  • AWS: IAM infrastructure, global availability, vulnerability analysis, compliance validation
  • You: managing users/groups/roles/policies, enabling MFA on all accounts, rotating access keys, auditing permissions with IAM tools, analyzing access patterns

Review Questions

Review Log

  • 2026-07-18 | Good | Gaps: IAM acronym expansion, inline policy exact definition (missed “no group” condition), confused access methods with account types (Console/CLI/SDK vs root/IAM user), EC2 can only have one role at a time | Solid: policy inheritance + union, deny always wins, role vs user distinction, ARN, Last Accessed vs Credentials Report, least privilege rationale | Next session: probe access methods, EC2 single role limit, and the three policy types (AWS managed vs customer managed vs inline)

Graph View