What is cloud IAM?
Identity and Access Management decides who — a person, a service, a machine — can do what to which resources. Every cloud action is checked against IAM policies. It is the security backbone of the entire cloud, and the thing attackers target first.
Why it matters
Most cloud breaches trace back to over-permissioned credentials, not exotic exploits. Get IAM right and a leaked key does limited damage; get it wrong and one credential opens everything. Designing least-privilege access is a core, high-stakes DevOps responsibility.
What to learn
- Users, groups, roles, and service accounts
- Policies and how permissions are evaluated
- Least privilege as the default
- Roles for machines and workloads, not long-lived keys
- Temporary credentials and assuming roles
- Auditing who can do what
- Avoiding wildcard permissions
Common pitfall
Attaching a broad * policy — full admin — to get something working, then never
tightening it. That credential becomes a skeleton key, and it will leak
eventually. Grant the specific actions a workload needs, start narrow and add
permissions when something genuinely fails, never the reverse.
Resources
Primary (free):
- AWS — IAM best practices · docs
- Google Cloud — IAM overview · docs
- AWS — Policy evaluation logic · docs
Practice
Create a role scoped to exactly one task — say read-only access to a single storage bucket — and attach it to a workload instead of using your own credentials. Try an action outside the scope and confirm it is denied. Done when the workload can do its job and nothing more.
Outcomes
- Explain identities, roles, and policy evaluation.
- Design least-privilege access for a workload.
- Use roles and temporary credentials instead of static keys.
- Audit and tighten over-broad permissions.