Cloud IAM Fundamentals: AWS vs Azure vs GCP Explained

Cloud identity and access management (IAM) is the system that decides which identity can perform which action on which resource, in which conditions. AWS, Azure, and Google Cloud all solve that same problem, but they model identity so differently that a control you rely on in one cloud may not exist in the next.

If you learn only one cloud's IAM console, you learn a vendor product. If you learn the underlying model, permission grants, policy attachment points, evaluation order, and guardrails, you can walk into any of the three and reason about who can do what. That is the skill hiring managers test in cloud security interviews, and it is the foundation of every other control you will build.

The four questions every cloud IAM system answers

Strip away the branding and all three providers answer the same four questions:

1. Who is the principal? A human user, a workload identity, a federated identity from an external provider, or a group of those.
2. What permissions are granted? Usually bundled into a role or a policy rather than assigned one permission at a time.
3. Where does the grant apply? The scope or attachment point, which may be a single resource, a project, a subscription, or an entire organization.
4. What can override the grant? Guardrails, explicit denies, and boundaries that cap what a grant can ever mean in practice.

Question four is where most engineers get lost, and where most real incidents originate. A permissive grant is only dangerous when nothing above it says no.

How the three clouds compare

Concept	AWS	Azure	Google Cloud
Identity store	IAM users and roles, IAM Identity Center for workforce SSO	Microsoft Entra ID	Google Cloud identities, service accounts, workforce and workload identity federation
Permission bundle	JSON policy (managed or inline)	Role definition with Actions and NotActions	Predefined, basic, or custom role containing permissions
Grant mechanism	Policy attached to identity or resource	Role assignment	Role binding inside an allow policy
Scope levels	Account, plus resource-level conditions	Management group, subscription, resource group, resource	Organization, folder, project, and many individual resources
Fine-grained conditions	Condition keys in the policy	Azure ABAC role assignment conditions	IAM Conditions on bindings
Org-wide guardrail	Service control policies (SCPs)	Azure Policy and management group structure	Organization policies, IAM deny policies, principal access boundary policies
Identity-level cap	Permissions boundary	No direct equivalent	Principal access boundary policy
Time-limited elevation	Role assumption with session duration	Entra Privileged Identity Management (PIM)	Temporary grants through conditions and role expiry

Read that table as a map of where a permission can come from. A cloud security review means tracing every row, not just the one you are most familiar with.

AWS: policies everywhere, deny wins

AWS grants permissions through JSON policy documents. Those documents can attach to an identity (an IAM user, group, or role) or to a resource (an S3 bucket, a KMS key, a Lambda function). Both count, which is why an S3 bucket can be publicly readable even when no user has been granted access to it.

The evaluation logic is the part worth memorizing. Every request starts as an implicit deny. An explicit allow in any applicable policy can flip that to allow. An explicit deny in any policy overrides every allow, no exceptions. When an identity is subject to an identity-based policy, a permissions boundary, and a service control policy at the same time, the effective permission set is the intersection of all three, as documented in the AWS policy evaluation logic reference.

Two AWS constructs confuse newcomers because neither one grants anything:

• Service control policies set the maximum permissions available to accounts in an AWS Organization. They do not grant. An SCP that allows an action simply declines to block it.
• Permissions boundaries set the maximum permissions an individual IAM user or role can have. They are the safe way to let application teams create their own roles without letting them create administrator roles.

Our deeper walkthrough of policy structure, role assumption, and least privilege lives in the AWS IAM security best practices guide.

Azure: roles assigned at a scope, identity governed separately

Azure splits the problem in two. Microsoft Entra ID handles the identity itself, who the user is, how they authenticate, what conditional access rules apply. Azure RBAC handles what that identity can do to Azure resources.

An Azure role assignment is a three-part object: a security principal, a role definition, and a scope. Scope is hierarchical across four levels, from management group down through subscription and resource group to an individual resource, and assignments inherit downward. Assigning Contributor at the management group level is a very different act from assigning it on one storage account, even though the console flow looks nearly identical.

Two Azure features matter disproportionately for security engineers:

• Azure ABAC adds conditions to a role assignment so access depends on attributes of the request, for example a blob's index tag, rather than on resource identity alone. Microsoft documents the model and its limits in the Azure ABAC overview.
• Privileged Identity Management (PIM) converts standing privilege into eligible, time-bound, approval-gated privilege. This is the single highest-value change most Azure tenants can make, because it shrinks the window in which a compromised admin account is actually an admin account. PIM requires a Microsoft Entra ID P2 license.

More Azure-specific detail sits in our Azure security fundamentals guide.

Google Cloud: bindings on a resource hierarchy, with layered guardrails

