Azure management groups and subscriptions look simple when an environment is small. A few subscriptions can be organized by naming convention and managed by people who know the history. At scale, those informal rules stop working. Governance inheritance, access boundaries, cost ownership, quotas, policy scope, deployment automation, and organizational change all depend on how the hierarchy was designed.
The current AZ-305 architecture exam includes governance and infrastructure design because these are not housekeeping details. They determine how easily an Azure estate can grow without turning every exception into manual work.
The design objective is not the prettiest hierarchy. It is a structure that maps durable policy and ownership boundaries while avoiding unnecessary coupling to an organization chart that may change next quarter.
Use management groups for durable governance differences
Management groups are valuable because policy and access decisions can be applied above subscriptions and inherited downward. That makes them appropriate for distinctions that should remain meaningful across many workloads: platform versus application landing zones, corporate-connected versus internet-facing environments, regulated estates, sandboxes, or decommissioned subscriptions.
A weak pattern is creating a management group for every department simply because departments exist. Organization charts change frequently. If the hierarchy mirrors them too closely, every reorganization becomes a governance migration.
A stronger question is: which group of subscriptions genuinely needs different policy, access, compliance, or operational treatment? If the answer is “none,” a new management group may add hierarchy without adding control.
Treat subscriptions as units of management and scale
Subscriptions provide more than billing separation. They create boundaries for quotas, RBAC scope, policy, resource providers, cost reporting, and many operational processes. Azure landing-zone guidance uses subscriptions as units that can be provisioned for workload teams through consistent vending patterns.
This makes subscription design a capacity decision as well as a governance decision. A large monolithic subscription can create noisy cost allocation, tangled access, and quota pressure. Excessive fragmentation can create management overhead and cross-subscription dependencies everywhere.
Subscriptions and hierarchical management become easier to reason about when the team starts from workload ownership, lifecycle, compliance, and scale rather than from arbitrary numerical limits.
Separate platform responsibilities from workload ownership
Connectivity, identity-related platform services, security monitoring, and management tooling often have different owners and change cadences from application workloads. Dedicated platform subscriptions can make that difference explicit. Workload subscriptions can then inherit enterprise controls without sharing every resource with the platform team.
This separation reduces permission pressure. A workload owner does not need rights over a central firewall simply because the application uses the network. A platform operator does not need broad control over application data just to maintain shared connectivity.
The boundary also helps incident response. When a shared platform service fails, ownership is clear. When an application fails, the workload team can investigate inside its subscription while platform teams verify shared dependencies.
Design the hierarchy for policy inheritance
Azure Policy becomes much easier to reason about when the management-group hierarchy reflects actual policy differences. Baseline security and governance can be assigned high in the tree. More specific controls can be applied to lower groups where needed.
Problems arise when teams rely on large numbers of exceptions. An exemption may be justified, but repeated exemptions often indicate that policy is assigned at the wrong scope or that workloads with different requirements were placed under the same management group.
The architecture should therefore include an exception model: who can approve exemptions, how long they last, what evidence justifies them, and how they are reviewed. Governance that cannot handle legitimate exceptions tends to be bypassed.
Identity scope should follow operational responsibility
Role assignments at the wrong level can erase the value of subscription boundaries. Granting broad roles at a management group because it is convenient can give administrators access to workloads they do not operate. Conversely, assigning every role individually at resource scope creates administrative sprawl.
A practical design uses groups and scoped roles aligned to responsibility. Platform teams receive the permissions needed for shared capabilities. Workload teams receive control within their subscriptions. Security and audit functions receive visibility appropriate to their role without automatically receiving change rights.
The related AZ-104 administration path is useful here because architecture decisions eventually become operational role assignments, policies, and subscription configurations. AZ-305 asks why the boundary should exist; administrators must make it real.
Plan for subscription lifecycle, not just creation
Subscription vending is only the beginning. Subscriptions change owners, move between management groups, enter restricted states, get merged into new operating models, and eventually reach decommissioning. The design should define those transitions before they become urgent.
Decommissioning is especially important because abandoned subscriptions can retain public endpoints, secrets, identities, logs, backup data, or unexpected cost. A controlled retirement path should remove or archive data, revoke access, preserve required evidence, and move the subscription into a state where accidental reuse is difficult.
A hierarchy that includes sandboxes and decommissioned areas can support these lifecycle differences without weakening production policies.
Billing structure and cost ownership are related but not identical
Teams sometimes shape subscriptions primarily around invoices. Cost attribution matters, but it should not override security and operational boundaries. Tags, cost-management scopes, budgets, and chargeback processes can provide financial visibility without forcing every organizational cost center into a separate technical architecture.
The reverse problem also exists: placing unrelated workloads in one subscription because a single department pays for them. That can make permissions and policy too broad and complicate capacity planning.
The design should distinguish who pays, who operates, who governs, and who owns the business outcome. Those roles may belong to different teams.
Stress the model with acquisition, regulation, and scale
A good subscription hierarchy should survive predictable disruption. Suppose the company acquires a regulated subsidiary. Does the new estate require different policies or data residency controls? Can it fit into an existing management group, or does it need a distinct governance branch? Can shared connectivity be used without violating isolation requirements?
Now imagine subscription count triples. Does role management still scale through groups? Can policies be applied without hundreds of manual assignments? Can network teams discover new spokes automatically? Can cost teams report by product and business unit without changing technical boundaries?
These questions reveal whether the hierarchy is based on durable architecture or temporary convenience.
The best hierarchy makes ordinary change boring
Management groups and subscriptions are successful when they turn recurring enterprise requirements into predictable inheritance. Teams know where a workload belongs, which controls apply, who owns the subscription, how access is granted, how connectivity is requested, how cost is reported, and what happens when the workload is retired.
For architects pursuing the Azure Solutions Architect Expert credential, the durable skill is not memorizing a canonical tree. It is learning to recognize which differences deserve architectural boundaries and which should remain metadata or process.
If the structure can absorb growth, organizational change, and policy evolution without constant reshaping, the early design decisions have earned their place.
A subscription boundary also changes blast radius. Resource locks, policy changes, role assignments, quota exhaustion, provider registration, and some service limits are scoped in ways that can affect many resources at once. Grouping unrelated production systems into one subscription can allow a local operational mistake to have wider consequences than expected.
Conversely, creating a subscription for every small component can make cross-subscription networking, identity, monitoring, and deployment harder to understand. The right granularity usually follows workload ownership and lifecycle. Components that are released, operated, secured, and retired together are natural candidates to share a subscription, provided their scale and policy needs are compatible.
Multi-region designs add another choice. Some organizations place regional instances of one workload in the same subscription to simplify ownership; others separate regions when regulatory, quota, or blast-radius requirements justify it. There is no universal answer. The architecture should state which failure or governance problem the extra boundary solves.
Subscription moves and management-group moves should also be treated as change events. Inheritance can alter policy and permissions immediately. A workload that is moved between governance branches may become noncompliant or lose expected access even when its resources have not changed. Mature teams test those moves and understand the inherited controls before using hierarchy changes as administrative shortcuts.
Finally, the hierarchy should be observable. Inventory reports should show where subscriptions sit, who owns them, which policy initiatives apply, which critical exemptions exist, and which subscriptions are inactive or orphaned. Governance structure that cannot be inspected at scale becomes dependent on tribal knowledge.
One final test is delegation. A mature hierarchy should let central teams define non-negotiable controls while allowing workload teams to manage their own lifecycle without waiting for tenant-wide administrators. If ordinary application delivery requires repeated elevation at the management-group level, the hierarchy may be concentrating authority rather than organizing it.
That delegation model also makes audits easier because privileged access and policy ownership follow recognizable scopes instead of ad hoc exceptions scattered across resources.
The hierarchy should also support emergency operations. Security or platform teams may occasionally need broader access during an incident, but that elevation should be deliberate, time-limited, and auditable rather than permanently embedded in the normal role model.
