IAM & Security Fundamentals
The principle of least privilege, and how roles/policies enforce it instead of relying on long-lived credentials.
Principle of least privilege
Every identity (a person or a service) should have only the permissions it actually needs, nothing more — minimizing the blast radius if that identity's credentials are ever compromised.
Users, roles, and policies
A policy is a document defining what actions are allowed/denied on which resources. A role is an identity that can be assumed temporarily (by a person or a service) rather than a permanent set of credentials — assuming a role grants short-lived, automatically-expiring credentials, which is why cloud providers push roles over long-lived user access keys for anything automated.
Why roles beat long-lived keys
A long-lived access key, if leaked (committed to a public repo, logged accidentally), grants access until manually revoked. A role's temporary credentials expire on their own — usually within an hour — dramatically shrinking the window an attacker has if one leaks.
Defense in depth
IAM is one layer, not the only layer — network isolation (VPCs/security groups), encryption at rest and in transit, and audit logging (who did what, when) all work together, so that a failure in any single layer doesn't fully compromise the system.
Prerequisite
Assumes the networking vocabulary — IAM controls who can act, network configuration controls what's reachable, and both are needed together.