3.1 Subscription Design and Management Groups

Subscription scope as an administrator boundary

In Azure, a subscription is the practical container where most administrator work becomes enforceable. It links resources to an Azure offer and billing relationship, but it also creates boundaries for quotas, role assignments, policy assignments, resource provider registration, cost analysis, activity logs, and support operations. On AZ-104, treat a subscription as more than a payment unit. It is often the smallest governance boundary that can cleanly separate production from nonproduction, regulated from unregulated, and centrally managed from application-owned workloads.

A subscription contains resource groups, and resource groups contain resources. Management groups sit above subscriptions and can contain other management groups or subscriptions. A tenant can have a hierarchy of management groups under the tenant root group. Governance assigned at a management group can flow down to child management groups, subscriptions, resource groups, and resources unless exclusions or scope choices change the result.

Tenant root group
|-- Platform management group
|   |-- Connectivity subscription
|   |-- Identity subscription
|   `-- Management subscription
|-- Landing zones management group
|   |-- Prod subscription A
|   |-- Prod subscription B
|   `-- Nonprod subscription A
`-- Sandbox management group
    `-- Developer sandbox subscription

A common exam trap is confusing the hierarchy with deployment placement. You do not deploy a virtual machine into a management group. You deploy the VM into a resource group in a subscription. The management group can govern the VM indirectly through inherited Azure Policy or RBAC assignments, but it is not a resource container for the VM.

Choosing subscription boundaries

Use separate subscriptions when you need a hard administrative or operational boundary. Strong reasons include separate billing ownership, different production controls, different regulatory requirements, subscription quota isolation, workload isolation for risky experiments, or separation between platform services and application teams. Weak reasons include every project name, every cost center change, or every short-lived environment. Those are often better handled with resource groups, tags, budgets, and policy.

For an enterprise landing zone, subscriptions commonly map to workload or platform boundaries. A connectivity subscription may host hub virtual networks, Azure Firewall, VPN gateways, or ExpressRoute gateways. A management subscription may host Log Analytics workspaces, automation, and monitoring assets. Application subscriptions host the business workloads. This pattern reduces accidental coupling between shared services and application deployments.

Management groups and inherited governance

Management groups are best used for broad, stable governance. Assign policies such as allowed regions, required tags, diagnostic settings, or allowed resource types at a management group when the rule should affect many subscriptions. Assign RBAC at a management group when a central team truly needs access across all child subscriptions. Do not use broad Owner or User Access Administrator assignments casually. They are powerful and are inherited by child scopes.

A practical hierarchy usually starts simple. Create top-level groups for platform, landing zones, sandbox, and decommissioned subscriptions. Put production and nonproduction under separate child groups only when they need different rules. If the company later reorganizes, do not immediately mirror every new department. Management groups should represent durable governance needs, not a volatile org chart.

Decision workflow
1. Does the rule apply across many subscriptions? Use management group scope.
2. Does the rule apply to one billing or workload boundary? Use subscription scope.
3. Does the rule apply to one application lifecycle? Use resource group scope.
4. Does the rule apply to one resource exception? Use resource scope only when necessary.

Subscription operations you must recognize

Administrators often need to register resource providers before deploying a service. For example, a subscription may need Microsoft.ContainerService, Microsoft.Insights, or Microsoft.RecoveryServices registered before related resources work. Many portal deployments register providers automatically, but template, CLI, or locked-down environments may expose provider registration as a blocker.

Useful commands include:

az account list --output table
az account set --subscription "Prod-Shared-01"
az provider list --query "[?registrationState!='Registered'].{Namespace:namespace, State:registrationState}" --output table
az provider register --namespace Microsoft.RecoveryServices
az account management-group list --output table

For PowerShell, expect Get-AzSubscription, Set-AzContext, Get-AzResourceProvider, and Register-AzResourceProvider. The exam may show either tool. The decision logic matters more than memorizing every switch.

Exam traps and troubleshooting cues

If a user can see a subscription but cannot create a resource, check RBAC at the target scope, policy denials, provider registration, quota, and region restrictions. If a policy assigned to a management group blocks a deployment in a child subscription, changing the resource group setting alone will not fix it. You must modify the inherited assignment, add an exemption when justified, or deploy in a compliant way.

If cost analysis does not show a resource where expected, confirm the selected scope. Cost Management can view costs at billing, subscription, resource group, or management group scopes depending on account type and permissions. A tag report also depends on tag presence and whether tags were applied before usage occurred.

Remember the AZ-104 pattern: when the question asks for one control applied consistently to many subscriptions, management group is usually the right governance scope. When it asks for isolating billing, quotas, or production risk, a separate subscription is usually the stronger answer. When it asks for a single application lifecycle, start with a resource group unless another boundary requirement is explicit.