Azure Management Groups: Seeing the Hierarchy You Actually Have

You inherit a tenant. It has forty-odd subscriptions with names like sub-test-old-2 and landingzone-pilot, hanging off a management group tree that grew one reorg at a time. Then a deny policy lands on a production subscription and blocks a deployment, and the on-call engineer spends an hour answering a question that should take seconds: which level of the tree did that come from?

Management groups are where Azure governance actually happens. Policy assignments and role assignments placed on a management group flow down to every subscription and resource underneath it. That inheritance is the whole point, and it's also the trap: the effects show up at the bottom of the tree, while the causes live somewhere above, unlabeled.

You can't govern a tree you can't see. And Azure doesn't make the tree easy to see.

The Problem: Inheritance Flows Down a Structure Nobody Drew

The hierarchy in most tenants wasn't designed; it accreted. A pilot structure from 2021, a landing-zone rework that half-finished, an acquisition bolted on under its own branch. The result has some structural properties that make it genuinely hard to reason about:

• The portal shows you one level at a time. Expanding nodes in the Management groups blade works for five subscriptions, not fifty.
• Effects and causes live at different levels. A policy or role assignment on an ancestor group is invisible when you're staring at the subscription it just affected. Resolving "what actually applies here" means walking every level by hand.
• The tree moves without announcing itself. Subscriptions get moved between groups, new groups appear, RBAC changes at some middle layer, and nothing taps you on the shoulder.
• Defaults collect strays. Subscriptions that were never explicitly placed sit in the default management group, quietly outside whatever governance your real branches enforce.

The sharp version: your governance model is only as good as your mental model of the tree, and the tree outgrew everyone's mental model years ago.

Reconstructing the Tree with Azure Resource Graph

Resource Graph's resourcecontainers table covers management groups and subscriptions, so you can pull the raw structure across the whole tenant at once. Management groups and their parents:

resourcecontainers
| where type =~ 'microsoft.management/managementgroups'
| project name, displayName = tostring(properties.displayName),
          parent = tostring(properties.details.parent.displayName)

Subscriptions with their full ancestor chain:

resourcecontainers
| where type =~ 'microsoft.resources/subscriptions'
| project subName = name,
          mgChain = properties.managementGroupAncestorsChain

(Verify the managementGroupAncestorsChain property name against current docs; it has been the ancestor-chain field in Resource Graph, but property paths shift.) If you prefer the CLI, az account management-group list returns the groups, and adding --expand --recurse on az account management-group show walks a branch.

These queries are the right first move in any unfamiliar tenant, and you should keep them handy. But be honest about what you're looking at afterward:

1. Flat rows for a tree. You get parent-child pairs and ancestor arrays, and then you rebuild the hierarchy in your head or in a spreadsheet. The structure is the thing you wanted to see, and it's exactly what rows can't show.
2. Inheritance is still unresolved. Knowing the chain is Tenant Root > Corp > Prod doesn't tell you which role assignments apply to the subscription at the bottom. That's a separate lookup at every level, per subscription.
3. No history. The query shows today's tree. Whether sub-payments-prod was moved out of the governed branch last month, and by whom, is not in the result.
4. Strays don't flag themselves. Nothing in the output says "these four subscriptions are sitting in the default group with no governance branch above them." You have to notice.

How StratoLens Shows You the Tree

StratoLens turns that same structure into something you can actually reason about:

• The whole hierarchy in one interactive view. Management groups, nested structure, and subscription assignments rendered as the tree they are, with drill-down instead of spreadsheet reconstruction.
• Role assignments in context. See the RBAC picture alongside the hierarchy instead of walking each level by hand to work out how access flows down.
• Changes get noticed. StratoLens tracks when subscriptions move between management groups, when the hierarchy is restructured, and when RBAC is modified, so the tree can't quietly rearrange itself behind your back.
• Strays become visible. When every subscription's placement is on one map, the ones parked outside your governed branches stand out instead of hiding in a list.

All of this runs from inside your own Azure tenant; the hierarchy and access data StratoLens works with stays under your control, in your environment.

Learn the Tree Before the Next Reorg

Start with the Resource Graph queries above; ten minutes in an inherited tenant with resourcecontainers beats a week of portal clicking. Then decide who keeps the picture current, because the tree will change again. If the answer is "nobody has time for that," that's the job Management Groups Visualization in StratoLens was built for.