Subscriptions, management groups, policies, tags and budgets influence Azure administration in different ways. This AZ-104 guide follows a subscription governance change and shows how to distinguish inherited permissions, policy enforcement, resource metadata, cost reporting and budget alerts.
Cost control begins above a resource group
Azure administrators often inherit a collection of subscriptions that grew one team at a time. A development application is deployed into production, a cost center changes, and a central security policy suddenly blocks a deployment. The fix is rarely to disable every rule until the portal displays green. The organization needs a coherent resource hierarchy, role assignments at intentional scopes, a governance method that explains compliant states, and a way to connect usage to the teams responsible for it.
Governance spans different Azure control layers. Management groups provide inherited administrative scope, resource groups organize a deployment lifecycle, and RBAC, Azure Policy and locks separately govern actor permissions, compliant configuration and protection from change or deletion. Tags and Cost Management budgets help track ownership and spending but should not be mistaken for universal access controls. After moving a subscription between management groups, verify the newly inherited policy assignments and effective access decisions even if the resources themselves have not changed.
Build management groups around stable policy boundaries
Management groups let an organization apply governance above individual subscriptions. A subscription belongs to one management-group parent at a time; parent role assignments and policies can apply to descendants. A useful hierarchy could group production subscriptions separately from development, then distinguish regulated workloads or shared services where compliance requirements genuinely differ. Adding more levels should solve an operational problem, not merely mirror every reporting line on an organization chart.
For a fictitious retailer, place two application subscriptions under a production management group and a sandbox subscription under a development group. Define which policy should apply to both, which rule is production-only and which team owns delegated administration. Record the reason a subscription is placed there. When the business reorganizes, moving a subscription is not a cosmetic operation: it can inherit access and policy restrictions from a new parent.
Microsoft’s management-group guidance notes that hierarchy changes may take time to be reflected because of token and management-group caching. After a move, examine effective access and assignments; an apparently old browser view does not prove a governance rule vanished. Verify the new state through authoritative management-group and policy data.
Separate Azure Policy assignments from permissions
Azure Policy evaluates resource configurations against definitions and initiatives. A policy definition placed at a management group can be assigned to a suitable descendant scope, with documented exclusions or exemptions for legitimate cases. Its effects matter: a deny effect may prevent creation, while an audit-oriented effect reports noncompliance. A remediation effect may require a managed identity and correctly scoped permissions to change existing resources. A role assignment granting Contributor does not cancel a deny policy.
Choose an effect by consequence. For a cost-center tag, audit-before-enforcement can reveal old unmanaged resources. A deny rule may be appropriate once the deployment pipeline is ready to attach correct tags, but an immediate broad deny may break otherwise safe production recovery. Test exclusions at the exact resource scope, and review the change’s blast radius before applying it above many subscriptions.
Locks are another control layer. A CanNotDelete lock blocks supported control-plane deletion operations even from principals that can normally manage the resource, while a ReadOnly lock can block writes. These locks do not protect all data-plane operations. Use them deliberately on recovery-critical resources and test whether automation handles the resulting authorization failures. Do not rely on a lock to replace backup or retention policy.
Tags serve inventory, accountability and billing differently
Tags attach key-value metadata such as application, environment, owner or cost center to supported resources. They improve grouping and policy checks, but a resource group tag does not automatically become a resource tag simply because the resource is inside the group. Microsoft’s Cost Management documentation distinguishes direct resource tags from tag inheritance applied to cost usage records. Treat those as separate mechanisms.
A cost-analysis report may display an inherited department tag even when the underlying VM resource does not have that tag assigned. This can be useful for reporting, but it does not prove an Azure Policy requiring the resource tag will pass. Conversely, a deployment could have compliant resource tags while some usage records lack the expected cost classification because of support or refresh timing. Check both policy-compliance evidence and cost-detail evidence where money allocation matters.
Avoid secrets, private personal information or confidential ticket details in tag values. Microsoft warns that tags are plain-text metadata exposed through reports, templates and management operations. Use identifiers whose disclosure is acceptable, and manage the mapping to sensitive information elsewhere.
Budgets provide signals, not automatic spending brakes
Microsoft Cost Management can analyze expenditures and configure budgets and alerts. A budget can notify an owner when consumption crosses a threshold; a basic budget alert does not automatically shut down every Azure resource before further spending occurs. Administrators need a response runbook that states who reviews a breach, what evidence is gathered and which remediation can be taken without causing an outage.
Choose the financial scope deliberately: subscription, management group reporting or billing context may not mean the same owner sees or controls each cost line. Shared services make this more difficult. A central firewall or monitoring workspace can incur cost attributable to multiple teams. Cost allocation rules can help reflect that usage, but moving cost reports is not the same as moving an invoice or altering who holds resource permissions.
Budget alerts also differ from Azure Advisor recommendations. Advisor evaluates resource configuration and usage telemetry and groups suggestions into cost, reliability, performance, security and operational excellence. For a fictional overprovisioned app, a cost recommendation might point toward a smaller SKU, while an availability recommendation might favor keeping resilient capacity. The administrator should record the recommendation category, affected resources, evidence, budget owner and any trade-off before deciding whether to accept, postpone or dismiss it. Applying a cost-saving change without checking performance and redundancy can create an outage; conversely, dismissing an expensive resiliency measure purely because a monthly budget has been reached can leave an acknowledged risk untreated. Recheck actual workload use, supported SKU/region availability and application behavior after implementation. Advisor is decision support, not a permission system or an automatic spending brake, and a suggested change is not proof of savings until the resulting Azure usage and service health are observed.
For a fictional monthly budget, suppose engineering receives a warning before reaching its planned capacity. The operator should inspect Cost Analysis, service and region trends, unusual deployment changes and the period under consideration. If spend is caused by a required surge, a capacity or budget decision may be appropriate; shutting off an essential resource solely because the warning appeared is unsafe.
Plan a subscription move like a production change
Consider moving one subscription from a development management group into production. Before the move, list inherited role assignments, policy definitions, compliance exceptions, monitoring destinations, billing ownership and support contacts. Simulate how a new production-only region policy would affect the currently deployed VMs and storage. A resource already present may become noncompliant even if the policy’s deny effect mainly influences subsequent changes.
A failed deployment after the move should be diagnosed by reading the policy assignment and effect. If an administrator previously had a broad role at the old parent, their permissions may differ under the new hierarchy. Use an approved deployment identity with the correct scope, not a temporary global Owner assignment. Keep a rollback plan and record the exact subscription ID and management-group assignment before and after change.
The change log should preserve which controls were expected, which were actually inherited and when the change became visible. A screenshot of the resource group name is not sufficient proof the policy hierarchy changed correctly.
An administrator’s verification and incident checklist
Set up a synthetic management hierarchy and a table of three expected results: a prohibited location deployment should be denied, a permitted development deployment should remain possible and an untagged resource should be detected or remediated according to the chosen policy effect. Measure outcomes with actual policy compliance and resource metadata. Then create a budget alert scenario where cost rises because an autoscale setting added capacity. The test passes when the team identifies the cost driver and correctly handles the alert, not when every cloud service is automatically disabled.
Include failure cases: policy is assigned at the wrong management-group scope; a resource group is excluded unexpectedly; an inherited tag appears only in Cost Management; a lock blocks an intended deletion; and a subscription move causes a formerly working role assignment to disappear. In each case identify the controlling service before prescribing a fix. All cases in this article are exercises, not recorded deployments.
Governance controls are easier to choose when the expected outcome is explicit. A management group can supply inherited policy scope, tags may label resources, and Cost Management budgets can notify owners without automatically stopping a deployment. Consider a VM whose resource group has a costCenter tag but the VM itself does not: a cost report using supported inherited reporting tags may differ from an Azure Policy check on the VM’s actual tags. Test that distinction before deciding whether the remedy is a policy assignment, tag correction or budget alert. AZ-104 governance practice questions should reward that separation of permission, compliance and spending signals, not treat all three as equivalent access-control mechanisms.
Test the difference between reporting and enforcement
Use a small synthetic resource inventory to demonstrate tag inheritance versus actual resource properties. Create a table of resource IDs, direct tags, resource-group tags and expected Cost Management reporting tags. In one case the application VM has no costCenter tag, but its resource group does. Under a supported inherited cost-tag setting, the spending report may show a cost center even when an Azure Policy evaluation still reports the VM as untagged. Document the expected difference and check both surfaces in a real lab rather than declaring either wrong.
A second case tests a policy remediation assignment that lacks the managed identity’s required permission. The policy may correctly identify noncompliance, but the remediation task can still fail. Inspect the policy assignment identity and targeted scope before broadening roles. A third case moves a subscription under a different management group and checks that only intended role and policy inheritance changes are accepted.
A final governance acceptance record should distinguish assignment from enforcement, alerts from spending limits, and cost attribution from resource security. Those boundaries remain important when a team automates policy deployment through Bicep or ARM: successful deployment of the rule isn’t proof of compliant resource state.