Azure Subscriptions, Policy, Locks and Governance (AZ-104)

Azure organizes everything into a four-level hierarchy, and understanding it is the foundation of governance. From the top down the levels are: management group, subscription, resource group, and resource. A resource (such as a virtual machine or storage account) lives in exactly one resource group; a resource group lives in one subscription; and a subscription sits under a management group. Governance settings — Azure Policy assignments, role assignments, and resource locks — flow downward and are inherited by everything beneath the scope where you apply them. (Locks are the exception at the top: they can be set on a subscription, resource group or resource, but not on a management group.)

Management groups sit above subscriptions and let you apply governance to many subscriptions at once. You might create a management group for "Production" and another for "Development," then assign a policy to each so every subscription inside — including subscriptions added later — inherits it. Each Microsoft Entra tenant has a single top-level root management group, and you can build a tree up to six levels deep beneath it (not counting the root or the subscription level). A subscription or management group has exactly one parent, and all management groups and subscriptions belong to one Entra tenant. Assigning at a management group is the most efficient way to govern an entire organization from one place, rather than repeating the same assignment in every subscription.

Moving a subscription between management groups changes what it inherits. Because there is only one parent, the new parent's policy and role assignments start to apply and the old parent's stop applying. A stricter Deny policy inherited this way does not delete or alter resources that already exist — they keep running and are reported as non-compliant — but new and updated requests are evaluated against it. To move a subscription you need:

• Owner on the subscription being moved;
• management group write permission (for example Management Group Contributor) on the target parent management group;
• the same write permission on the current parent management group.

When the target or current parent is the root management group, the permission requirement for that side doesn't apply. The same parent-side permissions apply when you move a child management group.

A subscription is a billing boundary, a quota boundary and a scope for access and policy. Resources you create are billed to their subscription, and administrators commonly use separate subscriptions to isolate environments — for instance one for production and another for development — so costs, quotas and governance stay cleanly divided. You manage subscriptions from the Subscriptions blade, where you can view spending, set role assignments, and see the policies that apply.

Quotas are per subscription, per region. Limits such as total regional vCPUs and vCPUs per VM family are counted for the whole subscription in one region; resource groups and management groups do not carry quotas. When a deployment fails because it would exceed a quota, request an increase for that subscription and region from the Quotas page (or a support request) — the quota is consumed per region, so only an increase in that region helps.

Two subscription operations are easy to confuse:

After a directory change you must re-create role assignments for identities in the new tenant, and re-create managed identities: disable and re-enable a system-assigned identity, or delete, re-create and re-attach a user-assigned one, then grant their roles again. Key Vault tenant IDs and access policies also need updating. Resources, resource groups, tags and data such as Key Vault secrets are not affected. (A billing transfer to an account in a different tenant can bring a directory change with it, with the same effect on access.)

Cancelling a subscription is not blocked by resource locks. Azure deactivates the subscription's resources rather than deleting them at once, and they are deleted only after a waiting period — locks protect against deleting individual resources, not against ending the subscription that holds them.

A resource group is a logical container for resources that share a lifecycle: you deploy, manage, tag, lock and delete them together. A resource belongs to exactly one resource group, and deleting a resource group deletes every resource in it. The group has a location of its own (where its metadata is stored), but the resources inside it can be in other regions.

You can move resources to another resource group or another subscription. The rules the exam relies on:

• The region does not change. A move changes the container, not where the resource runs; moving to another region is a different process (such as Azure Resource Mover or redeploying).
• The resource ID changes, because it includes the subscription and resource group, so scripts and templates that reference the old ID must be updated.
• Both resource groups are locked during the move — write and delete operations on the source and target groups are blocked until it finishes, but the resources themselves keep running.
• Not every resource type can be moved, and some can move between resource groups but not between subscriptions; check the move-support list first.
• For a move to another subscription, the destination subscription must be registered for the resource provider, and both subscriptions must be in the same Microsoft Entra tenant.
• Dependent resources. For a move to another subscription, a resource and its dependent resources (for example a VM, its disks and its network interface) must sit in the same resource group and be moved together — if they are spread across groups, consolidate them first. For a move between resource groups in the same subscription, the dependents must either already be in the destination group or be included in the same move request.
• A ReadOnly lock on the source or destination resource group or subscription blocks the move.
• Role assignments made directly on the resource are not moved and become orphaned; re-create them after the move. Assignments inherited from the destination scope apply automatically.

