Management groups, subscriptions and resource groups

A resource group is a lifecycle container: resources you deploy, manage and delete together belong in the same group, and deleting the group deletes everything inside it in one operation. That is exactly the throwaway-experiment pattern. Why not the others: deleting the subscription is far too broad — it takes down every resource group and resource under it, not just this experiment, and disrupts billing. Deleting resources one by one works but is manual, slow and easy to leave orphans behind (a stray disk or public IP keeps charging). Azure Policy governs what is allowed to exist; it is not a cleanup button. Pro tip: when a question stresses 'create and destroy together,' the answer is almost always the resource group as a unit.

A resource group's location only determines where the metadata about the group is stored; the resources inside it can live in any region. So a storage account in one region and a VM in another can share one resource group without issue. Why not the others: there is no rule forcing a resource to match its group's region — that is a common misconception the exam tests. Azure never silently relocates a running resource to match the group. And no Azure Policy is needed to 'permit' multiple regions, because nothing forbids them in the first place. Pro tip: remember the resource-group region is about the group's own metadata, not a constraint on what it can hold.

The subscription is Azure's billing and boundary unit: costs roll up per subscription, it is a natural invoice scope, and many service quotas and limits apply per subscription — so two subscriptions consume limits independently. That matches every part of the requirement. Why not the others: a resource group organizes resources for lifecycle and access but is not the primary billing or limits boundary. A management group sits above subscriptions to apply shared governance across many of them — useful, but it does not itself separate billing at the invoice level. A region is a physical location, not a billing or quota container. Pro tip: 'billing boundary' and 'service limits apply per…' almost always point to the subscription.

Governance in Azure flows one direction: downward. A policy (or an RBAC assignment) placed at a management group is inherited by all subscriptions under it, all resource groups under those, and all resources — including resources and groups created after the assignment. So the new resource group is covered automatically. Why not the others: nobody needs to re-apply the policy per resource group — that would defeat the point of assigning it high up. Policies do not apply 'only at the exact level' — inheritance is the whole reason management groups exist. And there is no automatic exemption for new resource groups. Pro tip: the diagram's downward arrow is the single most tested idea here — assignments inherit down, never up or sideways.

There is exactly one root management group per tenant, sitting above all other management groups and subscriptions; it cannot be moved or deleted. Because everything descends from it, a policy or access assignment placed there reaches every subscription and resource in the tenant — the widest possible blast radius, so it is used sparingly. Why not the others: a subscription is never the top of the tree — subscriptions live under management groups. There is no single tenant-wide 'default resource group' that sits at the top. Microsoft Entra ID handles identities (users, groups, sign-in); it is not the top of the resource-organization hierarchy. Pro tip: 'one, cannot be deleted, everything rolls up to it' = the root management group.

Azure supports moving many resources between resource groups and even between subscriptions, but not universally — support depends on the resource type, and some resources cannot be moved and must be recreated. So the honest, exam-correct statement is the qualified one. Why not the others: resources are not permanently locked to their original group — moving is a first-class operation for many types. A resource always lives in exactly one resource group at a time; it is never a member of two simultaneously. And moving is not inherently a delete-and-recreate — that is only the fallback for the resource types that do not support a move. Pro tip: watch for absolute words like 'never' and 'always' — the accurate answer here is the one that admits exceptions.

Because many limits and billing scopes are per subscription, splitting a workload across multiple subscriptions is the standard way to separate quotas and cleanly divide spending — a common reason to run production and non-production in different subscriptions. Why not the others: a resource group does not raise or hold service limits, so consolidating into one changes nothing about quotas. A management group organizes and governs subscriptions but does not increase the quotas of the subscriptions beneath it. Adding regions spreads resources geographically but does not, by itself, give you a clean billing wall or reset a per-subscription boundary. Pro tip: 'we keep hitting a limit' or 'separate the billing' is the classic cue to reach for another subscription.