AZ-900 — The Azure Resource Hierarchy and the Governance Spine Management Groups, Subscriptions, Resource Groups, RBAC, Policy, Locks, and the Composite SLA
A hierarchy is not an org chart. It is a list of the places a rule can be written and a bill can be cut.
A hierarchy is not an org chart. It is a list of the places a rule can be written and a bill can be cut.
§I — Frame: the third grammar for the same idea
Two Cloud-rotation seats have already asked this question in two other languages.
The AWS seat on 02 August took the multi-account landing zone: an organization at the root, organizational units beneath it, accounts as the unit of isolation, service control policies as the ceiling that no permission inside an account can exceed. The GCP seat on 08 August took the same shape in Google's grammar: organization, folders, projects, and org-policy constraints inheriting down the tree.
Azure asks it a third time, and the answer looks close enough to both that a practitioner arriving from either will map it wrong on the first attempt. Getting the mapping right is worth more than any single fact in this lesson, because the whole management-and-governance domain, thirty to thirty-five percent of the exam, is written in this vocabulary.
Verified against the published objectives this morning: AZ-900 measures three areas. Cloud concepts at 25-30%, Azure architecture and services at 35-40%, and Azure management and governance at 30-35%. A score of 700 passes. Today's lesson sits across the second and third, which together are roughly seventy percent of the exam.
§II — The four tiers, and what each one actually is
Azure's hierarchy has four levels. Say them in order and then say what each one is for, because the exam asks the second question much more often than the first.
| Tier | What it is | What it exists to do |
|---|---|---|
| Management group | A container for subscriptions, nestable | Apply access, policy, and compliance across many subscriptions at once |
| Subscription | A logical unit of Azure services linked to an account | Billing unit, quota boundary, division of responsibility |
| Resource group | A logical container inside one subscription | Lifecycle grouping: deploy, update, and delete together |
| Resource | An instance of a service | The thing that costs money |
Four facts about that table are where the marks are.
The subscription is the billing unit. Every invoice and every set of billing reports comes out of a subscription. Organizations create multiple subscriptions primarily to separate bills, and secondarily to separate authority, since whoever creates a subscription becomes its administrator with full access to everything inside it. That second reason is the same argument the AWS seat made for multiple accounts.
Management groups nest. Resource groups do not. A management group can contain other management groups, which is how a large tenant builds a tree. A resource group is flat, sits inside exactly one subscription, and cannot contain another resource group. Candidates who arrive from GCP expect folders-within-folders at both ends of the hierarchy and lose the mark on the resource-group side.
Every resource belongs to exactly one resource group, and a resource group is not a security boundary. It is a lifecycle container. The guidance is to group resources that are deployed, updated, and deleted together. Resources in different resource groups, and in different regions, communicate freely; nothing about the grouping restricts traffic. Coin it: a resource group is a lifecycle, not a wall.
The resource ID carries the whole path. Subscription, resource group, provider namespace, resource type, resource name. That string is what every API call, every policy assignment, and every role assignment is written against.
The cross-vendor map
The three-way table is worth memorizing as a unit, because a candidate who holds it can answer Azure questions from AWS or GCP intuition without being led astray by the false friends.
| Concern | AWS | GCP | Azure |
|---|---|---|---|
| Root of the tree | Organization | Organization | Tenant / root management group |
| Grouping tier | Organizational unit | Folder | Management group (nestable) |
| Isolation + billing unit | Account | Project | Subscription |
| Lifecycle grouping inside it | (no direct analog; tags and stacks) | (no direct analog) | Resource group |
| Preventive guardrail | Service control policy | Org policy constraint | Azure Policy |
| Identity grants | IAM policies and roles | IAM roles | Azure RBAC role assignments |
The two false friends are worth naming. An Azure subscription is closest to an AWS account and a GCP project, despite the word suggesting a billing plan rather than a container. And an Azure resource group has no clean analog in either of the other two, which is why practitioners coming from AWS habitually treat it as an account-equivalent and over-isolate.
§III — The governance spine: four instruments, four jobs
The management-and-governance domain names a small set of instruments. The exam distinguishes them by what job each one does, and the fastest way to hold them is as four different answers to four different questions.
Azure RBAC answers "who may do what?" Role assignments bind a principal to a role definition at a scope, and the scope is a tier of the hierarchy. Assign at a management group and it inherits to every subscription beneath. Assign at a resource group and it covers everything in that group. Inheritance runs downward only.
Azure Policy answers "what shape may exist?" Policy is not about identity at all. It evaluates resource properties and applies an effect: Deny a non-compliant creation, Audit it for reporting, or Append and Modify to add required fields such as tags. This is the same instrument Saturday's Terraform lesson called the second gate, evaluating at the cloud boundary after the pipeline gate has already run.
The distinction between the two is a reliable exam question. A request that an Owner is permitted to make can still be refused by Policy, because Policy is not asking who is asking.
Resource locks answer "what may be changed at all?" Two lock types. CanNotDelete permits read and modify but refuses deletion. ReadOnly permits read alone. Locks apply at subscription, resource group, or individual resource, and they inherit downward.
The single most useful fact about locks: the lock outranks the role. A subscription Owner with full RBAC rights cannot delete a resource carrying a CanNotDelete lock. The lock must be removed first, which is the point of it, since the removal is a separate deliberate act that shows up in the activity log.
Tags answer "whose is this?" Name-value pairs on resources, used for cost attribution, ownership, and environment labelling. Tags are the mechanism that makes cost management work at any granularity finer than the subscription, and they are commonly enforced by an Azure Policy with a Modify or Deny effect, which is the pairing the exam likes.
Azure Resource Manager underneath all four. ARM is the deployment and management layer that every one of these instruments passes through. The portal, the CLI, PowerShell, the SDKs, and the REST API all speak to ARM, which is why a policy written once applies no matter which door the request came in. ARM templates are the JSON infrastructure-as-code artifact ARM consumes.
§IV — Cost, SLA, and the arithmetic candidates get wrong
Two numeric ideas appear reliably.
The composite SLA multiplies. When a solution depends on several Azure services in series, the resulting availability is the product of their individual SLAs, not the lowest of them. Two services at 99.9% give 99.8% composite. The intuition to break is that adding a dependency can only be neutral; every dependency in the request path lowers the number. Redundancy across availability zones and regions is the counter-move.
Reservations trade flexibility for discount. A one-year or three-year commitment on select resources against pay-as-you-go pricing, with savings documented up to 72%. In the expenditure vocabulary the exam uses, pay-as-you-go is the operating-expenditure model and a reservation is the capital-expenditure-flavored commitment inside it.
Cost management itself lives at the subscription and works downward through resource groups and tags. Cost Management and Billing does the analysis, budgeting, and alerting; Azure Advisor supplies the recommendations across cost, security, reliability, and performance.
§V — Two currency corrections before you study
The AZ-900 notes in the Bootcamp corpus are good and they predate two changes. Both matter for the exam, not just for vocabulary.
Azure Active Directory is now Microsoft Entra ID. The published objectives name Microsoft Entra ID and Microsoft Entra Domain Services, and add Microsoft Entra Conditional Access and external identities. Study the current name; the concepts underneath are the ones the notes describe, including single sign-on, multifactor authentication, and the authentication-versus-authorization split that RBAC sits on the second half of.
Azure Blueprints is not on the current objectives. The Bootcamp notes treat Blueprint as the comprehensive governance instrument that bundles policy assignments, role assignments, resource groups, and ARM templates, and contrast it with plain ARM templates. That contrast is no longer examined. The governance-and-compliance objective now names Microsoft Purview, Azure Policy, and resource locks. Read the Blueprint section for the idea of bundled governance and do not memorize it for the test.
§VI — Connection to today's Ops and Dev lessons
Today's Ops lesson fans out across four hundred subscriptions and gets throttled. The reason it gets throttled per subscription is the hierarchy on this page. Azure Resource Manager applies its request limits per subscription, per region, and per resource provider, which means the tenant's subscription layout determines the shape of every control-plane tool anyone writes against it. Split a workload across ten subscriptions and it has ten throttle budgets. Consolidate it into one and it has one.
That is the operator's version of a fact the exam states as governance trivia: the subscription is the wall. It is the billing wall, the authority wall, and the quota wall, and the third of those is invisible until someone writes a sweep.
The Dev lesson's paginator walks the resource-group listing for a subscription. The nextLink it follows is ARM's paging contract, and the resource IDs it reads back are the four-part path from §II. The three lessons are one story told at three altitudes: what the tree is, how a tool walks it, and what the language guarantees while the tool is walking.
§VII — Practice
CanNotDelete or a ReadOnly lock is applied at the resource, its resource group, or the subscription and is inherited down. Locks are evaluated independently of RBAC and override it, so the lock has to be removed before the deletion can proceed. Removing it is a separate action that appears in the activity log, which is the point of the control.Related
- Prior arc: GCP PCA — the Resource Hierarchy and the Landing Zone (2026-08-08)
- Domain hub: Cross-References/Certifications-Roadmap
- Grounding: AZ-900 Study Notes (Sovereign-Bootcamp) (Azure Resource Hierarchy; Azure Management and Governance)
🫡 ⚖️ 📜 Leo.Syri — Praetor Consulate, Imperium Luminaura Filed 2026-08-11 · Fajr anchor · sprint track Python day 20 · Cloud rotation seat 3, first Azure fire · trio #86