Google Cloud attaches an allow policy to a resource. That policy contains bindings, and each binding ties a role to a set of principals. Because resources sit in a hierarchy of organization, folders, and projects, a binding set high in the tree is inherited by everything beneath it.

Google then layers two guardrail policy types on top:

• Deny policies list principals and the permissions those principals cannot use, regardless of any role they hold. Deny overrides allow.
• Principal access boundary policies attach to a set of principals and define which resources those principals are allowed to reach at all.

When a request arrives, IAM evaluates the relevant allow, deny, and principal access boundary policies together, and if any of them says the access should not happen, access is refused. Google's deny policy documentation covers the rule syntax. Service accounts deserve special attention here, which is why we wrote a separate piece on GCP service account security and workload identity federation.

Least privilege in practice, not in theory

Least privilege is easy to say and hard to implement, because the permission a workload actually needs is rarely the permission someone requested. A workable approach that transfers across all three clouds:

1. Start from denial. Grant nothing by default and add permissions in response to evidence, not to tickets that say "needs admin for now."
2. Grant to workload identities, not to keys. Federated workload identity removes long-lived credentials from the picture entirely.
3. Measure what is actually used. All three clouds expose usage signals that show which granted permissions were never exercised. Unused permissions are the cheapest thing you will ever remove.
4. Cap privilege from above. Use SCPs and permissions boundaries in AWS, management group structure and Azure Policy in Azure, deny and principal access boundary policies in Google Cloud.
5. Make standing admin rare. Elevation should be requested, time-boxed, and logged. Permanent administrator assignments should be a short, reviewed list.
6. Review on a schedule. Access accumulates silently as people change teams. A recurring review is the only thing that reverses that drift.

Every one of these practices assumes identity is a control plane rather than a directory, which is exactly the shift described in our zero trust architecture guide.

Common IAM mistakes that show up in real assessments

• Wildcard actions in production policies. An action or resource wildcard that was fine in a sandbox becomes an audit finding once it reaches production.
• Long-lived static credentials. Access keys and service account keys checked into repositories or baked into container images remain a leading cause of cloud compromise.
• Grants made at the wrong scope. A role assigned at the subscription, organization, or management group level when a single resource group was the actual requirement.
• Ignoring resource-based policies. In AWS especially, reviewing identity policies alone gives you an incomplete picture of who can reach a resource.
• No break-glass plan. Tightening IAM without a tested emergency access path is how teams lock themselves out of their own tenant.
• Unmonitored role creation. If application teams can create roles freely and no boundary constrains them, privilege escalation is a matter of time.

Frequently asked questions

What is the difference between authentication and authorization in cloud IAM?

Authentication proves who a principal is, usually through a password plus a second factor, a certificate, or a federated token. Authorization decides what that proven identity is permitted to do. Cloud IAM systems handle both, but they are separate stages, and a strong authentication setup does nothing to limit an over-permissive authorization grant.

Which cloud has the most complex IAM model?

Complexity depends on what you are measuring. AWS has the most policy attachment points and the most intricate evaluation logic. Google Cloud has the most guardrail policy types layered on top of its allow policies. Azure has the simplest core role assignment model but splits identity governance into Entra ID features that carry their own licensing and configuration requirements.

Do I need to learn all three clouds to work in cloud security?

Most roles ask for depth in one cloud and working familiarity with at least one other. The concepts transfer well once you understand the underlying model, so a strong foundation in one provider makes the second one much faster to pick up. Multi-cloud environments are common enough that single-cloud knowledge limits which jobs you can take.

What is a permissions boundary and when should I use one?

A permissions boundary is an AWS feature that caps the maximum permissions an IAM user or role can have, regardless of what its identity policies grant. Use one when you want to delegate role creation to application teams without allowing them to create roles more privileged than their own.

How do I prove IAM skills without on-the-job experience?

Build and document real configurations. Set up a multi-account or multi-project environment, implement guardrails, deliberately break the configuration, and write up how you detected and fixed it. Documented lab work plus a relevant certification is a credible substitute for production experience when you are moving into the field.

How long does it take to get comfortable with cloud IAM?

The core concepts take days. Real fluency, meaning the ability to trace an unexpected permission back to its source across policy types, usually takes several months of hands-on practice. Structured labs shorten that curve considerably compared to reading documentation alone.

Build the skill, not just the vocabulary

IAM is where most cloud security work starts, and it is the area interviewers probe hardest, because it separates people who have read about the cloud from people who have configured it. The fastest way to close that gap is repeated hands-on practice across more than one provider.

PrimeSec Academy's 20-week Cloud and AI Platform Security Engineer program covers IAM across AWS, Azure, and Google Cloud through hands-on labs and 36 projects, backed by a defended capstone. See the full curriculum, check your fit with the eligibility quiz, or enroll now to start building.