Management Group Hierarchy¶

The management group hierarchy is the governance backbone of the Grinntec Azure tenant. It determines where policies are applied, which teams can access which subscriptions, and how budgets and compliance are reported. Getting the structure right at the start avoids expensive reorganisation later.

The hierarchy¶

The Grinntec hierarchy follows the CAF enterprise-scale pattern with an intermediate root below the Azure tenant root. This is deliberate — assigning policies and roles at the mg-grinntec level rather than the Azure tenant root group gives full control without granting permissions above the tenant boundary.

Tenant Root Group  (Azure-managed, not touched)
└── grinntec       (mg-grinntec — intermediate root)
    ├── platform
    │   ├── connectivity
    │   ├── identity
    │   └── management  (reserved)
    ├── landingzones
    │   └── online
    ├── sandboxes
    ├── quarantine
    └── decommissioned

What each management group is for¶

mg-grinntec — Intermediate Root¶

The top of the Grinntec-controlled hierarchy. Policies and role assignments placed here inherit to every subscription in the tenant. Used for organisation-wide baselines only — tagging standards, Defender for Cloud enablement, and platform team access.

mg-platform¶

Groups all platform subscriptions that provide shared services to the rest of the organisation. The platform team manages these subscriptions directly. Child MGs map to CAF platform archetypes.

Child MG	Purpose	Subscription
`mg-connectivity`	Hub networking — ExpressRoute, VPN, DNS, firewalls	`gt-connectivity-prod-westeu`
`mg-identity`	Identity services — Entra ID, AD DS	(reserved)
`mg-management`	Central logging, monitoring, backup	(reserved)

mg-landingzones¶

Parent for all workload subscriptions. Workload teams land here. Child MGs differentiate governance posture by workload type.

Child MG	Purpose	Governance posture
`mg-online`	Internet-facing workloads	Stricter egress, WAF required
(mg-corp)	Internal workloads	No public IPs, private endpoints required

mg-sandboxes¶

Isolated developer and experimentation subscriptions. Looser policy enforcement to enable learning and prototyping. No production data permitted. Subscriptions here should be short-lived.

mg-quarantine¶

Restricted area for subscriptions under investigation or with suspected policy violations. Highly restrictive deny policies applied to limit blast radius. Move here before deciding whether to remediate or decommission.

mg-decommissioned¶

Final placement for subscriptions being retired. Policies prevent new resource creation. Resources should be deleted before the subscription is cancelled.

How it is managed¶

The hierarchy is managed entirely in Terraform in the azure-management-groups deployment. Each management group has its own .tf file.

module "mg_online" {
  source = "git::https://gitlab.com/grinntec-cloud/terraform-modules/terraform-azurerm-management-group.git?ref=v1.0.0"

  name                       = "mg-online"
  display_name               = "Online"
  parent_management_group_id = module.mg_landingzones.id
}

The module handles:

Creating the management group at the correct position in the hierarchy
Optional role assignments scoped to that management group
Stable for_each keys for role assignments to prevent destroy/recreate on reorder

Adding a new management group is a three-step process: copy an existing .tf file, update the name, display name, and parent, and open a merge request. The pipeline runs terraform plan as a comment and applies on merge.

Role assignments at management group scope¶

Role assignments placed at a management group scope are inherited by every child management group, subscription, resource group, and resource beneath it. This is the mechanism that gives the platform team consistent access across all subscriptions without per-subscription grants.

Assignment	Scope	Who
Owner	`mg-grinntec`	`grp-platform-engineers`
Cost Management Reader	`mg-grinntec`	`grp-finops-readers`
Reader	`mg-grinntec`	`grp-tenant-readonly`

These are managed in azure-platform-identity — see Platform Identity & RBAC.

Tip

Assign roles at the highest appropriate scope. A single Owner grant at mg-grinntec gives the platform engineering group access to every subscription that exists now and any that are added in the future — without touching individual subscriptions.

Service principal permissions¶

The sp-terraform-azure-management-groups service principal that runs the pipeline has exactly two roles at the tenant root management group:

Role	Why
Management Group Contributor	Create, update, and move management groups
User Access Administrator	Assign roles at management group scope

It has no permissions at subscription scope or below. A misconfiguration in the management groups pipeline cannot affect workload resources.

Naming convention¶

All management groups follow the mg-{name} prefix. The name value (the immutable Azure identifier) is always lowercase with hyphens. The display_name is the human-readable label shown in the portal.

Warning

The management group name field is immutable in Azure. Changing it destroys the management group and removes all RBAC assignments scoped to it. Child management groups are moved to the tenant root automatically by Azure. Plan the hierarchy carefully before creating groups.