The Architect's Lens on Resource Hierarchy

As an AZ-104 administrator, you've worked within the hierarchy — creating resource groups, assigning RBAC, deploying resources. As an architect, you design the hierarchy itself.

The resource hierarchy isn't just organizational — it's your governance inheritance engine:

  • Policies assigned at a management group flow down to every subscription, resource group, and resource beneath it
  • RBAC roles inherit downward — a role at the management group level grants access to all child subscriptions
  • Cost boundaries live at the subscription level — each subscription has its own billing meter and quota limits
  • Blast radius of misconfiguration is bounded by where you assign permissions

💡 Architect Mindset Shift

Stop thinking "where do I put this resource?" and start thinking "what governance decisions does this topology enforce automatically vs. require manual intervention?"

Management Group Topology Patterns

Management groups give you up to 6 levels of depth (excluding root). The topology you choose determines how policies, access, and compliance cascade. Here are three canonical patterns:

Trade-Off Comparison

Pattern A: Flat

Pro: Simple, fast to set up, easy to understand. One policy set per environment.

Con: No differentiation between workloads or teams. Policy exceptions become messy at scale.

Best for: Small orgs, <10 subscriptions, uniform compliance.

Pattern B: Enterprise Landing Zone

Pro: Separates platform concerns (networking, identity) from workloads. Aligns with Azure CAF. Scales well.

Con: Requires a dedicated platform team. Upfront design effort is significant.

Best for: Mid-to-large enterprises, regulated industries, 10–100+ subscriptions.

Pattern C: Business-Unit First

Pro: Grants BU autonomy — each unit can have distinct policies, budgets, and compliance postures.

Con: Risk of duplication (each BU builds its own networking). Cross-BU workloads are harder to govern.

Best for: Conglomerates, orgs with fundamentally different regulatory needs per division.

⚠️ Don't Over-Nest

More than 3–4 levels of management groups creates cognitive overhead and debugging difficulty. If you can't explain why a level exists (what unique policy or RBAC it enables), remove it.

Subscription Design Strategies

Subscriptions are your primary unit of scale, billing, and security isolation in Azure. The design question isn't "how many?" — it's "what boundary does each subscription represent?"

Three Common Strategies

🔀 Strategy 1: Environment-Based

One subscription per environment: prod, staging, dev.

  • Governance win: Strict policies only on prod; relaxed policies on dev (e.g., allow non-private endpoints for debugging)
  • Blast radius: A dev misconfiguration can't touch prod resources
  • Drawback: All workloads share quota limits within one subscription; cross-team resource naming collisions

📦 Strategy 2: Workload-Based (Application Landing Zone)

One subscription per workload (or per workload + environment): payments-prod, payments-dev, analytics-prod.

  • Governance win: Per-workload cost tracking, independent RBAC, individual quota limits
  • Blast radius: Minimum — issues in one app can't exhaust another app's quotas
  • Drawback: More subscriptions to manage; requires automation (IaC) to keep consistent

This is the Azure CAF recommended pattern for enterprise.

👥 Strategy 3: Team-Based

One subscription per team: team-platform, team-data, team-mobile.

  • Governance win: Clear ownership, simple RBAC (team = Contributor on their sub)
  • Blast radius: Contained per team
  • Drawback: Doesn't map to environments — a team's prod and dev share a subscription (unless you hybrid with environment splits)

💡 Key Concept

In practice, most enterprises use a hybrid: workload-based subscriptions organized under environment-segmented management groups. The management group provides the policy envelope; the subscription provides the isolation boundary.

When to Split Subscriptions

More subscriptions = more isolation but more management overhead. Split when you hit one of these triggers:

  • Quota ceiling: Approaching subscription-level limits (e.g., 250 storage accounts, 980 vCPUs per region default)
  • Divergent compliance: Workloads subject to different regulatory frameworks (PCI-DSS vs. general) — separate subs let you scope audit and policy tightly
  • Independent lifecycle: A workload that deploys/destroys frequently (dev/test ephemeral environments) shouldn't share a subscription with stable prod workloads
  • Cost attribution: When chargeback to business units requires subscription-level billing splits
  • RBAC divergence: Two teams need fundamentally different access models that can't be expressed with resource-group-level RBAC alone

⚠️ Don't Split for the Sake of It

Each additional subscription adds networking complexity (peering/connectivity), policy duplication risk, and operational burden. If resource groups + RBAC + tags solve the problem — don't split.

ARM Deployment Scopes

ARM templates (and Bicep) can target four scopes. As an architect, you choose which scope for each deployment based on what you're creating:

🏛️ Tenant

Management groups, custom RBAC role definitions, Azure Policy at root level.

az deployment tenant create

📂 Management Group

