A small town runs a single Azure subscription with a handful of resource groups. When is introducing management groups most clearly justified?
Select an answer to reveal the explanation.
Short Explanation
A tiny one-subscription shop does not need a management-group cathedral. Bring management groups in when you have many subscriptions to govern the same way. Scale of subscriptions — not VM count — is the usual trigger.
Full Explanation
Management groups pay off when an organization must govern multiple subscriptions consistently. A small town with a single Azure subscription and a handful of resource groups can often manage policy and RBAC at subscription and resource-group scope without building a management-group cathedral. Introducing management groups is most clearly justified when governance at scale across multiple subscriptions is the problem—not merely because a small estate exists.
Requiring a management group whenever any virtual machine is created misstates the trigger; VMs do not mandate management groups. Treating management groups as a blob-container renaming feature confuses governance hierarchy with storage organization. Saying management groups are used only after deleting all resource groups, because they replace resource groups, is wrong on both counts: management groups complement subscriptions and groups; they do not replace resource groups.
Exam caveat: even a single-subscription tenant has a root management group, but actively designing nested management groups is optional until multi-subscription governance needs appear. Operational check: before creating nested management groups, inventory how many subscriptions the town expects in the next planning cycle and whether shared policy initiatives must span them; if the answer is still one subscription, document subscription-scoped governance and revisit management groups when a second subscription is approved.