Azure Governance Design for AZ-305: Management Groups, Subscriptions, Tagging, Azure Policy and Identity Governance

Azure governance is applied at four nested scopes — management group, subscription, resource group and resource — and Azure RBAC role assignments and Azure Policy assignments made at a scope are inherited by everything below it. Designing governance for AZ-305 is mostly choosing the highest scope where a rule is true for everything beneath it, so it is assigned once and automatically covers resources and subscriptions added later.

Inheritance has three consequences the exam relies on:

• Assign once, high enough. A policy or role assigned at a management group reaches every current and future subscription under it. Scripting the same assignment into each subscription works today but misses the next subscription.
• Policy is not RBAC. A deny policy blocks a request no matter who sends it, subscription Owners included. Roles grant permissions; policies constrain what any permission can create or change.
• Tags are the exception. Tags are not inherited by the resources below a subscription or resource group (see the tagging section).

Authentication and authorization design (Conditional Access, RBAC role choice, managed identities, Key Vault) belongs to the sibling lesson on identity, and monitoring design to the logging and monitoring lesson. This lesson covers the governance skill: structure and tagging, compliance, and identity governance.

Design management groups around the policies and access that differ between groups of workloads (their archetypes), not around environments, departments or individual applications. The Cloud Adoption Framework's Azure landing zone hierarchy is the reference design Microsoft expects you to recognise:

• Intermediate root (for example "Contoso") directly under the tenant root group, holding policies that apply to the whole estate. Keeping your own root below the tenant root avoids assigning to the tenant root itself.
• Platform, with child groups for shared services such as identity, management (logging) and connectivity (hub networking).
• Landing zones, with archetype children such as Corp (internal, privately connected workloads) and Online (internet-facing workloads, for example with web application firewall requirements).
• Sandbox for experimentation: relaxed policies, no connection to corporate networks, isolated from production governance.
• Decommissioned for subscriptions being retired.

Environments are subscriptions, not management groups. An application's development, test and production subscriptions all sit in the same archetype group (for example Corp), so the policy set is assigned once per archetype and a workload never has to be re-parented when it is promoted. Splitting the hierarchy by environment as well as by archetype duplicates policy assignments, and adding groups that carry no distinct policy only adds administration.

Management group facts

• Each management group and each subscription has exactly one parent.
• A hierarchy supports up to six levels of depth, not counting the root level or the subscription level.
• Every tenant has one tenant root group; it cannot be moved or deleted.
• By default, new subscriptions land directly under the tenant root group. In the hierarchy settings you can change the default management group so new subscriptions arrive in a governed group (such as Sandbox) and inherit its policies from creation. You can also require authorization before anyone creates new management groups.

Moving a subscription between management groups

Moving a subscription needs write rights in three places: management group write and role assignment write on the subscription itself (Owner is the built-in example — Contributor cannot write role assignments), plus management group write on both the current parent and the new parent (Owner, Contributor or Management Group Contributor). After the move, the subscription stops inheriting everything assigned at the old parent and starts inheriting the new parent's roles and policies; assignments made directly on the subscription are kept.

Create a separate subscription when a workload needs its own billing destination, its own quotas and limits, or its own administrative and scale boundary; use resource groups for everything a single subscription can already separate.

Billing structures hold subscriptions: in a Microsoft Customer Agreement (MCA) a subscription is billed to one invoice section within a billing profile; in an Enterprise Agreement subscriptions belong to enrollment accounts. The general rule: when a unit needs separate billing or separate administration, give it its own subscription and attach that subscription to the right billing scope; when it must also keep central governance, place the subscription below the management group where those policies are assigned. Inheritance flows only downward, so a sibling group receives nothing, and a separate Microsoft Entra tenant sits outside the hierarchy altogether.

Designing resource groups

• Group by shared lifecycle. Resources deployed, updated and deleted together (an app, its database and its storage for one environment) share a group. Shared infrastructure used by many teams, such as a hub virtual network, lives in its own group so deleting an application never touches it.
• A resource belongs to one resource group, and resources in a group can be in different regions.
• The resource group's location stores its resources' metadata. If that region is unavailable, the resources keep running but you cannot update them through Azure Resource Manager — no scaling or reconfiguration. Place each resource group in the same region as its resources.
• Grouping by resource type or by region ignores lifecycle and is not a recommended pattern.

A tagging strategy defines a small set of required tags (such as CostCenter, Owner, Environment, Application) and enforces them with Azure Policy, because tags on a subscription or resource group are not inherited by the resources inside it. A tag on a resource group does not appear on its resources' usage records unless something copies it down.

Tag rules worth knowing

• A resource, resource group or subscription holds up to 50 tag name/value pairs; not every resource type supports tags.
• Tag names are case-insensitive for operations; tag values are case-sensitive. Some characters (such as <, >, %, &, \, ?, /) are not allowed in names.
• Tags are metadata in plain text — never put secrets or personal data in them.

Built-in tag policies

