IAM is how a cloud decides who is signed in and what they may do. AWS IAM authenticates a principal, then authorizes with identity policies, resource policies, and optional Organizations guardrails. Azure RBAC assigns a role definition to a principal at a management-group, subscription, resource-group, or resource scope. Google Cloud IAM grants roles through allow policies that inherit down the organization-folder-project tree. Alibaba Cloud RAM grants inside an account; Resource Directory access control policies only cap what RAM may allow. Documentation as of 2026-08-30.

Human sign-in (IAM Identity Center, Microsoft Entra ID, Google identities, Alibaba Cloud accounts) is the front door. Authorization is the part that pages you at 2 a.m.

Evaluation, not slogans

AWS. After authentication, a request is allowed only if identity-based policies allow it, resource-based policies do not deny it, permissions boundaries and session policies still allow it, and Organizations SCPs and RCPs (when enabled) leave the action inside the ceiling. SCPs are principal-centric ceilings. RCPs are resource-centric ceilings. AWS documents that SCPs do not apply to the management account. IAM is eventually consistent: create a role and an immediate assume can fail until replicas catch up.

Azure RBAC. A role assignment is principal + role definition + scope. Scopes nest: management group, subscription, resource group, resource. Multiple assignments add. Deny assignments win. Microsoft documents the evaluation order, including Actions minus NotActions. Role assignment data is stored globally so a principal in another geography can manage an East Asia VM without waiting on a regional IAM store.

Google Cloud IAM. You never attach a raw permission to a person. You grant a role (predefined, custom, or basic) on a resource via an allow policy. Child resources inherit parent bindings. The effective policy is the union of the resource and its ancestors. Deny policies and principal access boundary policies can still block an allow. The IAM API is eventually consistent. Basic roles (Owner, Editor, Viewer) are documented as too broad for production.

Alibaba Cloud. RAM users, groups, and roles live in an account. Policies grant actions on resources. If the account is a Resource Directory member, access control policies on folders or members restrict what those RAM grants can take effect. The management account is not a member and is not bound by those policies. Documented default: one resource directory, limited folder depth and member count.

Engineering recommendation: prefer roles or managed identities for workloads. Long-lived access keys and client secrets are customer-held credentials on every shared-responsibility page.

Simulate or list before you grant more

AWS policy simulator (replace the ARN and action):

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/AppRole \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::example-bucket/object

EvalDecision=allowed means the identity policies on that role allow the call. It does not prove an SCP, an RCP, a bucket policy, a VPC endpoint policy, or KMS will agree. Treat a implicitDeny as “this role never had an Allow.” An explicit Deny elsewhere will not show if you only simulated the role.

Azure:

az role assignment list --assignee <object-id> --all \
  --query "[].{role:roleDefinitionName,scope:scope}" -o table

Read the widest scope first. Contributor at subscription scope makes a Reader assignment on one resource group irrelevant. Microsoft documents that additive behavior.

Google Cloud:

gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --format="table(bindings.role,bindings.members)"

Then list the folder and organization policies if the project has parents. A binding you do not see on the project can still be inherited.

Alibaba Cloud console: RAM > Permissions > Grants, plus Resource Directory > Access control policy. If RAM allows * and the folder ACP denies the same action, the deny ceiling wins.

Risks and limitations

Eventual consistency on AWS IAM and Google Cloud IAM will break scripts that create-then-use in the same second. Build a retry on assume-role or policy read.

Console “admin” shortcuts attach AdministratorAccess, Azure Owner, or roles/owner. Those are documented roles, not a requirement. They also bypass the least-privilege story in every landing-zone guide.

Federation maps a human to a cloud principal. It does not translate an Azure role into an AWS policy. Multi-cloud identity is a join you design.

If you lock the only break-glass role, you will need the IAM access lockout runbook. For the cross-cloud join, see Designing multi-cloud identity.

Official sources