Security & identity

IAM fundamentals

3 min readChapter 05 of 48By Bipin Singh

AWS Identity and Access Management (IAM) controls who can do what on which resources. Every API call to AWS is checked against IAM. It is the heart of Domain 1, and misunderstanding it causes more wrong answers than any other topic.

The building blocks

Concept	What it is	Use it for
Root user	The email/password that created the account; unrestricted access	Almost nothing — lock it away
IAM user	A long-term identity with a password and/or access keys	Rare today; legacy tools, break-glass access
IAM group	A collection of users that share policies	Assign permissions to teams of users
IAM role	An identity with permissions but no long-term credentials; assumed temporarily	Applications, AWS services, cross-account and federated access
Policy	A JSON document that allows or denies actions	Attach to users, groups, roles or resources

Key idea

Prefer roles over users with access keys wherever possible. Roles give temporary credentials that expire automatically, so there's nothing long-lived to leak.

Protecting the root user

Enable MFA on the root user.
Don't create access keys for root.
Use root only for the few tasks that require it (for example, changing account settings or closing the account).
Create administrative access through IAM Identity Center or IAM roles instead.

Policies in detail

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadReports",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["arn:aws:s3:::company-reports", "arn:aws:s3:::company-reports/*"],
      "Condition": { "IpAddress": { "aws:SourceIp": "203.0.113.0/24" } }
    }
  ]
}

Element	Meaning
`Effect`	`Allow` or `Deny`
`Action`	API operations, e.g. `s3:GetObject`; wildcards allowed
`Resource`	The ARNs the statement applies to
`Condition`	Optional rules: source IP, MFA present, tags, VPC endpoint, time, encryption…
`Principal`	Who the policy applies to — only in resource-based policies

Types of policies

Type	Attached to	Purpose
Identity-based (AWS managed, customer managed, inline)	Users, groups, roles	What this identity can do
Resource-based	Resources (S3 bucket policy, SQS queue policy, KMS key policy, Lambda resource policy)	Who can access this resource — including other accounts
Permissions boundary	Users or roles	The maximum permissions an identity can ever have
Service control policy (SCP)	Organization root, OUs, accounts	The maximum permissions for accounts in an organization
Session policy	A role session	Further restricts a single session

How AWS evaluates a request

By default, everything is implicitly denied.
An explicit Deny in any applicable policy always wins.
Otherwise, the request is allowed only if an Allow exists and nothing caps it — SCPs, permissions boundaries and session policies must all permit the action too.

Explicit DENY anywhere?          → DENIED
Allowed by SCPs (if in an org)?  no → DENIED
Allowed by a resource policy or identity policy?  no → DENIED
Within permissions boundary / session policy (if set)?  no → DENIED
                                  → ALLOWED

Watch out

SCPs and permissions boundaries never grant permissions — they only set limits. An identity still needs an Allow from an identity- or resource-based policy.

Least privilege in practice

Start from AWS managed policies only for quick starts; move to customer-managed policies scoped to specific actions and resources.
Use conditions to narrow access (e.g. require MFA, restrict to a VPC endpoint, require tags).
Use IAM Access Analyzer to find resources shared outside your account and to generate least-privilege policies from CloudTrail activity.
Review with the credential report (all users and credential status) and last accessed information (unused permissions to remove).

Credentials and MFA

Passwords for console access, with a password policy (length, complexity, rotation).
Access keys (access key ID + secret) for CLI/SDK — avoid for humans; rotate if you must use them.
MFA — virtual authenticator apps, FIDO security keys or hardware tokens. Enforce with a policy condition such as "aws:MultiFactorAuthPresent": "true".

Tip

Never put access keys in code or on EC2 instances. Give the instance an IAM role (via an instance profile), and the SDK picks up temporary credentials automatically.

Exam patterns

"An application on EC2 needs to read from S3" → IAM role attached to the instance.
"Prevent developers from ever granting themselves admin" → permissions boundary.
"Prevent any account in the organization from disabling CloudTrail" → SCP.
"Allow another AWS account to read objects in a bucket" → bucket policy naming that account (resource-based), or a cross-account role.
"Require MFA for deleting resources" → policy condition on MFA.

Written by Bipin Singh

Senior Full-Stack Engineer · AI & AWS. I design and run production systems on AWS — serverless, data and AI.

Work with me