Cram sheet — Manage Azure subscriptions and governance

The heaviest topic in the bank — fifty-nine questions across seven objectives — and the one where exact numbers earn marks. Locks, tags and management groups all have published limits, and the command line uses names the portal does not.

Locks: two levels, two sets of names

• Note the command-line spelling: CanNotDelete, with a capital N. It is a favourite of question writers precisely because the portal never shows it.
• A ReadOnly lock is described as similar to restricting all authorized users to the permissions the Reader role provides.
• Locks inherit downwards: apply one at a parent scope and every resource inside it inherits the same lock, including resources added later. The most restrictive lock in the chain takes precedence.
• Locks are a control-plane control. They protect a resource from changes but do not restrict how it performs its function — a ReadOnly lock on a database server still permits data to be written inside its databases.

Tags: the numbers

• Maximum 50 tag name-value pairs per resource, resource group, and subscription — each, not combined.
• Tag name limit 512 characters; tag value limit 256 characters. Storage accounts are the exception: their tag name limit is 128.
• Resources do not inherit tags applied to a resource group or a subscription. If a stem asks for inherited tagging, the answer is a policy that applies them, not the tag itself.
• Need more than 50? The documented workaround is a JSON string as a single tag value.

Management groups: the numbers

• A single directory supports 10,000 management groups.
• A management group tree supports up to six levels of depth — and that depth does not count the root.
• Each management group and each subscription supports only one parent.
• The root management group is named Tenant root group by default, its ID is the same value as the Microsoft Entra tenant ID, and it cannot be moved or deleted — unlike every other management group.

Resource groups hold metadata, not resources' locations

• A resource group stores metadata about the resources, and the location you give it is where that metadata is stored — which is why the choice can matter for compliance.
• Resources inside a resource group can be in different regions. A resource group is not a region boundary, and a stem that implies otherwise is testing exactly this.
• Each resource belongs to exactly one resource group at a time; moving it is an explicit operation, not a property you edit.

Policy governs state; RBAC governs actions

This is the cleanest statement of the boundary, and it is worth memorising in the documentation's own terms:

• Azure Policy ensures that resource state is compliant to your business rules without concern for who made the change or who has permission to make a change.
• Azure RBAC focuses on managing user actions at different scopes.
• And the sentence that decides the hardest questions in this topic: even if an individual has access to perform an action, if the result is a non-compliant resource, Azure Policy still blocks the create or update. Permission is not sufficient. Compliance is a second gate.

Policy effects are evaluated in order

The order matters because an earlier effect can prevent a later one from ever firing:

1. disabled — checked first, to decide whether the rule is evaluated at all.
2. append and modify — either can alter the request, and that change may stop an audit or deny from triggering.
3. deny — evaluated before audit, which prevents double logging of a resource that was refused.
4. audit, then manual, then auditIfNotExists.

A policy assignment governs the state a resource may be in. It never grants, denies or interprets a person's access — that is RBAC's job, and mixing them is the most common wrong answer in this topic.

Budgets do not stop anything

• Notifications fire when a threshold is exceeded. Resources are not affected and consumption is not stopped. A budget is an alerting construct, not a spending cap.
• Cost and usage data is typically available within 8 to 24 hours, and budgets are evaluated against it every 24 hours. A budget is not a real-time control either.
• Budgets reset automatically at the end of each period — monthly, quarterly or annually — for the same amount. When a budget expires, it is automatically deleted.

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.