Managing cloud infrastructure at scale is one of the most underrated challenges in enterprise IT. Azure provides a layered hierarchy to help organizations structure their environments logically, enforce policies, and control costs. At the heart of this hierarchy are three foundational constructs: Management Groups, Subscriptions, and Resource Groups. Understanding how they work, how they interact, and how to secure them is essential for any cloud architect, DevOps engineer, or security professional working in Microsoft Azure.
This guide breaks down each layer in depth, walks through practical Azure CLI and PowerShell commands, and highlights the security implications your team cannot afford to overlook.
Before diving into each component, it helps to visualize the full hierarchy. Azure organizes resources in four levels:
Each level inherits policies and role-based access control (RBAC) from the level above it. This inheritance model means that a policy applied at the Management Group level cascades down to every subscription, resource group, and individual resource beneath it.
Management Groups sit at the top of the Azure hierarchy. They are containers that help you organize multiple Azure subscriptions into a single governance structure. If your organization runs dozens or hundreds of subscriptions across business units, regions, or environments, Management Groups are the mechanism that brings order to that complexity.
Every Azure tenant has a single root Management Group. All other Management Groups and subscriptions are nested beneath it. You can create up to six levels of nesting below the root, giving enterprise organizations significant flexibility in how they model their organizational structure.
From a security standpoint, Management Groups are where your governance posture starts. Applying Azure Policy or RBAC at the Management Group level means every subscription underneath inherits those controls automatically. This eliminates the risk of a rogue or misconfigured subscription operating outside your security perimeter.
For example, you can enforce a policy at the Management Group level that denies creation of public IP addresses across all child subscriptions unless explicitly allowed. That single policy blocks an entire class of misconfigurations before they happen.
If your team needs help evaluating whether your Azure governance structure is actually protecting your environment, Redfox Cybersecurity's cloud penetration testing services can identify gaps in your Management Group policies and RBAC configurations before attackers do.
Create a Management Group using Azure CLI:
az account management-group create \
--name "Contoso-Production" \
--display-name "Contoso Production Group"
[cta]
List all Management Groups:
az account management-group list --output table
[cta]
Move a subscription into a Management Group:
az account management-group subscription add \
--name "Contoso-Production" \
--subscription "your-subscription-id"
[cta]
Assign a policy definition at the Management Group scope using PowerShell:
$managementGroupId = "Contoso-Production"
$policyDefinitionId = "/providers/Microsoft.Authorization/policyDefinitions/<policy-guid>"
New-AzPolicyAssignment `
-Name "deny-public-ips" `
-Scope "/providers/Microsoft.Management/managementGroups/$managementGroupId" `
-PolicyDefinitionId $policyDefinitionId
[cta]
Get details on a specific Management Group:
az account management-group show \
--name "Contoso-Production" \
--expand \
--recurse
[cta]
The --expand and --recurse flags are particularly useful when auditing your hierarchy because they return the full tree of child management groups and subscriptions in a single API call.
An Azure Subscription is the core unit of billing and access in Azure. Every resource you create in Azure lives inside a subscription. Subscriptions also act as a trust boundary, meaning resources in one subscription cannot communicate with resources in another subscription without explicit configuration, such as Virtual Network peering or Private Link.
Organizations typically use multiple subscriptions to separate environments (development, staging, production), business units, geographic regions, or compliance domains. The Azure landing zone architecture, recommended by Microsoft, even prescribes specific subscription patterns for connectivity, identity, and workloads.
Every subscription has hard limits, also called quotas. For example:
When workloads grow or teams scale, these limits force architects to think carefully about subscription boundaries. A single monolithic subscription serving all workloads creates bottlenecks and increases blast radius when something goes wrong.
Subscriptions are a natural security boundary. If a subscription is compromised, the damage is contained to resources within that subscription. Organizations handling regulated data, such as those subject to PCI DSS, HIPAA, or ISO 27001, often isolate sensitive workloads into dedicated subscriptions with tighter RBAC and stricter Azure Policy assignments.
Misconfigured subscription-level RBAC is one of the most common findings in cloud security assessments. Overly permissive Owner or Contributor roles granted to user accounts, service principals, or managed identities at the subscription scope create significant attack surface. The penetration testing team at Redfox Cybersecurity regularly uncovers privilege escalation paths that originate from subscription-level RBAC misconfigurations during red team engagements.
List all subscriptions in your tenant:
az account list --output table
[cta]
Set a specific subscription as the active context:
az account set --subscription "your-subscription-id-or-name"
[cta]
Assign a built-in RBAC role at the subscription scope:
az role assignment create \
--assignee "user@contoso.com" \
--role "Reader" \
--scope "/subscriptions/your-subscription-id"
[cta]
List all role assignments at the subscription scope:
az role assignment list \
--scope "/subscriptions/your-subscription-id" \
--output table
[cta]
Check which subscription you are currently working in:
az account show --output json
[cta]
Retrieve subscription-level activity logs to audit actions (PowerShell):
Get-AzActivityLog `
-StartTime (Get-Date).AddDays(-7) `
-EndTime (Get-Date) `
-MaxRecord 100 | Select-Object EventTimestamp, Caller, OperationName, ResourceGroupName, Status
[cta]
This command pulls seven days of activity logs and is invaluable when investigating suspicious activity or building a timeline for incident response.
A Resource Group is a container that holds related Azure resources. Every resource in Azure must belong to exactly one resource group. Resource groups do not cost money themselves; they are organizational containers only.
The key design principle is that resources in the same resource group should share the same lifecycle. When you delete a resource group, all resources inside it are deleted. This makes resource groups a powerful tool for environment cleanup, especially in DevOps and infrastructure-as-code workflows where ephemeral environments are common.
Tags applied at the resource group level can propagate to resources for cost tracking and policy enforcement. A well-designed tagging strategy typically includes tags such as:
Environment: Production, Staging, DevelopmentOwner: team or individual responsibleCostCenter: for financial chargebackProject: the initiative the resource supportsCriticality: High, Medium, LowAzure Policy can enforce mandatory tags at the resource group level, ensuring that no resource is deployed without the metadata your operations and finance teams need.
Create a resource group:
az group create \
--name "rg-contoso-prod-eastus" \
--location "eastus" \
--tags Environment=Production Owner=CloudTeam CostCenter=12345
[cta]
List all resource groups in the current subscription:
az group list --output table
[cta]
Show details for a specific resource group including its tags:
az group show --name "rg-contoso-prod-eastus" --output json
[cta]
Lock a resource group to prevent accidental deletion:
az lock create \
--name "ProductionLock" \
--resource-group "rg-contoso-prod-eastus" \
--lock-type CanNotDelete \
--notes "Prevents accidental deletion of production resources"
Resource locks are a critical security and operational control. A CanNotDelete lock means no one, not even a subscription Owner, can delete the resource group or its resources without first removing the lock. This simple step prevents a class of catastrophic incidents ranging from human error to destructive insider threats.
Deploy a Bicep or ARM template to a specific resource group:
az deployment group create \
--resource-group "rg-contoso-prod-eastus" \
--template-file main.bicep \
--parameters @parameters.prod.json
[cta]
Move resources between resource groups:
az resource move \
--destination-group "rg-contoso-prod-westus" \
--ids "/subscriptions/your-sub-id/resourceGroups/rg-contoso-prod-eastus/providers/Microsoft.Compute/virtualMachines/vm-prod-01"
[cta]
Export the ARM template of an existing resource group for documentation or replication:
az group export \
--name "rg-contoso-prod-eastus" \
--output json > rg-export.json
[cta]
This is especially useful for compliance documentation or migrating configurations to new subscriptions.
Consider a financial services company with three main business units: Retail Banking, Investment Banking, and Corporate IT. A sensible Azure hierarchy might look like this:
At the Contoso-Corp Management Group level, you apply enterprise-wide policies: enforce encryption at rest, deny resource creation in non-approved regions, and require diagnostic logs to be sent to a central Log Analytics workspace. Each business unit Management Group can then layer on additional policies specific to their regulatory requirements.
# Assign the "Allowed locations" built-in policy at a Management Group
az policy assignment create \
--name "restrict-regions" \
--display-name "Restrict resource creation to approved regions" \
--policy "e56962a6-4747-49cd-b67b-bf8b01975c4f" \
--scope "/providers/Microsoft.Management/managementGroups/Contoso-Corp" \
--params '{"listOfAllowedLocations": {"value": ["eastus", "westus2", "northeurope"]}}'
[cta]
Granting permissions at the lowest necessary scope is a core principle of least privilege. Using Management Groups for broad read access, subscriptions for environment-level contributor access, and resource groups for targeted ownership keeps your permissions model tight and auditable.
# Grant a security team read access at the Management Group scope
New-AzRoleAssignment `
-ObjectId "<security-team-group-object-id>" `
-RoleDefinitionName "Security Reader" `
-Scope "/providers/Microsoft.Management/managementGroups/Contoso-Corp"
[cta]
Defender for Cloud (formerly Azure Security Center) can be enabled at the Management Group level, ensuring every subscription beneath it is automatically enrolled.
az security pricing create \
--name VirtualMachines \
--tier standard
[cta]
Run this command across each subscription or automate it via Policy to ensure consistent threat protection.
Use Azure Resource Graph to query across all subscriptions simultaneously. This is far more efficient than querying subscription by subscription.
az graph query \
-q "Resources | where type == 'microsoft.network/publicipaddresses' | project name, resourceGroup, subscriptionId, location" \
--output table
[cta]
This query returns every public IP address across all subscriptions you have access to, a useful starting point for attack surface mapping.
If you want a professional, adversarial perspective on how exposed your Azure environment truly is, Redfox Cybersecurity offers specialized cloud penetration testing that simulates real attacker behavior across your Management Group, Subscription, and Resource Group boundaries.
As mentioned earlier, resource locks are a low-effort, high-impact control. Automate their creation as part of your infrastructure-as-code pipelines so production resource groups are always protected.
az lock create \
--name "NoDeleteLock" \
--lock-type CanNotDelete \
--resource-group "rg-prod-critical" \
--notes "Auto-applied by deployment pipeline"
[cta]
The Azure hierarchy of Management Groups, Subscriptions, and Resource Groups is not just an organizational convenience. It is the foundation of your cloud governance, security posture, and operational maturity. Getting this structure right from the beginning prevents enormous technical debt and security debt down the road.
Management Groups let you govern at scale. Subscriptions create billing and security boundaries. Resource Groups provide the lifecycle containers your applications and workloads live in. When these three layers are designed thoughtfully and managed rigorously, they become a force multiplier for your entire cloud program.
The commands and patterns in this guide give you the practical starting points to build, audit, and secure your Azure hierarchy. But knowing your configuration exists is different from knowing it actually holds up under attack.
Redfox Cybersecurity's penetration testing services are built for organizations serious about understanding their real-world exposure. Whether you need a focused cloud configuration review, a full red team engagement, or a compliance-aligned assessment, the team at Redfox Cybersecurity brings adversarial expertise to help you harden what matters most.
Secure your Azure environment before someone else tests it for you. Engage Redfox Cybersecurity today.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
