Identity and access management (IAM) decides who can do what to which resource in a cloud account. You sign in (authentication), then the cloud checks a set of rules to allow or block each action (authorization). Learn three ideas well and you are ahead of most freshers: the difference between a user and a role, how least privilege keeps you safe, and the rule that an explicit deny always wins. The words differ across AWS, Azure and Google Cloud, but the shape is the same.
A college pass-out or new IT employee who has heard the word IAM in a job description and wants to actually understand it. No prior cloud security knowledge needed. If you have read Part 9 on choosing a provider, this is the natural next step.
Picture your first day at a large office. Reception does not hand you a master key to every room. They give you a badge. That badge opens the front door and your floor, maybe the cafeteria, and nothing else. The server room stays locked. If you try the finance vault, the reader beeps red and the door stays shut. Nobody is insulting you. The building simply runs on the idea that each person gets exactly the access their job needs, and not one door more.
Cloud IAM is that badge system for your AWS, Azure or Google Cloud account. It is the part of the cloud that answers one question, over and over, millions of times a day: is this person or this program allowed to do this specific thing right now? Get IAM wrong and either nothing works or everything is exposed. Get it right and it fades into the background, which is exactly what good security does.
What IAM actually is
Strip away the branding and every cloud IAM system is the same three nouns plus a verb. There is a principal (the who: a person, an application, or a service), a permission expressed through a policy or role (the what: read this, delete that), and a resource (the on what: a storage bucket, a virtual machine, a database). The cloud reads the rules and returns one verb: allow or deny.
Two halves people mix up: authentication and authorization
These two words sound alike and get swapped in interviews all the time. Authentication proves who you are. That is the badge scan at the door, or your password plus a code from your phone. Authorization decides what you are allowed to do once you are inside. That is the badge reader at each room saying yes or no.
A handy memory trick: authentication is the front door, authorization is every door after it. You can be perfectly authenticated and still get blocked everywhere because you have no permissions. That is not a bug. On a fresh cloud identity, the default answer to almost everything is no, and you grant access deliberately from there.
The building blocks: users, roles and policies
Users are long-term, roles are temporary
A user is a fixed identity with long-lived credentials, like a named badge that sits in your wallet. A role is different: it carries permissions but has no permanent owner. Anyone or anything trusted to use it borrows it for a short while and is handed temporary credentials that expire, often within an hour. Think of a role as a visitor lanyard at the front desk. It grants real access while you wear it, then it is returned and the credentials stop working.
This is why teams prefer roles for anything that is not a human at a keyboard. An application running on a virtual machine should assume a role and receive short-lived credentials, rather than carry a permanent secret key that could leak and stay valid forever. A leaked temporary credential is a problem for an hour. A leaked permanent key is a problem until someone notices, which can be months.
A policy is the written rule
A policy is the document that lists what is allowed or denied. It pairs an action (such as read an object) with a resource (such as one specific bucket). Attach the policy to a user or role and those rules now apply to it. The single most useful habit you can build early is to scope both the action and the resource narrowly, instead of granting a wildcard that means every action on everything.
The three big providers use different words for the same furniture. Keep this table near you. Once you see that the columns line up, switching clouds stops being scary.
| Idea | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
| The who | IAM user, IAM role | User, service principal, managed identity | Principal, service account |
| The directory of identities | IAM + IAM Identity Center | Microsoft Entra ID | Cloud Identity |
| The rule set | IAM policy | Azure role (RBAC) + Entra role | IAM role + allow policy |
| Pre-built broad roles | AWS managed policies | Built-in roles | Basic and predefined roles |
On your first real task you will be handed an account or a project with permissions already set. When something fails with a permission error, your team does not want a guess. They want you to say which principal tried which action on which resource, and which rule blocked it. That sentence alone marks you as someone who understands IAM rather than someone who just clicks until it works. It is also the fastest way to stop being blocked.
How a request is judged: deny beats allow
Here is the rule that trips people up and shows up in interviews. When you ask the cloud to do something, it does not stop at the first yes. It gathers every rule that could apply and runs a fixed order of checks. On AWS the logic is: if any policy says deny, the answer is deny, full stop. If no deny applies and at least one policy says allow, the answer is allow. If nothing says allow at all, the answer is still deny, called an implicit deny. So there are two ways to be blocked: someone wrote an explicit deny, or nobody ever wrote an allow.
When the answer is no, AWS does not leave you guessing. The error reads roughly like this: the user arn ending in your-name is not authorized to perform s3:GetObject on the resource your-bucket because no identity-based policy allows the action. Read that sentence slowly. It hands you the principal, the action, the resource, and the reason. Newer messages even include the name of the policy that blocked you. Most permission tickets are solved by reading this line carefully rather than randomly adding access.
On Azure there are two separate role systems, and freshers lose hours to this. Entra ID roles manage identity objects like users and groups. Azure roles (RBAC) manage cloud resources like virtual machines and storage. A Global Administrator in Entra ID does not automatically get access to your Azure resources. The person who can reset everyone in the company can still get an access error opening a storage account, until an Azure role is assigned to them. Two systems, two assignments. Knowing this early saves a confusing afternoon.
If a user has one policy that allows an action and another policy that denies it, what happens?
The action is denied. In AWS policy evaluation an explicit deny always overrides any allow, no matter how many allows exist or where they come from. Strong answer adds the second half: if no policy explicitly denies and no policy allows either, the request is still denied through an implicit deny, because access starts at no and is only opened by an explicit allow. Saying both halves shows you understand the model, not just the headline.
Worked example: least privilege, made concrete
Least privilege sounds abstract until you size it. Say a reporting app only needs to read files from one bucket named team-reports. A lazy grant gives it s3 colon star on every bucket: that is roughly hundreds of possible actions across every bucket in the account, including delete. A least-privilege grant gives it exactly two actions, GetObject and ListBucket, on exactly one resource, team-reports. If that app key ever leaks, the blast radius drops from your entire storage estate to read-only on a single bucket. Same app, same feature, a fraction of the risk. The cost of doing it right is a few extra minutes writing a tighter policy.
On an AWS free tier account, open the IAM console and create a new role or user with the AmazonS3ReadOnlyAccess managed policy attached. Create a small bucket and upload a text file. Using that identity, try two things: read the file, then try to delete it. The read succeeds. The delete returns an access denied error naming s3:DeleteObject as the action that is not allowed. How to check the result: the wording in the error should match the principal and action you used. You just watched least privilege work in practice. As a bonus, paste the same scenario into the IAM Policy Simulator and confirm it predicts the same allow and deny before you ever run the action.
One opinion: stop reaching for the admin role
Plenty of tutorials, and more than a few senior engineers under deadline, will tell a new joiner to attach a broad administrator policy or the Google Cloud Owner role just to get unblocked, then tighten it later. I disagree, and I have seen where it leads. Later never comes. That temporary wide grant becomes permanent because nothing breaks, so nobody revisits it, and a year on the account is full of identities that can do far more than their job needs. Every one of them is a bigger target.
The better habit is to start from nothing and add the one or two permissions an error asks for, one at a time. It feels slower for the first hour and pays you back for the life of the account. Cloud providers even build tools for this: access analyzers watch what an identity actually uses and suggest a policy shaped to that real usage. Lean on them. The basic Owner and Editor roles on Google Cloud, and blanket administrator policies on AWS, are fine for a throwaway learning sandbox and a poor habit everywhere else. Convenience today is somebody else incident next quarter.
FAQ
Is IAM the same thing as a password manager?
No. A password manager stores your secrets on your side. IAM lives inside the cloud account and decides what each identity is allowed to do after it signs in. They solve different problems and you often use both.
Do I need to memorize every policy action for a job?
No, and nobody does. You need the model: principal, permission, resource, and the rule that deny wins. The exact action names you look up in the docs or read straight from the error message. Understanding beats memorizing here.
What is a service account or service principal?
It is an identity for a program rather than a person. Your application uses it to call cloud services without a human typing a password. Treat its permissions with the same least-privilege care you give a human, because leaked machine credentials are a common way accounts get breached.
Why did my access break right after it was working?
Common causes are a newly added deny rule somewhere above you, a permission boundary or organization policy capping what you can do, or temporary credentials that simply expired. Read the full error, note the action and resource, and check whether a broader policy is denying you rather than your own.
Should a fresher learn IAM on one cloud or all three?
Learn one deeply, ideally the one your target job uses, then skim how the other two rename the same parts. The mental model transfers almost completely. Spreading thin across three at once mostly produces confusion about which word belongs to which cloud.
Where this leaves you
IAM is not the scary part of the cloud once you hold the shape of it. Someone or something asks to do a thing to a resource, the cloud reads the rules, deny wins if present, and no rule at all still means no. Prefer roles over long-lived keys, scope your permissions tight, and read the error instead of guessing. Do that and you will fix permission problems faster than people twice your experience who never slowed down to learn the model. Next up, we turn permissions into running software with containers and Kubernetes, explained without the jargon.
References
AWS, Troubleshoot access denied error messages
Microsoft, Azure roles vs Entra ID roles
Google Cloud, IAM roles and permissions overview
About The Author
DrJha