Cloud IAM: least privilege that survives contact with teams

Roles, policies, boundaries and guardrails across AWS, GCP and Azure. The patterns that keep IAM from becoming a 2,000-policy swamp.

● Must know for interviews🔒 PROLesson·13 min read·Intermediate → Staff

IAMAWSGCPleast privilege

01The IAM mental model

✓What you will learn

Explain identity, resource and boundary policies and how a request is evaluated against them
Design account and project structure as a security boundary
Recognise the privilege escalation paths hidden in ordinary permissions
Use conditions and attribute-based access so policies stay small as teams grow
Right-size permissions with access analysis, not guesses

Every cloud IAM system answers one question per API call: may this principal perform this action on this resource under these conditions? A principal is a user, role or service account. An action is an API verb such as s3:GetObject. The answer comes from combining several policy types, and most IAM bugs are a misunderstanding of how they combine.

Concept	AWS	GCP	Azure
Isolation unit	Account	Project	Subscription
Org guardrail	SCP and RCP	Organization Policy	Azure Policy
Workload identity	IAM role + IRSA / Pod Identity	Service account + Workload Identity	Managed identity
Permission ceiling	Permissions boundary	IAM deny policies / conditions	Deny assignments
Unused-permission data	IAM Access Analyzer	Policy Intelligence recommender	Access reviews / PIM

One rule across clouds: the account or project is the blast radius. Put production, staging and each sensitive workload in their own unit. Cross-unit access is explicit, logged and rare. Policies inside an account will drift; a boundary between accounts holds even when they do.