IAM & Access Management

1. IAM Overview

AWS Identity and Access Management (IAM) is a global service (not region-specific) that controls:

• Authentication — Who you are (verifying identity via login or credentials)
• Authorization — What you can do (permissions granted via policies)

IAM is free — no charge for creating users, roles, groups, or policies.

---

2. IAM Core Components

---

3. Root Account

Created automatically when you first sign up for AWS. Has complete, unrestricted access to every AWS resource and billing function.

Root account should ONLY be used for:

• Closing the AWS account
• Changing the AWS support plan
• Changing the payment method
• Enabling IAM access to the Billing console
• Restoring IAM administrator access

Root account should NEVER be used for:

• Daily administrative tasks
• Programmatic API or CLI calls
• Application access

Protect root with MFA — this is one of the most commonly tested best practices on CLF-C02.

---

4. IAM Users

Individual identities for humans or applications needing long-term access. Two credential types:

Best practices for users:

• Create one IAM user per person — never share credentials
• Never embed access keys in application source code
• Rotate access keys regularly
• Delete or deactivate unused users immediately

---

5. IAM Groups

Collections of IAM users. Attach a policy to the group — all members automatically inherit those permissions.

Key rules:

• You cannot nest groups (no groups inside groups)
• A user can belong to multiple groups and inherits permissions from all
• Groups are for organizational convenience — they are not identities and cannot log in

---

6. IAM Roles

A role is an identity that can be assumed by AWS services, users, or applications. Roles provide temporary security credentials via AWS STS (Security Token Service) — no long-term passwords or access keys are stored anywhere.

Why roles instead of users for services:

• No static access keys to rotate or accidentally expose in code
• Credentials are automatically rotated by STS
• Fine-grained permissions tailored to each service's needs

Common role use cases:

---

7. IAM Policies

JSON documents that define what actions are allowed or denied on which resources:

Policy types:

---

8. Policy Evaluation: How AWS Decides Allow or Deny

When AWS receives an API request, it evaluates all applicable policies in this order:

1. Explicit DENY in any policy — request is immediately denied (highest priority)
2. SCP — if the account's Organization SCP does not allow the action, denied
3. Resource-based policy — if the resource policy grants access, may be permitted
4. Identity-based policy — the user/role must have an Allow for the action
5. Permission boundaries — if set, the final permission cannot exceed the boundary
6. Default: Implicit DENY — if no explicit Allow is found anywhere, the request is denied

Key rule to remember: An explicit Deny always wins over any Allow, no matter where the Allow comes from.

---

9. IAM Best Practices

---

10. IAM Identity Center (formerly AWS SSO)

• Centrally manage single sign-on (SSO) access to multiple AWS accounts and business apps
• Integrates with Active Directory, Okta, and SAML 2.0 identity providers
• Users sign in once and access multiple accounts without needing separate IAM users per account
• Recommended approach for enterprises with multiple AWS accounts

---

11. AWS Organizations and SCPs

Service Control Policies (SCPs):

• Applied at the Organizations level to accounts or OUs
• Define the maximum permissions available — they do not grant permissions themselves
• An SCP Deny overrides any IAM Allow in the account
• Used to enforce guardrails like "no one in this account can create resources outside us-east-1"

---

12. CLF-C02 Quick Reference