Keep the distinction clear: moving a subscription between management groups changes which governance it inherits, whereas moving a resource changes which resource group and subscription contain and bill it.

Azure Policy enforces organizational standards by evaluating your resources against rules and reporting or blocking configurations that break them. Working with Policy involves three parts. A policy definition is a single rule — for example "resources may only be created in approved regions" (the built-in Allowed locations policy) or "every resource must carry a given tag." An initiative (also called a policy set definition) is a group of policy definitions bundled toward a goal, such as a security baseline containing dozens of related policies; you assign and track the group as one unit. An assignment applies a definition or initiative at a scope — a management group, subscription or resource group — and everything beneath that scope is evaluated.

Where a custom definition is saved limits where it can be assigned. You save a custom definition or initiative at a management group or a subscription, and it can be assigned only at that scope or below it. A definition saved in one subscription cannot be assigned to a sibling subscription; to reuse it across many subscriptions, save it at a management group above them. Built-in definitions are available everywhere.

Parameters make one definition reusable. Allowed locations takes a list of regions as a parameter, so you can assign the same definition several times at different scopes — for example West Europe only for one subscription and East US plus West US for another — rather than writing a new definition per region set. Assignments are cumulative: a resource must satisfy every assignment that reaches it.

Each assignment also has an enforcement mode. The default, Default (Enabled), enforces the effect. DoNotEnforce evaluates and reports compliance but does not apply the effect — a Deny assignment does not block anything — which lets you test the impact of a rule on real resources and then switch the same assignment to Default, without creating a new one. After assignment, Policy evaluates existing resources and every new create or update request, producing a compliance view of which resources pass and which fail.

An exclusion removes a scope from an assignment so it is not evaluated at all; an exemption keeps the scope evaluated but records that it is excused from the rule. Both narrow an assignment, but they answer different needs.

Use an exclusion when a scope simply should never be governed by that assignment, such as a sandbox resource group. Exclusions can be added or changed after the assignment is created by editing its notScopes. Use an exemption when the exception must stay visible and accountable: choose Mitigated when a compensating control already meets the intent, and Waiver when the business accepts the non-compliance for now. When an exemption reaches its expiresOn date it is not deleted — the object is kept for the record — but it is no longer honored, so the resource is evaluated normally again. For an initiative assignment, list the policyDefinitionReferenceId values to exempt a resource from only some of the initiative's definitions while the rest still apply.

The effect of a policy decides what happens when a resource does not comply. Audit allows the resource but records it as non-compliant — nothing is blocked, so it is ideal for measuring a problem before you tighten the rule. Deny blocks a non-compliant create or update request, so the resource is never created or changed. Deny evaluates create and update requests only: it never acts on delete requests and does not remove resources that already exist. Blocking deletion by policy is the job of DenyAction.

DenyAction versus resource locks. Both stop deletion, but they reach different scopes. A DenyAction policy can be assigned at a management group and target resources by their properties (such as a tag), so it protects matching resources in every current and future subscription beneath it. A resource lock can be placed on a subscription, resource group or resource — not on a management group — and protects everything at and below where it sits. Choose DenyAction for "protect resources of this kind across many subscriptions," and a CanNotDelete lock for "protect this resource or group."

Remember: Audit and AuditIfNotExists report, Deny blocks creates and updates, DenyAction blocks deletes, and Modify and DeployIfNotExists fix.

