AWS Identity and Access Management (IAM) controls who can do what on which resources. Every API call is authorized through IAM—master this before launching production workloads.
IAM building blocks
- Root user — account owner; use only for break-glass tasks
- IAM users — long-lived identities (prefer SSO/roles for humans in orgs)
- Groups — collections of users sharing permissions
- Roles — temporary credentials for services or federated users
- Policies — JSON documents listing Allow/Deny actions on resources
Authentication vs authorization
Authentication proves identity (password, MFA, access key). Authorization decides allowed actions via policies attached to users, groups, or roles.
Inspect your caller identity
aws sts get-caller-identity
aws iam list-attached-user-policies --user-name YOUR_SANDBOX_USERPractice: Perform IAM steps in the IAM Console or with the AWS CLI in a sandbox account only.
Replace YOUR_SANDBOX_USER with a learning user you created—not root.
Security baseline
Enable MFA on privileged accounts. Rotate access keys. Never embed keys in Python or Node.js source—use IAM roles on EC2/Lambda or environment variables from a vault.
Important interview questions and answers
- Q: What is IAM?
A: AWS service for managing authentication and authorization to AWS resources. - Q: Root vs IAM user?
A: Root owns the account; daily work should use least-privilege IAM users or roles.
Self-check
- Name the five IAM building blocks from this lesson.
- What is the difference between authentication and authorization?
Pitfall: Using root for daily Console work—create IAM identities immediately.
Interview prep
- IAM purpose?
Control authentication and authorization for AWS API access.
- Policy attachment?
Policies attach to users, groups, or roles to grant/deny actions on resources.