This chapter covers subscription security and management group policy, a critical area for the AZ-500 exam. You will learn how to design and manage a hierarchical structure using management groups to enforce governance, access control, and compliance across multiple subscriptions. Approximately 10-15% of exam questions touch on management groups, Azure Policy, and RBAC inheritance, making this a high-yield topic. Mastery of these concepts is essential for the 'Identity and Access' domain (objective 1.4) and for real-world Azure security engineering.
Jump to a section
Think of an Azure tenant as a large corporate office building. The building itself (the tenant) has a main entrance (the root management group). Inside, there are floors (management groups) that group departments (subscriptions). Each department has its own secure area (subscription) with various rooms (resource groups) and cabinets (resources). The building's security system (Azure RBAC) controls who can enter which floor, which department, and which room. Now, imagine the building's management decides to enforce a company-wide policy: all doors must have electronic locks (Azure Policy). They can apply this policy at the building level (root management group), and it automatically applies to every floor, department, and room. However, a specific department (subscription) with sensitive data might need an additional policy: all rooms in that area must also have biometric scanners. This is allowed because policies can be inherited and overridden at lower levels (management group or subscription). The security guard (Azure Policy) continuously checks that all doors comply. If a room is moved to a different floor, the policies of the new floor apply. This is exactly how management groups and subscriptions work: management groups provide a structure for policy and RBAC inheritance, while subscriptions are the boundary for billing and resource organization. Just as a building's security is only as strong as its weakest door, Azure security depends on correctly layering policies and permissions across management groups and subscriptions.
What Are Management Groups and Why Do They Exist?
Management groups are containers that help you manage access, policy, and compliance across multiple Azure subscriptions. They form a hierarchy that can go up to six levels deep (excluding the root level). The root management group is automatically created for every Azure AD tenant and cannot be moved or deleted. Management groups exist to solve a fundamental problem: as organizations grow, they accumulate dozens or hundreds of subscriptions. Without management groups, administrators would have to apply policies and RBAC assignments to each subscription individually, which is error-prone and unscalable. By grouping subscriptions into management groups, you can apply policies and role assignments at a higher level and have them automatically inherited by all descendant subscriptions and resource groups.
How Management Groups Work Internally
When you create a management group, it is essentially a logical container that holds subscriptions and other management groups. The hierarchy is stored in Azure Resource Manager as a tree structure. Every subscription belongs to exactly one management group at a time (by default, the root management group). The inheritance mechanism works as follows:
RBAC Inheritance: Role assignments applied at a management group are inherited by all subscriptions, resource groups, and resources within that management group. For example, if you assign the 'Reader' role at a management group, every user in that role can read all resources in all subscriptions under that management group.
Policy Inheritance: Azure Policy assignments at a management group apply to all subscriptions and resource groups within that management group. Policies can be enforced (deny) or evaluated (audit).
Inheritance is transitive: A policy assigned at the root management group applies to every subscription in the tenant. A policy assigned at a child management group applies only to that subtree.
Exclusions: You can exclude specific child management groups, subscriptions, or resource groups from a policy assignment using the 'Exclusion' parameter. This is a powerful feature that allows fine-grained control.
Key Components, Values, Defaults, and Timers
Root Management Group: Created automatically. Its ID is the tenant ID (a GUID). It cannot be deleted or moved.
Management Group ID: A unique string you define when creating the management group (e.g., 'Sales'). This ID is used in Azure CLI and PowerShell commands.
Display Name: A friendly name (e.g., 'Sales Department').
Depth Limit: Maximum of 6 levels (root level counts as level 0, so you can have up to 6 child levels).
Subscription Limit per Management Group: No hard limit, but Azure Resource Manager has a limit of 10,000 subscriptions per tenant. Each management group can hold many subscriptions.
Policy Assignment Inheritance: Policies are inherited immediately (no timer). However, policy evaluation is eventual consistency – it may take up to 30 minutes for new assignments to be evaluated on existing resources.
RBAC Inheritance: Role assignments are effective immediately for new resources, but existing resources may take up to 5 minutes to reflect changes due to caching.
Management Group Readiness: When you move a subscription to a different management group, the new policies and RBAC assignments apply within minutes.
Configuration and Verification Commands
To create a management group using Azure CLI:
az account management-group create --name Sales --display-name "Sales Department"To move a subscription to a management group:
az account management-group subscription add --name Sales --subscription <subscription-id>To assign a policy at a management group:
az policy assignment create --name "audit-vm-managed-disks" --policy "audit-vm-managed-disks" --scope /providers/Microsoft.Management/managementGroups/SalesTo view effective policies for a subscription:
az policy state list --resource-group <rg-name>To view management group hierarchy:
az account management-group show --name <mg-name> --expandHow Management Groups Interact with Related Technologies
Management groups are tightly integrated with: - Azure RBAC: Roles assigned at management group scope are inherited. This allows you to grant access to an entire department's subscriptions in one place. - Azure Policy: Policies assigned at management group scope enforce compliance across multiple subscriptions. This is the primary use case for management groups. - Azure Blueprints: Blueprints can be assigned at management group scope to orchestrate the deployment of resource groups, policies, and RBAC assignments consistently. - Azure Cost Management: You can view costs aggregated by management group, which helps in chargeback and showback scenarios. - Azure AD: Management groups use Azure AD for identity, but the management group hierarchy is separate from Azure AD organizational structure.
Subscription Security Considerations
Subscriptions are the primary boundary for resource organization and billing, but they also have security implications: - Trust Boundary: By default, resources in one subscription cannot access resources in another subscription unless explicitly configured (e.g., VNet peering, RBAC). - Service Administrator Role: The Account Administrator (billing owner) and Service Administrator (can manage all resources) are legacy roles that still exist. For security, you should use RBAC roles instead and limit the number of Subscription Admins. - Default Permissions: When a subscription is created, the creator is automatically assigned the 'Owner' role at the subscription scope. This cannot be removed but can be overridden. - Moving Subscriptions: When you move a subscription between management groups, policies and RBAC assignments from the new parent apply. This can inadvertently grant or revoke access. Always test moves in a non-production environment.
Policy and Initiative Definitions
Azure Policy includes: - Built-in Policies: Microsoft-provided policies (e.g., 'Allowed locations', 'Audit VMs without managed disks'). - Custom Policies: JSON-defined policies you create. - Initiatives (Policy Sets): A group of policies that are applied together (e.g., 'ISO 27001' blueprint). - Assignments: Binding a policy or initiative to a scope (management group, subscription, resource group). - Exemptions: Exclude a specific resource from policy evaluation. Exemptions have an expiration date. - Remediation: Automatically fix non-compliant resources (e.g., deploy a managed disk).
Policy Effects
Each policy definition has an effect that determines what happens when the condition is met: - Deny: Prevents creation or modification of non-compliant resources. - Audit: Logs a warning in the activity log but allows the resource. - Append: Adds additional fields to the resource during creation (e.g., tags). - AuditIfNotExists: Audits if a related resource does not exist (e.g., audit if a VM does not have a backup). - DeployIfNotExists: Deploys a related resource if it does not exist (e.g., deploy a network watcher). - Disabled: Effectively turns off the policy.
Common Exam Scenarios
Inheritance Confusion: Candidates often think that a policy applied at management group A does not apply to subscriptions in management group B. This is correct – inheritance is strictly hierarchical.
Exclusion Precedence: An exclusion on a child management group overrides a policy applied at a parent. For example, if root management group has a policy denying public IP addresses, but you exclude a child management group, that child can have public IPs.
Multiple Assignments: If the same policy is assigned at multiple scopes, the most restrictive assignment wins. However, if one assignment has 'Deny' and another has 'Audit', the 'Deny' takes effect.
Resource Group vs. Subscription: Policies assigned at subscription scope apply to all resource groups within that subscription. Policies assigned at resource group scope apply only to that resource group.
Management Group Hierarchy: The root management group is not visible in the Azure portal by default. You must enable 'View all management groups' to see it.
Azure Blueprints and Management Groups
Azure Blueprints allow you to define a repeatable set of Azure resources that adhere to organizational standards. Blueprints can be assigned to management groups, which then apply to all subscriptions within that management group. This is ideal for deploying a standard environment (e.g., a secure landing zone) across multiple subscriptions. Blueprints include:
Role assignments
Policy assignments
ARM templates
Resource groups
Security Best Practices
Use management groups to enforce baseline policies: Apply common security policies (e.g., 'Audit VMs without managed disks', 'Deny public IP on NICs') at the root management group.
Limit the number of subscription owners: Use management group-level RBAC to grant 'Owner' at a higher scope, but avoid granting 'Owner' at subscription scope unless necessary.
Separate workloads into subscriptions: Use management groups to organize subscriptions by environment (dev, test, prod) or by department.
Use Azure Policy to enforce tagging: Require cost center and environment tags on all resources.
Audit management group changes: Enable Azure Activity Log alerts for changes to management group structure.
Use Azure AD Privileged Identity Management (PIM) for role assignments at management group scope to provide just-in-time access.
Avoid deep hierarchies: Six levels is the maximum, but deeper hierarchies can become difficult to manage. Aim for 3-4 levels.
Troubleshooting Common Issues
Policy not applying: Check if the policy is assigned at the correct scope. Verify that the subscription is under that management group. Use the Azure Policy compliance dashboard.
RBAC not inherited: Role assignments at management group scope are inherited, but if a role is assigned at subscription scope with a different permission set, the subscription-level assignment overrides (it is additive).
Cannot create management group: You need 'Owner' or 'Contributor' at the root management group. By default, the Global Administrator in Azure AD does not have these permissions; they must be elevated.
Moving subscription fails: The user must have 'Owner' (or 'Contributor' with write permissions) on both the source and destination management groups, and on the subscription itself.
Exam Focus: Key Numbers and Values
6 levels: Maximum depth of management group hierarchy.
10,000 subscriptions: Maximum per Azure AD tenant.
30 minutes: Maximum time for policy evaluation on existing resources after a new assignment.
5 minutes: Typical time for RBAC changes to propagate.
Root management group ID: The Azure AD tenant ID (GUID).
Policy effects: Deny, Audit, Append, AuditIfNotExists, DeployIfNotExists, Disabled.
Blueprints: Can be assigned to management groups, subscriptions, and resource groups.
Exclusions: Can be applied at child management groups, subscriptions, or resource groups.
This deep understanding of management groups and policy inheritance is crucial for both the AZ-500 exam and real-world Azure security architecture.
Design Management Group Hierarchy
Start by planning the management group structure based on your organization's requirements. Common patterns include by department (Finance, IT, HR), by environment (Dev, Test, Prod), or by geography (NA, EU, APAC). The root management group already exists. Create child management groups up to six levels deep. For example, a hierarchy could be: Root -> Environment -> Prod -> Workload. Each management group must have a unique ID (e.g., 'Prod') and a display name (e.g., 'Production'). Use the Azure CLI command `az account management-group create` to create them. Ensure that the naming convention aligns with your governance strategy. Document the hierarchy to avoid confusion.
Assign Policies at Management Group
Once the management group structure is in place, assign Azure Policies at the appropriate level. For example, assign a policy that denies public IP addresses at the root management group to apply to all subscriptions. Use the Azure portal, CLI, or PowerShell. For CLI: `az policy assignment create --policy <policy-name> --scope /providers/Microsoft.Management/managementGroups/<mg-name>`. Policies can be assigned with parameters (e.g., list of allowed locations). Understand that policies are inherited by all child management groups and subscriptions. To exclude a child, use the 'Exclusion' option when assigning the policy. Test the policy in audit mode first to see what resources would be affected.
Assign RBAC Roles at Management Group
Grant access to teams by assigning RBAC roles at the management group scope. For example, assign the 'Contributor' role to the development team at the 'Dev' management group so they can manage all resources in development subscriptions. Use the command: `az role assignment create --assignee <user-or-group> --role Contributor --scope /providers/Microsoft.Management/managementGroups/<mg-name>`. Remember that role assignments are inherited by all subscriptions under that management group. Avoid assigning 'Owner' at high scopes unless necessary, as it grants full control. Use PIM for elevated roles.
Move Subscriptions into Management Groups
After creating management groups and assigning policies/roles, move subscriptions into the appropriate management group. Use the Azure portal or CLI: `az account management-group subscription add --name <mg-name> --subscription <subscription-id>`. The user must have write permissions on both the subscription and the management group. When a subscription is moved, all policies and RBAC assignments from the new parent management group apply. This can cause immediate changes in access and compliance. Always verify the impact by checking effective policies and role assignments before and after the move.
Monitor and Audit Compliance
After deployment, continuously monitor compliance using Azure Policy compliance dashboard. Check for resources that are non-compliant with policies. Use the activity log to track changes to management groups, policy assignments, and role assignments. Set up alerts for critical changes (e.g., deletion of a management group). Use Azure Policy's 'Remediation' task to automatically fix non-compliant resources (e.g., deploy managed disks). Regularly review effective policies and RBAC assignments at each scope to ensure they align with security requirements.
Enterprise Scenario 1: Multinational Corporation with Subsidiaries
A large corporation with multiple subsidiaries (e.g., Contoso US, Contoso EU, Contoso APAC) needs to enforce a baseline security policy across all Azure subscriptions while allowing each subsidiary to have its own policies. The solution: create a management group hierarchy with Root -> Geography (US, EU, APAC) -> Subsidiary. At the Root, assign policies that require encryption at rest, deny public IP addresses, and enforce tagging with cost center. Each geography management group can have additional policies, such as data residency (e.g., EU requires data to stay within Europe). Each subsidiary management group can assign its own policies and RBAC roles. This hierarchy simplifies compliance because policies are inherited, but exclusions can be made for specific subsidiaries that have different requirements. In production, this setup handles thousands of subscriptions. The key challenge is ensuring that moves between management groups do not inadvertently break access – a common mistake is moving a production subscription to a development management group, which could grant developers unintended access. To mitigate, use Azure Policy to restrict who can move subscriptions and require approval via Azure DevOps.
Enterprise Scenario 2: Cloud Center of Excellence (CCoE) Landing Zone
A company adopts Azure with a CCoE team that builds a secure landing zone for application teams. The CCoE creates a management group hierarchy: Root -> Platform -> Landing Zones -> Workload. At the Platform management group, they assign policies that enforce network security (e.g., forced tunneling, no inbound RDP from internet), identity (e.g., require Azure AD passwordless), and monitoring (e.g., deploy Log Analytics agent). Each landing zone management group contains subscriptions for different application teams. The CCoE uses Azure Blueprints to deploy the landing zone: the blueprint includes resource groups, VNet, NSG, and policy assignments. When a new application team requests a subscription, the CCoE creates a new subscription and moves it into the appropriate landing zone management group. The subscription automatically inherits all policies and RBAC assignments. The application team then deploys their resources within the guardrails. A common issue is that the CCoE's policies are too restrictive, causing application teams to request exemptions. The solution is to use audit mode initially and refine policies based on feedback.
Enterprise Scenario 3: Mergers and Acquisitions
After an acquisition, Company A needs to integrate Company B's Azure subscriptions into its tenant. Company B's subscriptions have their own management group structure. The integration involves moving Company B's subscriptions under Company A's root management group. However, Company B's existing policies and RBAC assignments may conflict. The approach: first, create a new management group under Root named 'Acquired' and move Company B's subscriptions there temporarily. Then, gradually apply Company A's policies while removing Company B's duplicate policies. Use policy exclusions to avoid breaking running applications. This process can take months. A common mistake is moving subscriptions too quickly without testing, which can cause outages due to policy enforcement. The best practice is to use a phased approach with extensive testing in a non-production environment.
What AZ-500 Tests on This Topic
The AZ-500 exam objective 1.4 focuses on 'Configure and manage Azure policy, management groups, and role-based access control (RBAC)'. Specifically, you need to know:
How to create and manage management groups (up to 6 levels).
How policy inheritance works across management groups, subscriptions, and resource groups.
How to assign policies and RBAC roles at management group scope.
How to move subscriptions between management groups and the impact on inheritance.
How to use Azure Blueprints with management groups.
The difference between policy effects (Deny vs. Audit vs. Append).
Common Wrong Answers and Why Candidates Choose Them
'Policies assigned at the root management group cannot be overridden.' – This is false. Child management groups can be excluded from a policy assignment. Candidates assume inheritance is absolute, but exclusions are a key feature.
'Moving a subscription to a different management group requires the subscription to be empty.' – False. Subscriptions can be moved with resources. The impact is that new policies apply immediately. Candidates confuse this with moving resources between subscriptions, which does require no dependencies.
'Management groups can be nested up to 10 levels.' – False. The limit is 6 levels. Candidates often guess a higher number.
'All users in the tenant can create management groups.' – False. You need 'Owner' or 'Contributor' at the root management group. The default Azure AD Global Admin does not have this permission unless elevated.
Specific Numbers and Terms That Appear on the Exam
6 levels: Maximum depth.
10,000 subscriptions: Maximum per tenant.
Root management group: Cannot be moved or deleted.
Policy effects: Know the six effects and when to use each.
Exclusion: The term 'exclusion' is used in policy assignments.
Initiative: A group of policies (also called policy set).
Blueprint: Can be assigned to management groups.
Edge Cases and Exceptions
What happens if a policy is assigned at both management group and subscription scope with different effects? The most restrictive effect applies. If management group says 'Deny' and subscription says 'Audit', the resource is denied.
Can you assign a role at management group scope that conflicts with a role at subscription scope? RBAC is additive – you get the union of permissions. There is no conflict; the user has both sets of permissions.
If a subscription is moved from one management group to another, do existing resources become non-compliant? Yes, if the new management group has policies that the resources do not meet. They will be marked non-compliant in the next policy evaluation cycle.
How to Eliminate Wrong Answers
Always check the scope in the question. If the scope is a management group, inheritance applies. If the scope is a subscription, only that subscription is affected.
If a question says 'policy applies to all subscriptions in the tenant', the assignment must be at the root management group (or at all management groups individually, which is impractical).
If a question asks about overriding a policy, look for the word 'exclusion'. Only exclusions can remove inheritance.
For RBAC, remember that 'Owner' at management group gives full control over all subscriptions under it. This is a powerful permission that should be limited.
Management groups form a hierarchy up to 6 levels deep, with the root management group at the top.
Policies and RBAC assignments at a management group are inherited by all subscriptions and resources in that group.
Exclusions can be used to prevent inheritance for specific child management groups, subscriptions, or resource groups.
Moving a subscription to a different management group applies the new parent's policies and roles immediately.
The root management group cannot be deleted or moved; its ID is the Azure AD tenant ID.
Azure Blueprints can be assigned to management groups to deploy consistent environments across subscriptions.
Policy effects include Deny, Audit, Append, AuditIfNotExists, DeployIfNotExists, and Disabled.
To create management groups, you need 'Owner' or 'Contributor' at the root management group scope.
These come up on the exam all the time. Here's how to tell them apart.
Management Groups
Container for subscriptions and other management groups.
Supports inheritance of policies and RBAC.
Can be nested up to 6 levels deep.
Used for cross-subscription governance.
Cannot contain resources directly.
Resource Groups
Container for resources within a single subscription.
Supports inheritance of policies and RBAC from subscription and management groups.
Cannot be nested (flat structure).
Used for resource lifecycle management and grouping.
Contains resources directly.
Mistake
Management groups are required to organize subscriptions.
Correct
Management groups are optional. Subscriptions can exist directly under the root management group without any custom management groups. However, management groups are strongly recommended for governance at scale.
Mistake
Policies assigned at a management group apply to all subscriptions in the tenant.
Correct
Policies assigned at a management group apply only to subscriptions within that management group's hierarchy. To apply to all subscriptions, assign at the root management group.
Mistake
You can delete the root management group.
Correct
The root management group is automatically created and cannot be deleted or moved. It serves as the top-level container for all subscriptions and management groups.
Mistake
RBAC role assignments at management group scope are not inherited by resource groups.
Correct
They are inherited by all descendant scopes, including subscriptions, resource groups, and individual resources. This is a fundamental concept.
Mistake
A subscription can belong to multiple management groups simultaneously.
Correct
Each subscription can belong to exactly one management group at a time. However, it can be moved between management groups.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The maximum depth is 6 levels, including the root management group. This means you can have up to 5 levels of child management groups under the root. If you attempt to create a management group that would exceed this limit, Azure will return an error. Plan your hierarchy carefully to avoid hitting this limit, especially in large organizations with many departments and sub-departments.
Yes, you can assign a policy to a management group even if it currently has no subscriptions. The policy will apply to any subscriptions that are added to that management group in the future. This is useful for pre-configuring governance before onboarding new subscriptions.
A user needs 'Owner' or 'Contributor' role at the root management group scope. By default, the Global Administrator in Azure AD does not have these permissions. You must elevate access by going to the root management group in the Azure portal and assigning the role. Alternatively, you can use Azure CLI: `az role assignment create --assignee <user> --role Contributor --scope /providers/Microsoft.Management/managementGroups/<tenant-id>`.
Existing resources are evaluated against the new policy. If they are non-compliant, they will be marked as such in the policy compliance dashboard. The effect (Deny, Audit, etc.) applies to future modifications, not to existing resources unless the policy has a 'DeployIfNotExists' effect that triggers remediation. For Deny policies, existing resources are not automatically deleted, but they cannot be modified if they violate the policy.
Yes, moving a subscription does not affect the resources within it. However, the subscription will immediately inherit the policies and RBAC assignments of the new parent management group. This could cause access changes or compliance violations. Always test the move in a non-production environment first.
A policy assignment applies a single policy definition to a scope. An initiative assignment applies a group of policies (initiative) together. Initiatives are used to enforce a set of related policies, such as a compliance framework (e.g., ISO 27001). Both can be assigned at management group, subscription, or resource group scope.
When creating or updating a policy assignment, you can specify exclusions. In the Azure portal, you can select 'Exclude' and choose the subscription (or management group) to exclude. In CLI, use the `--not-scopes` parameter: `az policy assignment create --policy <policy> --scope /providers/Microsoft.Management/managementGroups/<mg> --not-scopes /subscriptions/<sub-id>`.
You've just covered Subscription Security and Management Group Policy — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?