Manage Azure identities and governance
Azure Resource Organization and Scope Hierarchy
CoreOperate management groups, subscriptions, resource groups, and tags with clear inheritance and move boundaries.
Aligned to the current AZ-104 study guide, verified August 21, 2026.
Why this matters
The hierarchy determines where resources live, where governance inherits, which costs roll up together, and how broad an administrative change becomes.
Must Know
- Management groups organize subscriptions so governance and access can be assigned above the subscription boundary.
- A subscription is a management and billing boundary; a resource group is a lifecycle container within one subscription.
- A resource belongs to one resource group, while its location can differ from the resource group metadata location.
- Tags provide key-value metadata for organization and reporting but do not automatically inherit from resource groups or subscriptions.
- Moving resources requires checking supported resource types, dependencies, locks, permissions, and destination constraints.
Compare and Distinguish
- Management group vs subscription vs resource group: governance grouping above billing boundary vs billing/management boundary vs resource lifecycle container.
- Resource group vs tag: a resource has one resource-group home; it can have multiple tags used for classification and reporting.
- Tags vs Policy enforcement: tags record metadata; Policy can require, append, or modify tags where its definition and effect support that behavior.
Scenario examples
- Scenario: Every production subscription needs the same location restriction. Think: Place those subscriptions under one management group and assign governance at that parent scope.
- Scenario: Finance needs cost reports by application and owner. Think: Apply consistent tags and enforce missing metadata with Policy where appropriate.
- Scenario: A resource move fails before any data transfers. Think: Check support, dependencies, locks, provider registration, and destination permissions.
Exam traps
- Resource groups are not nested, and one resource cannot simultaneously belong to two resource groups.
- Moving a resource group does not change the Azure region of the resources inside it.
- A tag on a resource group is not automatically copied to its resources.
Key takeaways
- Use hierarchy for inherited governance, subscriptions for management and billing boundaries, and resource groups for coordinated lifecycle.
- Treat tags as metadata and verify move prerequisites before changing a resource’s administrative home.
How it works
- Azure Resource Manager records each resource under a subscription and resource group while exposing parent scopes for assignments.
- A move operation checks a set of resources and dependencies, validates the destination, and then updates the management-plane placement.
Objects and administrative surfaces
- Tenant root and management groups — hierarchy for subscriptions and inherited governance.
- Subscription — resource providers, quotas, billing context, policies, roles, and resource groups.
- Resource group and resource — lifecycle operations, moves, deployments, tags, locks, and access.
When to use it
- Use management groups to apply common governance across subscriptions with the same policy needs.
- Group resources by shared lifecycle and administration rather than assuming a resource group is a network boundary.
Security and governance implications
- Keep the hierarchy simple enough that administrators can predict inherited roles and policies.
- Standardize required tags and restrict cross-subscription moves to authorized operators.
How to reason about this
- For unexpected governance, walk from the resource upward and inspect each parent assignment.
- For a failed move, run prerequisite checks and review dependent resources, locks, destination quotas, and permissions.
More detail
- Administrators create and reorganize management groups, manage subscriptions and resource groups, apply tags, and move supported resources across administrative boundaries.
- Resource moves change the resource ID when the subscription or resource group path changes, so dependent tooling and permissions may need attention.
Ready for the quiz?
- Which scope should hold a rule shared by several subscriptions?
- What is the difference between a resource group location and a resource location?
- Which dependencies should be checked before moving resources?
Related objectives
- D1.3.S3 — Apply and manage tags on resources
- D1.3.S4 — Manage resource groups
- D1.3.S5 — Manage subscriptions
- D1.3.S7 — Configure management groups