The modify policies act on new and updated resources; existing resources are fixed with a remediation task. A common combined design is to deny resource groups that lack the required tags, then let an inherit-from-resource-group modify policy copy those tags onto every resource, with remediation for what is already deployed. That rejects only badly formed resource groups while application deployments never fail.

Cost Management tag inheritance is a different feature

Cost Management tag inheritance applies billing, subscription and resource group tags to usage records only — it never changes the resources. It is available for Enterprise Agreement, Microsoft Customer Agreement and Microsoft Partner Agreement accounts, is enabled in Cost Management (on the EA enrollment or MCA billing profile), and applies to the current month's usage (records update within about a day).

When a resource already has the same tag with its own value, the resource's tag wins by default; a setting in tag inheritance lets the inherited subscription or resource group tag override it instead. Cost allocation rules are another separate feature: they redistribute the cost of shared subscriptions, groups or tags to other targets rather than tagging usage.

Choose the policy effect by what must happen to a non-compliant request: reject it (deny), only report it (audit), report a missing related resource (auditIfNotExists), create that related resource (deployIfNotExists), change the resource's properties or tags (modify, append), or block a delete (denyAction).

• deny vs denyAction: deny blocks creating or changing a non-compliant resource; denyAction blocks deleting resources that already exist. Neither cares about the caller's role.
• denyAction and resource group deletion: by default, deleting the parent resource group still deletes the protected resource. Setting cascadeBehaviors with resourceGroup to deny in the policy rule makes the resource group deletion fail too.
• deployIfNotExists vs auditIfNotExists: both look for the same related resource; only deployIfNotExists fixes it. Choose modify when the change is a property or tag on the resource itself, deployIfNotExists when it is a separate child or extension resource.

A policy definition is saved at a management group or subscription and can only be assigned at that scope or below it; an assignment applies it, an initiative bundles definitions, and exclusions and exemptions carve out exceptions in two different ways.

• Definition location matters. A custom definition saved in one subscription cannot be assigned in its sibling subscriptions. Save shared definitions at the management group that contains every target, then assign there once so subscriptions added later are covered.
• Initiatives (policy set definitions) group related policies — for example a regulatory baseline — so they are assigned, parameterised and reported together.

When a scope must be allowed out of compliance for a limited time and the break must stay visible, an exemption with the Waiver category and an expiration date fits: it records why, can target only some of an initiative's policies, and ends by itself. Mitigated is for a control met by a different means, which is not the same as "not yet compliant".

Remediating existing resources

Assignments with modify or deployIfNotExists fix new and updated resources automatically, but resources that existed before the assignment stay non-compliant until a remediation task runs against them. Both effects act through the assignment's managed identity, which needs the roles listed in the definition (its roleDefinitionIds). The Azure portal grants those roles when it creates the assignment; Azure CLI, PowerShell and templates do not, so you must create the role assignments yourself — without them the automatic deployments fail as well as remediation.

Compliance is evaluated when an assignment is created or changed, when resources are created or updated, on a regular cycle (about every 24 hours), and on demand. An on-demand evaluation scan only refreshes compliance results — it never changes a resource.

Use the regulatory compliance dashboard in Microsoft Defender for Cloud to measure your own Azure resources against a standard, the Microsoft Service Trust Portal for Microsoft's own audit reports, Azure Policy location policies for data residency, and Azure Policy machine configuration for settings inside the operating system.

Defender for Cloud vs Service Trust Portal

The dashboard starts with the Microsoft cloud security benchmark; you add further standards (for example PCI DSS or ISO 27001) and can add your own Azure Policy initiative as a custom standard so internal controls are tracked in the same dashboard. An auditor usually needs both views: Microsoft's audit evidence and your own resources' posture. Azure Advisor recommendations are not mapped to regulatory controls.

Data residency

• The built-in Allowed locations policy restricts the regions resources can be deployed to. It does not evaluate resource groups, and it excludes resources deployed to the global location (such as Azure Front Door, Traffic Manager and DNS zones).
• Assign Allowed locations for resource groups as well, because a resource group's location is where its resources' metadata is stored.
• Global services are not stopped by any location list; govern them with Not allowed resource types (or an allowed-types list) if they need approval.
• Assign both location policies at the management group so every current and future subscription inherits them. A management group itself has no region.

Settings inside the operating system: machine configuration

Ordinary policy rules evaluate Azure Resource Manager properties, so they cannot see password complexity, TLS settings or installed software inside a server. Azure Policy machine configuration (formerly guest configuration) audits — and, with apply modes, can configure — settings inside Windows and Linux on Azure VMs and Azure Arc-enabled servers, reporting into Azure Policy compliance. Its modes are audit, apply and monitor, and apply and auto-correct.

• Azure VMs need the machine configuration extension and a system-assigned managed identity; the built-in prerequisites initiative deploys both.
• Arc-enabled servers already have machine configuration built into the Azure Connected Machine agent.
• Azure Automation State Configuration is retiring (30 September 2027) and is not a choice for new designs; Change Tracking and Inventory records changes rather than evaluating a baseline.

