AZ-305
Deep Dive
Governance is the backbone of AZ-305: how to organize management groups, how many subscriptions to create, where to apply policies and RBAC, and how the Cloud Adoption Framework structures all of it into Azure Landing Zones. Questions typically give you an organizational structure and ask for the correct hierarchy design.
Contents
The Azure hierarchy: Tenant → Management Groups (up to 6 levels) → Subscriptions → Resource Groups → Resources. RBAC and Azure Policy assigned at one level are inherited downward. Correct design minimizes duplicate assignments.
Key management group rules
Design principle
Group subscriptions by shared governance requirements, not organizational structure or geography. If Prod and Dev need different policies → separate management groups. If two departments need exactly the same policies → they can share a management group.
The subscription is the unit of billing, service limits (quotas), and administrative isolation. Legitimate reasons to separate subscriptions:
| Driver | Why it splits subscriptions |
|---|---|
| Platform limits (quotas) | Quotas (vCPUs, VNets, storage accounts) are per-subscription — a massive workload can exhaust other teams' quota. |
| Environment isolation | Prod vs Dev/Test: different policies, different RBAC, Dev/Test pricing offers. |
| Billing separation | Chargeback by business unit or customer — the subscription is the natural billing line. |
| Security boundary / blast radius | A compromise or mistake in one subscription doesn't affect another's resources. |
| Regulatory requirements | PCI/HIPAA workloads isolated with their own policies and auditing. |
Anti-pattern
One subscription per small app → administrative sprawl. A single subscription for the entire company → quota clashes and no RBAC granularity. The exam rewards balance: subscriptions per environment + significant workload, governed by management groups.
A landing zone is a pre-configured environment (identity, network, governance, monitoring) where workloads land. The CAF conceptual architecture defines a standard management group hierarchy that the exam expects you to recognize.
Reference CAF hierarchy
Landing zone design principles
Implementation
Resource groups — design rules
Tags — design
Resource locks
CanNotDelete: can be modified but not deleted. ReadOnly: cannot be modified or deleted (careful: it blocks unexpected operations, like listing storage keys). Locks apply to all users including Owners — protect critical production resources from accidental deletion.
| Requirement | Design |
|---|---|
| Apply a policy to 40 subscriptions without repeating assignments | Assign it at an ancestor management group |
| Prod and Dev need different guardrails | Separate management groups (Prod / Non-Prod) |
| A massive workload threatens other teams' quotas | A dedicated subscription for that workload |
| Cost chargeback by business unit | Subscriptions per BU + cost center tags |
| Prevent accidental deletion of critical resources | CanNotDelete resource lock |
| Inherit a cost center tag from the resource group | Azure Policy with a modify effect |
| Repeatable standard environment for new teams | Landing zone with Bicep/Terraform (CAF accelerator) |
| Risk-free experiments for corp | Sandbox management group with no connectivity and relaxed policies |
Did you get this topic?
Test what you just learned
A multinational has 60 subscriptions: 25 production, 20 development, 10 shared platform (network, identity), and 5 sandbox. They need: strict policies in production, relaxed policies in sandbox, and only the central team administering the platform subscriptions. What is the correct hierarchy design?
Put what you learned to the test with original AZ-305 exam questions.
Start AZ-305 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.