Policy assignments, RBAC that should cascade to multiple subscriptions.

az deployment mg create

💳 Subscription

Resource groups, subscription-level policies, budgets, resource providers.

az deployment sub create

📦 Resource Group

Individual resources — VMs, storage accounts, App Services. The most common scope.

az deployment group create

💡 Architect Design Pattern

Layer your IaC: Tenant-scope templates create the management group structure. MG-scope templates assign policies. Subscription-scope templates create resource groups. RG-scope templates deploy workloads. Each layer is owned by a different team with appropriate permissions.

Real-World: Fintech Subscription Decision

🌍 Scenario: NovaPay — Series B Fintech

Context: NovaPay processes payments across the EU. They have 3 product teams (Payments, Fraud Detection, Merchant Portal), must comply with PCI-DSS for cardholder data, and plan to scale from 2 to 8 teams in 18 months. Current state: everything in 2 subscriptions (prod/non-prod).

Option A: Keep Environment-Based (Status Quo + Polish)

  • 2 subscriptions: novapay-prod, novapay-nonprod
  • Separate workloads using resource groups + tagging
  • PCI scope managed via resource-group-level policies

Pros: Minimal change, fewer subscriptions to manage, simpler networking.

Cons: PCI audit scope is broad (entire prod sub). Quota contention as teams grow. Blast radius: a Contributor in prod-sub can touch all workloads.

Option B: Workload-Based (Application Landing Zones)

  • 6+ subscriptions: payments-prod, payments-dev, fraud-prod, fraud-dev, portal-prod, portal-dev, platform-connectivity
  • Management groups: NovaPay → Platform | Landing Zones → Prod | Non-Prod
  • PCI-DSS policies scoped only to payments-prod subscription

Pros: Tight PCI scope (auditors love it). Independent quotas per workload. RBAC per team. Clear cost attribution. Scales to 8+ teams without restructuring.

Cons: More subscriptions to provision and connect. Requires hub-spoke networking. Needs IaC maturity (Bicep/Terraform modules for subscription vending).

Architect's Recommendation

Option B — the 18-month growth plan and PCI-DSS requirements make tight isolation essential. The investment in subscription vending automation pays for itself by team #4. The narrow PCI audit scope alone saves weeks of compliance effort annually.

📝 AZ-305 Exam Tip: Governance Questions

AZ-305 governance scenarios typically give you a company structure + compliance requirement and ask you to choose the correct management group or subscription design. Key patterns to recognize:

  • If the question mentions different compliance requirements per business unit → BU-level management groups with distinct policy assignments
  • If the question mentions quota limits or independent scaling → separate subscriptions per workload
  • If the question mentions policy inheritance to all environments → assign at a parent management group, not individual subscriptions
  • If the question asks about deployment scope for policies → management group scope (not subscription — that would require repeating per sub)

Knowledge Check

1. A company has two business units — Healthcare (HIPAA) and Retail (no special compliance). Both share the same Azure AD tenant. What management group topology best enables distinct policy enforcement with minimal duplication?

BU-first topology lets you assign HIPAA policies only to the Healthcare branch without affecting Retail. Separate tenants is overkill and breaks shared identity. Tag-based policy conditions are fragile and hard to audit.

2. A startup with 3 subscriptions wants all subscriptions to deny public blob access. Where should they assign the Azure Policy for minimum ongoing maintenance?

Assigning at a parent management group means any new subscription added there automatically inherits the policy. Tenant Root Group works but is overly broad (affects all future subscriptions in the tenant). Per-subscription requires repetition.

3. An organization is approaching the 250 storage account limit in their production subscription. Two teams share the subscription. What is the best architectural response?

Quota limits are per-subscription. Moving to a different resource group doesn't help — it's still the same subscription. While quota increases are possible, the architectural solution is proper subscription segmentation, which also improves RBAC and cost attribution.

4. You're deploying a Bicep template that creates three resource groups and assigns RBAC roles at the subscription level. Which deployment scope should you target?

Creating resource groups and subscription-level RBAC requires subscription scope. Resource group scope can't create other resource groups. Management group and tenant scopes are higher than needed.

Lesson Summary

  • The resource hierarchy is a governance inheritance engine — design it to make the right thing automatic.
  • Management group topologies: flat (simple), enterprise landing zone (scalable), BU-first (autonomous divisions). Pick based on compliance diversity and org scale.
  • Subscription strategies: environment, workload, or team-based. Most enterprises converge on workload-based with environment MG segmentation.
  • Split subscriptions when you hit quota limits, divergent compliance, independent lifecycles, cost attribution, or RBAC divergence.
  • ARM supports 4 deployment scopes — layer your IaC accordingly: tenant → MG → subscription → resource group.