Recommend a structure for management groups, subscriptions, and resource groups
5 minutes
5 Questions
When designing a structure for management groups, subscriptions, and resource groups in Azure, architects must consider organizational hierarchy, governance requirements, and operational efficiency. The recommended approach follows a layered model that balances control with flexibility.
Management…When designing a structure for management groups, subscriptions, and resource groups in Azure, architects must consider organizational hierarchy, governance requirements, and operational efficiency. The recommended approach follows a layered model that balances control with flexibility.
Management Groups form the top tier of the hierarchy, sitting above subscriptions. They enable policy and access management at scale. A typical structure includes a Root Management Group, followed by organizational divisions such as Production, Development, and Sandbox environments. You might also create management groups based on business units, geographic regions, or regulatory requirements. Management groups can be nested up to six levels deep, allowing granular control while maintaining centralized governance.
Subscriptions serve as billing boundaries and access control containers. Each subscription should represent a distinct workload category or environment. Common patterns include separating subscriptions by environment (Production, Test, Development), by business function (HR, Finance, IT), or by application lifecycle stage. This separation helps manage costs, apply consistent policies, and maintain security boundaries. Consider subscription limits when planning workload distribution.
Resource Groups act as logical containers for resources that share the same lifecycle. Best practices include grouping resources that deploy, update, and delete together. Naming conventions should reflect the application, environment, region, and purpose. For example: rg-webapp-prod-eastus. Each resource group should contain resources from a single application or service component, making management and access control more straightforward.
Key recommendations include implementing consistent naming conventions across all levels, using Azure Policy at appropriate management group levels for governance enforcement, leveraging role-based access control inheritance through the hierarchy, and planning for growth by leaving room for additional subscriptions and resource groups. Tags should complement this structure by providing additional metadata for cost allocation, ownership, and operational purposes. Regular reviews ensure the structure continues meeting organizational needs as requirements evolve.
Recommend a Structure for Management Groups, Subscriptions, and Resource Groups
Why This Is Important
Understanding how to recommend an appropriate management structure is critical for Azure Solutions Architects because it forms the foundation of governance, security, and cost management in Azure. A well-designed hierarchy ensures that policies, access controls, and compliance requirements are applied consistently across an organization's cloud resources. Poor structure leads to management overhead, security gaps, and compliance issues.
What Is Azure's Management Hierarchy?
Azure uses a four-level hierarchy for organizing resources:
1. Management Groups These are containers that help you manage access, policy, and compliance across multiple subscriptions. They can be nested up to six levels deep (excluding the root). All subscriptions within a management group automatically inherit policies and RBAC applied to that group.
2. Subscriptions Subscriptions are billing boundaries and access control boundaries. They contain resource groups and serve as units for scaling, billing separation, and policy application.
3. Resource Groups Logical containers for resources that share the same lifecycle. Resources in a resource group can span multiple regions but the resource group itself has a metadata location.
4. Resources Individual Azure services like VMs, storage accounts, and databases.
How It Works
Policies and RBAC assignments flow downward through the hierarchy. When you assign a policy at the management group level, it applies to all subscriptions and resources beneath it. This inheritance model allows for:
- Centralized governance at higher levels - Flexibility for teams at lower levels - Separation of concerns between billing, environments, and workloads
Design Considerations
When recommending a structure, consider:
- Organizational structure: Align with business units, departments, or geographic regions - Environment separation: Development, testing, staging, and production - Billing requirements: Cost tracking per project, department, or customer - Regulatory compliance: Data residency and industry-specific requirements - Team autonomy: Balance central control with team flexibility
Common Patterns
Pattern 1: Environment-based Management groups organized by environment (Dev, Test, Prod)
Pattern 2: Business Unit-based Management groups aligned with organizational departments
Pattern 3: Geographic-based Management groups based on regions for data sovereignty
Pattern 4: Hybrid Combination of approaches using nested management groups
Exam Tips: Answering Questions on Management Structure
1. Look for governance requirements: When a question mentions applying policies uniformly across multiple subscriptions, management groups are the answer.
2. Identify billing boundaries: If cost separation between departments or projects is required, recommend separate subscriptions.
3. Consider lifecycle together: Resources that should be deployed and deleted together belong in the same resource group.
4. Remember inheritance: RBAC and policies assigned at higher levels apply to everything below. Questions often test whether you understand this flow.
5. Watch for scale limits: Know that subscriptions have resource limits and when to recommend multiple subscriptions.
6. Read for compliance clues: Data residency requirements suggest geographic separation at the subscription or management group level.
7. Identify who needs access: When different teams need isolated control, separate subscriptions or resource groups with appropriate RBAC are the solution.
8. Default to least privilege: Recommend structures that allow minimal permissions at higher levels with more specific grants lower in the hierarchy.
9. Think about operational boundaries: Production workloads typically need their own subscriptions to prevent accidental impact from development activities.