Azure Policy and role-based access control (RBAC) are complementary and easy to confuse. RBAC controls who can act — it grants identities (users, groups, service principals, managed identities) permission to perform actions on resources, such as "Contributor on this resource group." Azure Policy controls what is allowed — it governs the configuration a resource may have, regardless of who is making the change. A user with full Owner rights is still stopped by a Deny policy if their deployment violates the rule, because the two systems evaluate different questions.

Requirements often need both. An RBAC role must cover every resource an operation touches, not just the main one. Creating a VM also attaches its network interface to a subnet, which is an action on the virtual network (Microsoft.Network/virtualNetworks/subnets/join/action). The built-in Virtual Machine Contributor role includes that join action but no write access to virtual networks or NSGs, so it lets people place VMs on existing subnets without changing the network itself. A custom role restricted to Microsoft.Compute actions has no join permission, so VM creation fails at the networking step. Limits on what gets deployed — permitted regions, VM sizes, SKUs — are configuration rules and belong to Policy, which applies them to every requester regardless of role. Many built-in definitions have a fixed effect: Allowed locations and Allowed virtual machine size SKUs always Deny. To only report violations instead, you need a custom copy of the definition with Audit (or an effect parameter), because a built-in definition's fixed effect cannot be changed.

RBAC decides who may deploy, and Policy decides what they may deploy. The depth of assigning RBAC roles at different scopes belongs to the access-management topic.

Remediation is how Azure Policy fixes resources that already exist and break a rule. A Deny policy stops new non-compliant requests, but existing resources that break the rule simply show as non-compliant. Remediation is available only with the effects that can change or deploy configuration: deployIfNotExists and modify. New and updated resources are fixed as they are deployed; for resources already in scope you create a remediation task that sweeps them and brings them into compliance — for example deploying a missing diagnostic setting, or adding a tag that resources created before the policy never had.

Because remediation writes to your resources, the remediation deployments run as the assignment's managed identity (system-assigned or user-assigned), not as the person who created the task. That identity needs the roles the policy definition lists in its roleDefinitionIds property, at the scope where it must act. When you create the assignment in the portal, Azure Policy can create the identity and grant those roles for you. When you create it another way — Azure CLI, PowerShell or a template, for instance with an existing user-assigned identity — check that the identity holds those roles and add any missing role assignments yourself; otherwise the assignment evaluates compliance but its remediation tasks fail.

The workflow: assign the policy with a deployIfNotExists or modify effect and a managed identity that holds the required roles, let it evaluate, then create a remediation task from the assignment to apply the fix across resources already in scope. Audit, AuditIfNotExists and Deny cannot remediate, because they only report or block.

Resource locks protect critical resources from accidental change or deletion. You can place a lock on a subscription, resource group or individual resource (not on a management group), and child resources inherit it. There are two lock levels.

Locks apply regardless of RBAC — even an Owner cannot delete a resource that carries a CanNotDelete lock until the lock is removed. A lock on one resource also stops its resource group from being deleted, because deleting the group would delete the locked resource. Who can manage locks: creating or removing a lock needs Microsoft.Authorization/locks/*, which Owner and User Access Administrator include. Contributor cannot create or remove locks, because that role excludes Microsoft.Authorization/*/write and delete actions.

Locks govern the control plane only. They apply to Azure Resource Manager operations on the resource (management.azure.com), not to data-plane operations. A CanNotDelete lock on a storage account stops the account from being deleted but does not stop anyone with data access from writing or deleting blobs; a lock on a SQL server doesn't stop data being deleted from its databases.

ReadOnly blocks more than it seems to. It blocks every write request, including POST actions that don't look like changes: starting, stopping, restarting or resizing a VM, adding a tag, and listing storage account keys (a POST), which breaks tools that use key-based access. Only reading properties, metrics and logs keeps working. A ReadOnly lock on a source or destination group or subscription also blocks resource moves.

