Read as
Last updated: April 29, 2026
AWS IAM is the single largest source of cloud misconfigurations. It’s also AWS’s most powerful feature. Master it and you can architect least-privilege cleanly; fumble it and you ship the kind of blast radius that makes every new access key a production-impacting event.
AWS IAM is the single largest source of cloud misconfigurations. It’s also AWS’s most powerful feature. Master it and you can architect least-privilege cleanly; fumble it and you ship the kind of blast radius that makes every new access key a production-impacting event.
This module is the concrete IAM practitioner’s guide. You’ve seen the mental models in Module 1. Now we write actual policies, understand how AWS evaluates them, and cover the patterns that Indian fintech auditors, SOC 2 assessors, and your pen-testers actually look for.
The four core objects
- User — a named identity (typically human). Has long-lived credentials. Use sparingly; prefer SSO-federated access
- Group — a collection of users. Attach policies here; users inherit via membership
- Role — an assumable identity. No long-lived credentials; temporary credentials via STS. Used by workloads (EC2, Lambda) and humans (via AssumeRole)
- Policy — a JSON document describing permissions. Attached to users, groups, or roles (identity-based), or directly to resources (resource-based)
Want this for your team?
Custom team training + practitioner advisory
Beyond the free academy — we run private workshops, vCISO advisory, and red-team exercises tailored to your stack. For Indian SMBs scaling past their first hire.
Book team training call
Replies in 4 working hrs · India-only · Senior consultants