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 can be placed under a management group. The key rule for the exam is that governance settings — Azure Policy assignments, role assignments, and resource locks — flow downward and are inherited by everything beneath the scope where you apply them.

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 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 can have only one parent management group, and all management groups and subscriptions belong to one Entra tenant. To create the hierarchy in the portal, use the Management groups blade, where you can add child groups and move subscriptions into them. Applying policy 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.

A subscription is both a billing 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 subscription for production and another for development — so costs, quotas, and governance stay cleanly divided. As an administrator you manage subscriptions from the Subscriptions blade, where you can view spending, set role assignments, and see the policies that apply.

You can move a subscription from one management group to another to reorganize your governance. When you move a subscription, it immediately begins to inherit the policies and role assignments of its new parent management group, so plan the move carefully — a subscription dropped under a stricter management group may suddenly report resources as non-compliant. To move a subscription you need appropriate permissions on both the subscription and the target management group. You can also move individual resources between resource groups or subscriptions, which is a different operation: not every resource type supports a move, and moving does not change the resource's region. Remember the distinction the exam draws — moving a subscription between management groups changes which governance it inherits, whereas moving a resource changes which resource group or subscription bills and contains it. Keep production and development in separate subscriptions so a policy or budget meant for one never touches the other.

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" (the "Require a tag" policy). An initiative (also called a policy set definition) is a group of policy definitions bundled together toward a goal, such as a security baseline containing dozens of related policies; you manage the group as one unit instead of assigning each policy separately. An assignment applies a definition or initiative at a scope — a management group, subscription, or resource group — and everything beneath that scope is evaluated.

When you create an assignment you set its parameters (for "Allowed locations" you choose the permitted regions) and its effect, and you can define exclusions for scopes that should be skipped. After assignment, Policy continuously evaluates existing resources and checks every new create or update request, producing a compliance view that shows which resources pass and which fail. On the exam, the trigger "a group of policies managed together" points to an initiative, while a single rule is a policy definition. Assign at the highest scope that fits so the rule is inherited widely — for a company-wide standard, assign at a management group.

The effect of a policy assignment decides what happens when a resource does not comply. The two you must know cold are Audit and Deny. Audit allows the resource but records it as non-compliant for reporting — nothing is blocked, so it is ideal for measuring how widespread a problem is before you tighten the rule. Deny actively blocks a non-compliant create or update request, so the resource is never created; this is how you stop deployments in unapproved regions or without a required tag. Other effects add or fix configuration rather than just judge it.

Remember: Audit reports, Deny blocks. When a scenario says "block non-compliant resource creation," the answer is the Deny effect; when it says "log but allow," it is Audit.

Azure Policy and role-based access control (RBAC) are complementary and easy to confuse, so the exam probes the difference. 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.

Use them together: RBAC decides who may deploy, and Policy decides what they may deploy. On the exam, the phrase "controls what is allowed versus who can act" maps Policy to what and RBAC to who. This lesson stays on the Policy side; the depth of assigning RBAC roles at different scopes belongs to the access-management topic.

A Deny policy stops new non-compliant resources, but it does not change resources that already exist and break the rule — those simply show as non-compliant. To auto-fix existing non-compliant resources you use remediation, which is available only with the effects that can change or deploy configuration: deployIfNotExists and modify. When you assign a policy that uses one of these effects, Azure Policy can create a remediation task that sweeps existing resources and brings them into compliance — for example deploying a missing diagnostic setting, or adding a required tag that resources created before the policy never had.

Because remediation actively writes to your resources, the policy assignment needs an identity with permission to make those changes. You grant this by giving the assignment a managed identity (system-assigned or user-assigned) and the appropriate role, so Policy can act on your behalf during remediation. Without that identity and role, a deployIfNotExists or modify assignment can evaluate compliance but cannot remediate. The workflow is: assign the policy with a deployIfNotExists or modify effect and a managed identity, let it evaluate, then create a remediation task (in the portal, under the assignment's remediation options) to apply the fix across resources already in scope. On the exam, "auto-fix existing non-compliant resources" points to remediation using deployIfNotExists or modify — Audit 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 at the subscription, resource group, or individual resource scope, and child resources inherit it. There are two lock levels. A CanNotDelete lock lets authorized users read and modify a resource but stops anyone from deleting it — the classic way to prevent accidental deletion of production systems. A ReadOnly lock is stricter: users can read the resource but cannot modify or delete it, effectively freezing its configuration.

The most important exam point is that locks apply regardless of RBAC — even a user with Owner or Contributor rights cannot delete a resource that carries a CanNotDelete lock. The lock overrides the permission. To create or remove a lock you need access to Microsoft.Authorization/locks/*, which the Owner and User Access Administrator built-in roles include. Be careful with ReadOnly: some operations that appear to only read actually use a write call under the hood (such as listing storage account keys), so a ReadOnly lock can cause unexpected failures. To change a locked resource you must remove the lock first, 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 can hold up to 50 tags. Critically, tags are not inherited by default — a resource does not automatically receive its resource group's or subscription's tags. To enforce and inherit tags you use Azure Policy: a "Require a tag" policy with the Deny effect blocks resources created without the tag, while a modify policy can add or inherit the tag onto existing resources through remediation.

Microsoft Cost Management controls spending. Cost analysis lets you explore and break down costs — including grouping by tag, which is why consistent tagging matters. A budget sets a spending threshold over a period (monthly, quarterly, or annually) and triggers an alert when actual or forecast spend crosses a percentage you choose — so you are notified when spend hits a threshold, though the budget does not itself stop resources. Azure Advisor adds cost recommendations, such as right-sizing or shutting down underused virtual machines. Before you deploy, the Pricing calculator and Total Cost of Ownership calculator help you estimate.

Scenario: to govern production, assign an "Allowed locations" policy with the Deny effect at the production management group so resources cannot be created outside approved regions; add a "Require a tag" policy demanding a CostCenter tag (Deny for new resources, modify to remediate existing ones); place a CanNotDelete lock on the production resource group to prevent accidental deletion; and create a monthly budget with an alert at 80% so finance is warned before overspending.