CanNotDelete has side effects too. Azure Backup keeps instant-restore points in a resource group it manages and deletes old ones as they expire; a CanNotDelete lock on that group — including one inherited from the subscription — stops the clean-up, the limit on restore points is reached, and backups fail. Locks also don't block cancelling the whole subscription. To change a locked resource, remove the lock, make the change, and reapply it.

Tags are name-value pairs (such as CostCenter = 1001 or Environment = Production) that you attach to subscriptions, resource groups and resources to organize and report on them. A resource, resource group or subscription can hold up to 50 tags. Tags are not inherited — a resource does not automatically receive its resource group's or subscription's tags. Applying a tag is a write operation, so it needs write permission on the resource (the Tag Contributor role grants tag changes without other access) and is blocked by a ReadOnly lock.

To enforce or copy tags onto resources you use built-in Azure Policy definitions, whose effects are fixed:

The Deny definitions only stop new or updated non-compliant resources. The Modify "Inherit a tag…" definitions write the tag onto resources as they are created or updated, and a remediation task applies it to resources that already exist. Similar Modify definitions inherit from the subscription.

Cost Management tag inheritance is a different feature with a similar name. Available for Enterprise Agreement, Microsoft Customer Agreement and Microsoft Partner Agreement accounts, it applies subscription and resource group tags to the usage records of child resources so cost reports can group by them — including the current month's charges. It does not write tags to the resources themselves. Use it when the goal is cost reporting by tag; use the Modify policy when the tag must actually exist on the resource.

Microsoft Cost Management lets you analyze, budget and alert on Azure spending. Cost analysis breaks costs down by service, resource group, location or tag — which is why consistent tagging matters. Before you deploy, the Pricing calculator and Total Cost of Ownership calculator help you estimate.

A budget sets an amount over a period (monthly, quarterly or annually) and raises alerts when cost crosses percentages you choose. Each alert condition is either Actual (cost already incurred) or Forecasted (cost projected to cross the threshold by the end of the period, which warns earlier). By itself a budget only notifies — resources keep running. To automate a response, attach an action group to the alert, which can call a runbook, Logic App or function, for example to deallocate development VMs. Action groups can be attached only to budgets at the subscription or resource group scope; budgets at a management group or billing scope send email alerts only.

The only built-in hard stop is the spending limit, and it exists only on credit-based offers such as the Azure free account and Visual Studio subscriptions. When the credit is used up, the subscription's resources are disabled until the next billing period's credit arrives, unless the owner removes the spending limit and pays for the overage. Pay-as-you-go subscriptions have no spending limit.

Azure Advisor provides personalized cost recommendations:

• Right-size or shut down underused VMs and scale sets, based on utilization — CPU and outbound network for shut-down recommendations, plus memory for resize recommendations;
• buy reservations or an Azure savings plan for steady, long-running usage;
• remove or reconfigure idle or unused resources, such as unassociated public IP addresses or idle virtual network gateways.

You can tune the VM right-sizing recommendations per subscription in Advisor Configuration. The lookback period sets how much usage history Advisor analyzes — 7 days by default, or 14, 21, 30, 60 or 90 days — so a workload with weekly or monthly usage cycles needs a window long enough to capture its busy periods (updated recommendations can take up to 48 hours). The CPU utilization setting is a filter: it controls which recommendations you see, not how Advisor calculates them.

A typical production setup combines every tool in this lesson, each doing the job it is built for. Assign Allowed locations (Deny) at the production management group, with the approved regions as its parameter, so no subscription beneath it — current or future — can create resources elsewhere. Assign Require a tag on resources for CostCenter (Deny for new resources) and Inherit a tag from the resource group if missing (Modify, with a remediation task for existing resources), giving the assignment a managed identity that holds the definition's roles. Place a CanNotDelete lock on the production resource group — but not on the resource group Azure Backup uses for restore points. Record a sandbox with a time-limited Waiver exemption rather than an exclusion so the exception stays visible. Finally, create a monthly budget on each production subscription with a forecasted alert at 80% and an action group for the operations team, and review Advisor's cost recommendations each month.