Cram sheet — Manage access to Azure resources

Three objectives, twenty-five bank questions, and almost all of them turn on one of two things: the scope an assignment was made at, or the difference between what a role grants and what something else takes away.

The anatomy of an assignment

• A role assignment has exactly three elements: a security principal, a role definition, and a scope. Every RBAC question is really asking about one of the three.
• A security principal is a user, a group, a service principal, or a managed identity.
• Access is granted by creating an assignment and revoked by removing one. There is no deny switch in the middle of that, which is why the deny-assignment section below matters.

Scope: four levels, inherited downwards

• Scope can be set at four levels: management group, subscription, resource group, and resource.
• Lower levels inherit role permissions from higher levels. An assignment at the subscription reaches every resource group and resource beneath it, and there is no way to subtract from it with another role assignment.
• Because inheritance only flows one way, the fix for over-broad access is always to move the assignment down, never to add a narrower one alongside it.

The three roles you must be able to separate

The line between Owner and Contributor is role assignment, and it is the single most-tested distinction in this topic. If a stem says somebody must grant access to others, Contributor is wrong.

Deny assignments and custom roles

• A deny assignment blocks actions even if a role assignment grants them. Deny wins.
• You cannot create deny assignments yourself. They are created and managed by Azure — a deployment stack's deny settings are the one way an administrator causes one to exist.
• A tenant may hold up to 5,000 custom roles. (For Microsoft Azure operated by 21Vianet the limit is 2,000.) Custom roles can be shared between subscriptions that trust the same tenant.

Traps

Check yourself

Where these figures come from

Every figure above was read from the raw documentation below on the day this sheet was written. The sha1 is git hash-object over the bytes as fetched, so a doc that changes underneath this sheet can be detected rather than assumed.