Azure Blueprints and Management Groups

Azure Management Groups are containers that help you manage access, policies, and compliance across multiple Azure subscriptions. Think of them as folders that can hold subscriptions and other management groups, forming a hierarchy. The root management group is automatically created for every Azure AD tenant and sits at the top of the hierarchy. You can create up to 10,000 management groups in a single directory, and a management group can have up to 2,000 child management groups or subscriptions. The depth of the hierarchy is limited to six levels (excluding the root level).

Why do you need management groups? In a large organization with hundreds or thousands of subscriptions, managing each one individually is impractical. Management groups allow you to apply Azure Policy and Role-Based Access Control (RBAC) at a higher level, and those settings are inherited by all subscriptions and management groups underneath. For example, you can apply a policy that restricts VM SKUs to only approved sizes at the root management group, and every subscription in the tenant will automatically enforce that rule. This eliminates the need to configure policies per subscription.

Management groups create a parent-child relationship. When you assign a policy or RBAC role to a management group, all child management groups and subscriptions inherit that assignment. However, inheritance is not transitive in the sense that a child can override a parent's policy (if the policy effect allows it), but by default, policies are inherited.

To create a management group, you need the "Management Group Contributor" role at the root level. The root management group itself has special permissions: only Azure AD Global Administrators can elevate their access to become a User Access Administrator at the root. This is a security best practice—limit who can manage the root.

Here's a step-by-step of how inheritance works:

If you need to exempt a specific subscription, you can assign an exemption at that subscription level. Exemptions can be for a limited time or permanent, but they must be explicitly created.

Azure Blueprints are a declarative way to orchestrate the deployment of resource groups, policies, role assignments, and ARM templates. They are not the same as ARM templates—Blueprints are a higher-level abstraction that packages multiple artifacts into a single deployable unit. The key difference is that Blueprints maintain a relationship with the deployed resources, allowing you to track and update the deployment as the blueprint version changes.

The business problem: When you need to create a new subscription that complies with company standards (e.g., must have a specific network topology, must use only certain VM sizes, must have auditing enabled), you could manually configure everything, but that's error-prone and inconsistent. Blueprints allow you to define a repeatable set of configurations that can be assigned to a subscription or management group. Once assigned, the blueprint creates a versioned artifact that Azure monitors for drift.

A blueprint is composed of artifacts. Artifacts can be:

When you publish a blueprint, it creates a version number (e.g., 1.0). You can then assign that blueprint version to a subscription or management group. During assignment, you can specify parameters (e.g., location, admin password) and grant the blueprint system-assigned managed identity permissions to deploy the artifacts.

After assignment, Azure Blueprints tracks the deployment. If you later publish a new version (e.g., 2.0), you can update the assignment to the new version. Azure will then apply the changes—adding new artifacts, updating policies, etc. However, it does not automatically delete resources that were removed from the blueprint; you must manually delete those.

Blueprints are stored in a globally distributed, read-only store within Azure. They are scoped to a subscription or management group, and you can export/import them as JSON files.

In an on-premises environment, managing governance across multiple departments or business units is often done manually or with scripts. For example, you might have a configuration management database (CMDB) that tracks server configurations, but enforcing policies like "no VMs in certain subnets" requires manual audits. Management Groups and Blueprints automate this: policies are enforced at scale, and blueprints ensure every new environment is built exactly to specification, reducing configuration drift.

Management Groups in Portal:

Management Groups via CLI:

# Create a management group
az account management-group create --name Contoso --display-name "Contoso"

# Add a subscription to a management group
az account management-group subscription add --name Contoso --subscription "Subscription-ID"

# List management groups
az account management-group list

Blueprints in Portal:

Blueprints via CLI:

# Create a blueprint definition
az blueprint create --name MyBlueprint --scope /subscriptions/YourSubID --blueprint-file blueprint.json

# Publish a blueprint version
az blueprint publish --name MyBlueprint --version 1.0 --scope /subscriptions/YourSubID

# Assign a blueprint
az blueprint assignment create --name MyAssignment --scope /subscriptions/YourSubID --blueprint-version-id /subscriptions/YourSubID/providers/Microsoft.Blueprint/blueprints/MyBlueprint/versions/1.0

Note: Blueprints are being deprecated in favor of deployment stacks (announced in 2024). However, AZ-900 still covers Blueprints as they are widely used. Deployment stacks offer similar functionality but with better drift detection and management. For the exam, know the basics of Blueprints and that deployment stacks are the newer alternative.

A global company, Contoso Ltd., operates in multiple regions with strict data residency laws. They have hundreds of subscriptions across business units. Without management groups, each subscription would need individual policies to restrict resource creation to approved regions. The cloud governance team creates a management group hierarchy: Root > Geo-Regions (e.g., 'NA', 'EU', 'APAC') > Business Units (e.g., 'Finance', 'HR'). At the 'EU' management group, they assign a policy that denies creation of resources outside EU data centers. This policy automatically applies to all subscriptions under 'EU'. They also assign a custom RBAC role 'Compliance Reader' to the global compliance team at the root, giving them read access to all subscriptions. This setup ensures compliance without per-subscription configuration. A common mistake: assigning policies at the root that are too restrictive, causing global issues. Best practice: use exemptions sparingly and document them.

A software company, Fabrikam, needs to spin up new development subscriptions quickly. Each subscription must contain a specific network topology (VNet with subnets), a set of Azure Policies (e.g., no public IPs on VMs), and a role assignment for the DevOps team. They create a blueprint called 'Dev-Environment' that includes an ARM template for the VNet, three policy assignments, and a role assignment. They publish version 1.0 and assign it to each new subscription. When security requirements change (e.g., a new policy requiring encryption), they update the blueprint, publish 2.0, and update all assignments. Azure automatically applies the new policy to existing resources. However, they must manually delete resources that are no longer needed (e.g., an old storage account type). The cost consideration: Blueprints themselves have no cost, but the resources they deploy do. A pitfall: if the managed identity does not have sufficient permissions, the assignment fails. Always grant the blueprint identity 'Contributor' on the target subscription.

When a company acquires another, they often inherit existing Azure subscriptions with no consistent governance. Using management groups, the parent company can create a new management group for the acquired company, then move their subscriptions into it. They can then assign corporate policies at the parent management group level, which will be inherited by the acquired subscriptions. However, existing resources may violate the new policies (e.g., resources in disallowed regions). Azure Policy can be set to 'Audit' initially to identify non-compliant resources, then later changed to 'Deny' after remediation. Blueprints can be used to deploy a standardized landing zone for new subscriptions created post-acquisition. This approach minimizes business disruption while enforcing governance.