An Azure subscription may begin as a simple billing container and quietly become the boundary for deployment authority, policy and operational ownership. A team can provision resources into the right region, tag them consistently and still discover that costs are rising in an unmanaged resource group. A budget notification arrives, but production keeps consuming resources because budgets are designed to alert, not to shut down applications. That difference is essential when building a governance system people can actually operate.
A storage team adds cross-region replication to improve resilience, and the subscription budget begins issuing alerts. The alert is informative; it does not automatically stop production resources. For Microsoft AZ-104 governance, the first task is to identify the cost driver, its owner and its applicable scope—not to disable a valid production capability or widen privileges.
Choose management boundaries before deploying resources
Management groups organize subscriptions under broader policy and access boundaries. Subscriptions provide distinct billing, quota and governance scopes. Resource groups collect resources that share an administrative lifecycle. These abstractions overlap operationally but are not interchangeable. Putting applications in the same resource group solely because they belong to one department can complicate deployment and deletion when their release schedules differ.
Use Management groups to apply common governance boundaries above individual subscriptions when the organization needs inherited policy and delegated oversight. Resource groups alone do not replace those subscription-level decisions.
Consider a company with regulated workloads and a research sandbox. Management groups can apply different policy and role assignments to the subscription families. Within each subscription, resource groups can reflect the lifecycle of an application stack rather than creating one enormous bucket. A shared network hub may have an owner separate from the apps that consume it. The design should make ownership visible without forcing all systems into the same maintenance window.
Moving resources has constraints. A move between resource groups is not automatically equivalent to moving a VM to a different region or virtual network, and the operation can change inherited policy and RBAC behavior. Validate allowed move combinations, dependent resources, locks and downtime implications before moving anything. The new location in a hierarchy may alter both who can operate the resource and which configurations are compliant.
Subscription governance is an inheritance system
An assignment made at a management group can flow into child subscriptions. Resource-group and resource assignments can be more specific, but a narrow role does not automatically cancel a broader inherited grant. Administrators therefore need a tree view when investigating a security or configuration problem, not a single screenshot of the current resource.
Azure RBAC determines who is authorized to change a resource at a given scope. Subscription and management-group inheritance should be checked before granting a local exception to solve what appears to be an access failure.
Policy assignments can also inherit from higher scopes. A resource denied by policy may have a perfectly legitimate operator and correct template. The right troubleshooting sequence is to identify the assignment, effect, parameters, exemptions and current compliance state before attempting another deployment. A deny result should prompt examination of the resource properties, not an upgrade of the deployer to an unrestricted role.
Infrastructure as code improves consistency across subscriptions when templates accept carefully chosen parameters and scope assignments are understood. In Bicep and ARM deployments, deployment scope and policy conflicts are operational realities. Use preflight validation and staged releases rather than treating management-group inheritance as a documentation-only concern.
Build cost allocation into the resource organization
Cost analysis becomes more meaningful when resources have reliable owners, workload labels and environments. Tags can help assign charges within a subscription, but they do not create financial isolation and may not automatically propagate to every dependent resource or historical billing record. Define which tags are required, how they are applied and who reviews untagged or incorrectly tagged services.
A useful cost investigation starts with a time window and a comparison. Did one environment increase its storage redundancy, leave test VMs running or begin exporting more logs? Group spending by the appropriate subscription, resource group, service and tag where available. Use billing data to understand the change, then trace it to actual technical configuration. A single large total does not tell an administrator which intervention is justified.
Do not confuse cost estimates with observed invoices. Pricing varies by region, tier, contract, data transfer and consumption pattern. When documenting a cost-saving proposal, state the assumptions and expected operational tradeoffs. Turning off an apparently idle resource may save money but interrupt a standby application that is deliberately quiet until an emergency.
Budgets inform decisions; they are not automatic kill switches
Microsoft Cost Management budgets track actual or forecast spending against a defined amount and period. Administrators can configure notification thresholds and recipients at supported scopes. The key caveat is that crossing a budget threshold does not itself stop resource consumption or shut down running services. Treating a budget as a hard spending cap is both a technical misunderstanding and a potential business risk.
A production team might define an alert at a conservative point in its monthly budget, a higher warning for forecast overrun and an escalation path for persistent anomalies. The useful response is investigation: identify the responsible service, confirm whether growth is legitimate and decide whether resizing, scheduling or architectural changes are appropriate. Automated remediation, where separately designed, requires its own authorization and safeguards.
Budget data does not update in real time. Microsoft documents latency in cost availability and evaluation, so an alert should not be interpreted as an instantaneous circuit breaker. Maintain complementary platform metrics for sudden request storms, runaway log ingestion or storage growth. Operational telemetry can reveal a problem before the next cost report is available.
Advisor recommendations need context, not blind acceptance
Azure Advisor analyzes resource configuration and usage to surface recommendations involving cost, reliability, performance, operational excellence and security. Recommendations can be valuable evidence, but they are not a substitute for workload ownership. A recommendation to resize a VM should be compared with seasonal peaks, memory pressure, reserved capacity and availability obligations before any change is approved.
A right-sizing report based on average utilization can miss a month-end batch peak. Conversely, an oversized development instance running continuously may be a clear savings opportunity if nobody depends on its current capacity. The administrator should record the measured signal, the operational risk, the proposed change and the expected verification test.
The same reasoning applies to performance and reliability. A service may need an additional zone or better backup coverage even if that costs more. VM availability and scale sets address availability during infrastructure failures. Backup and Site Recovery covers separate recovery and restoration requirements; cost-cutting alone cannot choose between them.
Resource locks and compliance should support ownership
Deletion locks can protect critical resources from accidental management-plane deletion, while read-only locks can block certain changes. They do not create an archive backup or prevent every possible data-plane operation. Before applying a lock, decide how legitimate automation will deploy, update and restore the protected service. A protection that blocks every normal maintenance workflow is likely to be bypassed under pressure.
Azure Policy governs acceptable resource configurations, while budget alerts track cost trends. A compliant deployment can still be expensive; the operational response must distinguish these two signals.
Exemptions need accountable owners and review dates. If a project requires a temporary deviation from a location or network policy, record the reason and the supported exemption path instead of weakening the assignment for an entire management group. An exception left in place after the project ends can quietly normalize a security weakness.
Review compliance and costs together without treating them as one score. A resource can be cheap but noncompliant, secure but wasteful, or operationally resilient at a justifiable premium. The governance model should make each tradeoff explicit and connect findings to the team that can act.
Observe the effect of governance changes
After changing a budget or policy, verify scope, notifications, compliance evaluation and affected resources. A deployment should still be possible for a permitted configuration while deliberately disallowed settings fail. Budget test notifications should go to the expected group; recipients who never receive warnings defeat the purpose of the threshold.
Azure Monitor and Network Watcher cover the operational signals needed after configuration changes. Cost reports, Activity Logs and compliance assessments answer different questions; use the relevant evidence rather than assuming one dashboard proves everything. Keep versioned records of policy assignments and budget configuration so an unexpected change can be compared with a known baseline.
For AZ-104, an effective scenario exercise creates a resource-group budget, traces an inherited policy, examines a role assignment and models a resource move. Explain what each tool can and cannot enforce. The administrator’s job is to maintain accountable service boundaries while retaining enough flexibility to operate a live environment.
Use budgets and policies as decision tools
A useful exercise is to compare two incidents that look similar on a dashboard. In the first, a developer launches expensive resources outside the approved region. Policy can deny that deployment when the organization has defined and assigned the relevant rule. In the second, legitimate storage growth pushes a production subscription over its budget. Cost Management can notify the owner, but automatically disabling production storage would be a separate, potentially dangerous action. Each problem calls for a different control and approval process.
Build evidence into the review: the affected scope, exact policy effect, current cost estimate, operational importance and proposed change. An inherited assignment may explain a deployment denial while an underestimated replication cost explains a budget alert. Avoid fixing a governance issue by broadening privileges without diagnosing the condition. A well-run Azure estate uses consistent hierarchy and cost visibility to make responsibility clear, not to suppress every expensive or unusual operation.