Use resource locks to stop accidental deletion or change of specific resources, deployment stacks to keep platform-deployed resources from being changed by anyone except the deploying pipeline, and template specs to share approved, versioned templates under Azure RBAC.

• Locks apply to every user, inherit down from the scope where they are set, and are removed by anyone with lock permissions — they protect against accidents, not against Owners.
• A deployment stack is an Azure resource that manages a group of resources from one Bicep or ARM deployment, applies deny settings through deny assignments, and decides what happens to resources dropped from the template (detach or delete). To protect resources inside a subscription from that subscription's own Owners, create the stack at a parent scope — the management group — targeting the subscription, so Owners there cannot simply delete the stack. You can exclude a small number of principals, such as the pipeline's identity.
• Template specs store ARM or Bicep templates as versioned Azure resources. Teams in other subscriptions deploy them with Reader access granted through Azure RBAC — no storage SAS tokens or public links.
• Azure Blueprints is deprecated and retires on 31 January 2027. Microsoft's replacements are template specs and deployment stacks (with Azure Policy for rules); do not recommend Blueprints for a new design.

Microsoft Entra Privileged Identity Management (PIM) replaces standing administrator access with eligible assignments that a user activates just in time, under rules you set per role: maximum duration, MFA or an authentication context, justification and approval, all recorded for audit. PIM covers Microsoft Entra roles, Azure resource roles (at management group, subscription, resource group or resource scope) and group membership or ownership (PIM for Groups). It needs Microsoft Entra ID P2 or Microsoft Entra ID Governance licences.

Role settings

• Activation: maximum activation duration (1 to 24 hours), require Azure MFA or a Microsoft Entra Conditional Access authentication context, justification, ticket information, approval by named approvers.
• Authentication context lets one role's activation demand a specific authentication strength (such as phishing-resistant MFA) through a Conditional Access policy that targets that context, without changing any other sign-in or role.
• Assignment: allow permanent eligible or active assignments, or make them expire after a set period (for example six months), plus MFA and justification on active assignment. Eligible-assignment expiry ends the eligibility itself; maximum activation duration only limits each activation.

PIM for Groups

When several roles must be activated together — Azure roles across many subscriptions plus a Microsoft Entra role — assign all of them to one group and make users eligible members of the group through PIM for Groups. One activation and one approval then grant every role, and eligibility is managed in one place. Microsoft Entra roles can only be assigned to a role-assignable group, and role-assignable groups cannot be dynamic. Assigning Azure roles at a management group already covers its subscriptions, but it does not bundle activation with an Entra role.

Microsoft Entra ID Governance covers the rest of the identity lifecycle: access reviews periodically recertify who still needs access, entitlement management grants bundled access through requestable or automatic access packages, and lifecycle workflows automate joiner, mover and leaver tasks from HR dates.

Access reviews

• What can be reviewed: group and Teams membership, application access, access package assignments, and — created through PIM — Azure resource roles and Microsoft Entra roles, covering both eligible and active assignments.
• Reviewers: group owners, selected users, the users' managers, or users reviewing themselves. With managers as reviewers, add fallback reviewers for users who have no manager.
• Settings: recurrence (weekly to annual), auto apply results, and If reviewers don't respond (no change, remove access, approve access, or take recommendations).
• Denied guests: only when the review's scope is limited to guest users can you choose an action for denied guests: remove the membership from the resource, or block sign-in for 30 days, then remove the user from the tenant — the grace period lets mistakes be reversed.

Entitlement management

• An access package bundles groups and teams, applications and SharePoint sites from a catalog, granted through policies.
• Policies for users in your directory, or for users not in your directory: specific connected organizations, all configured connected organizations, or All users (all connected organizations plus any new external users) — with All users, organizations of approved new requesters are added as proposed connected organizations, so domains need not be known in advance.
• Policies set approvers (including multi-stage approval, such as a partner's own sponsor followed by an internal one), expiry and reviews. When an external user brought in by entitlement management loses their last assignment, their account can be blocked from sign-in and removed from the directory after a set period (30 days by default).
• Incompatible access packages (or groups) enforce separation of duties at request time: a user holding one cannot request the other.
• Automatic assignment policies assign an access package to internal users who match an attribute rule (for example department equals Sales) and remove it when they stop matching — no requests or approvals.

Lifecycle workflows

Lifecycle workflows (part of Microsoft Entra ID Governance) run built-in tasks on a schedule relative to employeeHireDate (joiner, including pre-hire) or employeeLeaveDateTime (leaver), or on attribute changes (mover). Joiner tasks include generating a Temporary Access Pass and sending it to the manager, so a new hire can register passwordless sign-in on day one, and sending a welcome email; leaver tasks include disabling the account, removing it from all groups and Teams, removing licences, and emailing the manager. HR provisioning populates the date attributes, so no custom scripts are needed.