1. AWS-Recommended IAM Best Practices

AWS provides official best practices for IAM. These are frequently tested on the exam:


1. Lock Away the Root User Access Keys

  1. Do NOT create access keys for the root user
  2. Enable MFA on the root user immediately
  3. Use the root user only for tasks that require it


2. Create Individual IAM Users

  1. Never share credentials between people
  2. Each person gets their own IAM user
  3. This provides individual audit trails in CloudTrail


3. Use Groups to Assign Permissions

  1. Attach policies to groups, not individual users
  2. Add/remove users from groups to manage permissions
  3. Makes permission management scalable


4. Grant Least Privilege

  1. Start with minimum permissions and grant additional as needed
  2. Do NOT start with full access and then try to restrict
  3. Use AWS Access Analyzer to identify unused permissions
  4. Regularly review and remove unnecessary permissions
Principle of Least Privilege Every user, role, and application should have ONLY the minimum permissions necessary to perform their specific task. This is the most important IAM security principle and is tested extensively on the exam.

5. Enable MFA (Multi-Factor Authentication)

  1. Enable MFA for the root user — mandatory best practice
  2. Enable MFA for all IAM users, especially those with console access
  3. Use a virtual MFA device (Google Authenticator, Authy), hardware MFA, or U2F security key


6. Use Roles for Applications on EC2

  1. Never embed access keys in application code or EC2 instances
  2. Use IAM roles via Instance Profiles
  3. Roles provide temporary, auto-rotated credentials


7. Rotate Credentials Regularly

  1. Rotate access keys periodically
  2. Use the IAM Credential Report to audit credential age
  3. Set a password policy that requires rotation


8. Use IAM Access Analyzer

  1. Identifies resources shared with external entities
  2. Validates policies against best practices
  3. Generates least-privilege policies based on access activity

2. Password Policy

IAM lets you set a custom password policy for your account:

  1. Minimum password length
  2. Require specific character types (uppercase, lowercase, numbers, symbols)
  3. Allow/prevent users from changing their own passwords
  4. Require password expiration (e.g., every 90 days)
  5. Prevent password reuse (remember the last N passwords)

3. MFA Deep Dive

4. IAM Security Tools

IAM Credential Report (Account-Level)

  1. Lists all IAM users and the status of their credentials
  2. Shows: password age, access key age, MFA status, last login, last key usage
  3. Use it to audit and identify unused or old credentials
  4. Download as CSV from the IAM Console


IAM Access Advisor (User-Level)

  1. Shows the services a specific user has accessed and when they last accessed them
  2. Helps you identify unused permissions that can be removed
  3. Supports the principle of least privilege


IAM Access Analyzer

  1. Identifies resources that are shared with external entities (e.g., S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues)
  2. Helps you identify unintended access from outside your account
  3. Can generate least-privilege policies based on CloudTrail access logs
  4. Validates your policies against IAM best practices

5. IAM Security Tools Comparison

6. IAM Conditions

Conditions let you add fine-grained control to your policies. Common condition keys:

  1. aws:SourceIp — Restrict access to specific IP addresses or CIDR ranges
  2. aws:RequestedRegion — Restrict actions to specific AWS Regions
  3. aws:MultiFactorAuthPresent — Require MFA for certain actions
  4. aws:PrincipalTag — Match tags on the IAM principal
  5. aws:CurrentTime — Restrict access based on time of day
  6. s3:prefix — Restrict S3 actions to specific key prefixes


Example: Require MFA for Certain Actions

{
  "Effect": "Deny",
  "Action": "ec2:TerminateInstances",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}


This denies terminating EC2 instances unless MFA is present in the session.

7. IAM Permission Boundaries

A permissions boundary is an advanced feature that sets the MAXIMUM permissions an IAM user or role can have. It does NOT grant permissions — it limits what policies CAN grant.

  1. Permissions boundary + Identity policy = effective permissions (intersection of both)
  2. Used to delegate administration safely — allow junior admins to create users/roles but cap their maximum permissions
  3. Only applies to users and roles, NOT groups

8. When to use

Use IAM best practices when you need to control who can access what in your AWS account securely.

Common scenarios:

  1. Setting up a new AWS account — Apply security foundations from day one.
  2. Managing users and permissions — Ensure least privilege across the organization.
  3. Audit and compliance — Prove access controls meet security standards.
  4. Multi-account environments — Centralize identity management across AWS Organizations.
  5. Incident prevention — Reduce attack surface by limiting unnecessary access.


Permission Boundaries Analogy Think of a permission boundary as a fence around a yard. The identity policy defines where you can walk inside the yard. The boundary defines the edges of the yard. Even if your identity policy says you can go anywhere, you cannot go beyond the fence (boundary).
Exam Tip The exam tests: Credential Report = account-level audit. Access Advisor = user-level last accessed. Access Analyzer = find external sharing. For security questions, the answer often involves: least privilege, MFA, roles instead of keys, and Credential Report for auditing. Permission Boundaries are tested as a way to limit delegated admin powers.