1.1 IAM Fundamentals — Users, Groups, Roles, and Policies

Quick Answer: AWS Identity and Access Management (IAM) controls WHO can do WHAT on WHICH resources. Use users for human identities, groups to organize users, roles for temporary credentials (EC2, Lambda, cross-account), and policies to define permissions. Always apply least privilege and never use the root user for daily operations.

IAM Overview

AWS Identity and Access Management (IAM) is a global service that controls authentication (who are you?) and authorization (what may you do?) for every AWS Application Programming Interface (API) call. IAM itself is free — you pay only for the resources your identities consume. On the SAA-C03 exam (65 questions, 130 minutes, 720/1000 to pass), Domain 1 is the single largest block at 30%, so IAM mechanics are worth memorizing cold.

Key Characteristics

IAM Users vs. Groups

An IAM user is a long-lived identity for one person or application. A group is a container that attaches the same policies to many users at once.

IAM Roles

An IAM role is an identity with permissions that a trusted principal assumes to receive temporary credentials from the AWS Security Token Service (STS). Roles are the secure-by-default answer whenever a workload — not a human — needs access.

When to Use Roles (high-yield)

How Assumption Works

1. A principal calls sts:AssumeRole.
2. STS checks the role's trust policy (who may assume it).
3. STS returns temporary credentials (access key, secret key, session token).
4. Credentials expire after 15 minutes to 12 hours (configurable).

On the Exam: When an EC2 instance must reach S3, DynamoDB, or any AWS service, the answer is almost always "attach an IAM role." Storing long-term access keys on an instance is always wrong.

IAM Policies

Policies are JSON documents. Memorize the elements and evaluation order.

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

Policy Types

• AWS managed — prebuilt (e.g., ReadOnlyAccess).
• Customer managed — your reusable policies.
• Inline — embedded in one entity (1:1).
• Resource-based — attached to a resource (S3 bucket policy, KMS key policy).
• Permission boundary — caps the maximum an identity can ever have.

Evaluation Logic (memorize)

1. Explicit Deny anywhere → request denied. Deny always wins.
2. Service Control Policy (SCP) must allow (if in an Organization).
3. Permission boundary must allow (if set).
4. Identity-based policy must allow (at least one).
5. Resource-based policy can grant access independently.

Key Rule: If nothing explicitly allows an action, it is implicitly denied. An explicit Deny overrides every Allow.

The Root User

The root user is the account's founding email identity with unrestricted power. Best practices: enable MFA immediately, create no access keys for root, and reserve it for the handful of root-only tasks (changing account settings, closing the account). Use IAM Access Analyzer to surface unintended external access and CloudTrail to audit every call.

Identity-Based vs. Resource-Based Policies

The exam repeatedly tests the difference between the two policy attachment styles. An identity-based policy attaches to a user, group, or role and says "this identity may do X." A resource-based policy attaches to a resource — an S3 bucket policy, an SQS queue policy, a KMS key policy, or a Lambda function policy — and names a Principal that may act on that resource. Resource-based policies are the only practical way to grant cross-account access without first creating a role, and an S3 bucket policy is the standard answer when a question says "allow another AWS account to read this bucket."

When the request and the resource live in the same account, access is granted if either the identity-based policy or the resource-based policy allows it (and nothing denies it). When they live in different accounts, both sides must allow: the resource policy must name the external principal, and that principal's identity policy must permit the action. Memorizing this dual-allow rule prevents the classic mistake of fixing only one side of a cross-account grant.

IAM Identity Center and Federation

For human access at scale, AWS now steers customers toward IAM Identity Center (formerly AWS Single Sign-On) instead of individual IAM users. Identity Center connects an external identity provider — Active Directory, Okta, or any SAML 2.0 / OIDC source — and maps groups to permission sets that become roles in each account. The result is centralized, short-lived, MFA-protected console and CLI access with no long-lived keys to leak. On the exam, "hundreds of employees need least-privilege access across many accounts" points to IAM Identity Center with permission sets, not to creating an IAM user per person in every account.

Common IAM Exam Traps

• Long-lived access keys on EC2 — always replaced by an instance-profile role.
• Making a bucket public to solve an access problem — almost never correct; use a bucket policy or VPC endpoint policy instead.
• Assuming an SCP grants access — it only caps; IAM still must allow.
• Forgetting that Deny wins — an explicit Deny in any policy layer cannot be overridden by any Allow.
• Believing IAM is Regional — it is global; a role works in every Region without duplication.