On this page
TL;DR
IAM collapses to four words: who can do what to which thing. Master how a request is evaluated and why roles beat long-lived users, and you close the gap where most cloud breaches actually start.
Why IAM is the foundation of cloud security
Almost every cloud breach you read about starts the same way: a credential or permission that was broader than it needed to be. Not a clever zero-day, just an access key with too much power, or an S3 bucket open to everyone. IAM (Identity and Access Management) is the system that decides who can do what. Get it right and most attack paths simply close.
It feels intimidating because of the jargon, principals, policies, roles, ARNs. But underneath, IAM answers exactly one question for every single request:
Is THIS identity allowed to perform THIS action on THIS resource, yes or no?
Who this is for
Beginners. If you've ever gotten an "Access Denied" and not known why, this article is for you.
The four words: who, what, which, allow/deny
- Principal, the identity making the request. A human user, or (better) a role assumed by a service or app.
- Action, the specific operation, namespaced by service:
s3:GetObject,ec2:StartInstances. - Resource, the exact thing, named by an ARN (Amazon Resource Name):
arn:aws:s3:::my-bucket/*. - Effect,
AlloworDeny. Everything is denied by default; you grant access explicitly.
How a request is actually evaluated
Every API call runs this gauntlet. Default is deny; an explicit Deny always wins over any Allow.
- 1
Start from DENY
Nothing is allowed until something explicitly allows it. This is the single most important IAM rule.
- 2
Look for a matching Allow
AWS gathers every policy attached to the principal and the resource, and checks for an Allow matching this action + resource.
- 3
Check for any explicit Deny
If any policy says Deny for this request, it's denied, full stop. An explicit Deny beats any Allow.
- 4
Decide
Allowed only if there is a matching Allow and no matching Deny. Otherwise: Access Denied.
What a policy actually looks like
A policy is just JSON listing statements of effect + action + resource. This one lets a principal read objects from one bucket, and nothing else:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::reports-bucket/*"
}
]
}Read it as a sentence: *Allow the action s3:GetObject on every object in reports-bucket.* No write, no delete, no other bucket. That's least privilege, grant exactly what's needed, nothing more.
Users vs roles: prefer roles, always
The biggest practical upgrade you can make: stop handing out long-lived access keys, and use roles instead.
| IAM User (keys) | IAM Role | |
|---|---|---|
| Credentials | Long-lived access key | Short-lived, auto-rotated |
| If leaked | Valid until you notice + revoke | Expires in minutes/hours |
| Best for | Rare human/CLI cases | Apps, services, EC2, Lambda, CI |
| Rotation | Manual (often forgotten) | Automatic |
The #1 cloud security mistake
Hardcoding long-lived access keys in code, config, or a Git repo. Leaked keys are the most common breach vector. Use roles so credentials are temporary and rotate themselves.
Common mistakes that cost people (a lot)
- 1Using the root account for daily work. Lock it away, enable MFA, and never use it for routine tasks.
- 2**Granting
*permissions "to make it work."**Action: "*"onResource: "*"is admin-over-everything. Scope it down. - 3Long-lived access keys in code or Git. Use roles and short-lived credentials. Scan repos for leaked keys.
- 4No MFA on human users. A password alone is one phishing email away from compromise.
- 5Never auditing. Permissions accumulate. Review and remove what's unused, least privilege is a habit, not a one-time setup.
Where to go next
The whole article in 6 lines
- IAM answers one question: can THIS identity do THIS action on THIS resource?
- Four parts: principal, action, resource, effect (Allow/Deny).
- Everything is denied by default; you grant access explicitly.
- An explicit Deny always beats an Allow.
- Practice least privilege, grant exactly what's needed, nothing more.
- Prefer roles (short-lived credentials) over users with long-lived keys.
- Go deeper: Service Auth & IAM.
- Related read: Zero Trust Networking, where IAM meets the network.
- See it in context in the Cloud Engineer path.
You got an unexpected "Access Denied" or you're deciding how to grant access. What now?
Check your understanding
1. According to the article, what single question does IAM answer for every request?
2. Why does the article say to prefer roles over long-lived access keys?
Frequently asked questions
What question does IAM actually answer?
Underneath all the jargon, IAM answers exactly one question for every request: is this identity allowed to perform this action on this resource, yes or no. Once you see it as who can do what to which thing, the principals, policies, and ARNs stop feeling intimidating.
What does least privilege mean in practice?
Least privilege means granting exactly the permissions needed and nothing more. For example, a policy that allows only s3:GetObject on objects in one bucket gives read access to that bucket and no write, no delete, and no access to any other bucket.
Why are roles better than access keys?
The biggest practical upgrade you can make is to stop handing out long-lived access keys and use roles instead, because roles provide temporary credentials that rotate themselves. Long-lived keys hardcoded in code, config, or a Git repo are the most common breach vector when they leak.
Why do so many cloud breaches start with IAM?
Almost every breach begins with a credential or permission broader than it needed to be, such as an access key with too much power or a bucket open to everyone, rather than a clever zero-day. Getting IAM right and applying least privilege closes most attack paths before they can be used.
Was this article helpful?
Want to learn this properly?
Reading is a start. Identity & access is a full interactive lesson in the Cloud Engineer path, with real terminal labs, production scenarios, and a completion record.