Identity is the part of cloud that transfers worst between providers, because the combination models are genuinely different. An engineer who is expert on one cloud and applies its mental model to another will confidently grant far more than they intended.

The evaluation order runs: default deny, then a scan of every applicable policy for an explicit deny, then two organisation-level layers that can only bound, then the resource policy, the identity policy, the permissions boundary and the session policy — the last three as an intersection.

• An explicit deny anywhere ends evaluation. At any layer, in any policy type. This is the one absolute rule.
• Organisation-level policies subtract, never add. Attaching a policy at the top of the hierarchy grants nothing to anybody; it only removes what identity policies could otherwise permit. Engineers arriving from the additive clouds get this backwards and are surprised that their org-wide grant did nothing.
• A resource policy can allow on its own — a bucket can grant access to a principal whose own identity policy says nothing about it. Whether boundaries still constrain that depends on which form of principal is named in the resource policy, which is a genuinely subtle piece of the specification and worth reading once carefully.
• Two things always require an explicit allow for the principal, regardless: a role's trust policy, and an encryption key's policy. That second one is why “I have decrypt permission in my identity policy and I am still getting access denied” is probably the most-asked question on that platform — the key has its own policy and it has not heard of you.

The other two major clouds are purely additive. Your effective permission is the union of every grant that applies to you, inherited down the resource hierarchy. There is no boundary, no intersection, and no way for a narrow grant at a low scope to restrict a broad one above it.

Stated as a rule that catches people: a broad grant at the top of the hierarchy makes every narrower grant beneath it irrelevant. Assigning someone a contributor role at the subscription level and then a reader role on one resource group inside it does not restrict them — they are a contributor everywhere in that subscription, and the reader assignment is noise.

• Both clouds have added a deny primitive later, and in both cases it is a separate object type rather than a policy statement. On one, deny assignments exist and win — but you generally cannot author them directly; they are created on your behalf by higher-level services. On the other, deny policies are a distinct, opt-in object that most estates never use.
• So the honest summary: one cloud gives you a deny you can write anywhere, and the other two give you a deny that exists and that you probably cannot reach for.

• Constrain the pass-role equivalent on whichever cloud you are on. It is the highest-value single control in cloud identity.
• Use short-lived, federated credentials rather than stored keys. A credential that expires in an hour is worth far less to an attacker than one that never does, and workload identity federation removes the class rather than protecting it.
• Compare granted against used permissions. Every cloud has an analyser for this and the gap is routinely 95%. It is the fastest blast-radius reduction available.
• Set an organisation-level guardrail so that even a manual console action cannot create the forbidden state. Detecting it four hours later is worth much less.
• And run the escalation tooling against your own account. Open tools enumerate the known escalation paths per cloud. An afternoon doing that is genuinely revealing and it is a very good thing to have done before an interview.