A subscription can appear well organized while containing resources that are impossible to manage consistently. One team deploys workloads without owners, another creates public IP addresses in an unexpected region, and finance discovers a cost spike only after the monthly bill closes. The Microsoft AZ-104 exam tests the controls that make this problem manageable: resource groups and management scopes, Azure Policy assignments, tagging, locks, budgets and alerts.
These tools are different. Azure Policy evaluates resource configuration. Tags label resources for ownership, cost allocation or automation. Locks restrict certain management operations. Cost Management tracks usage and sends budget alerts. An administrator who applies the wrong tool can create a convincing dashboard without changing the underlying behavior.
Start with an explicit scope model
Management groups organize subscriptions for governance, while resource groups organize Azure resources that share management operations and lifecycle. A policy assigned at a management-group scope can apply to descendant subscriptions, subject to exclusions and the rule’s design. A resource-group-level assignment controls a narrower set of resources. The first question is therefore not which policy to select, but which resources the control must reach.
Sketch the hierarchy for an enterprise with production and development subscriptions. A production-only location restriction belongs at a scope where it cannot accidentally prevent an approved disaster-recovery deployment in another environment. Check inherited assignments and exemptions before creating a duplicate rule. The same structure helps interpret inherited Azure RBAC permissions; neither grouping mechanism is simply a folder for prettier portal navigation.
A governance rollout may involve a management group containing two production subscriptions and a sandbox subscription. Suppose the organization prohibits public IP addresses in production but permits them in a controlled sandbox. Put the restriction at a scope that expresses that real difference rather than applying a global deny and creating dozens of exemptions. Map policy assignments, initiatives and exclusions before creating them. An operator troubleshooting a deployment needs to know the exact assignment ID and inherited scope; the fact that a user has Contributor rights does not explain whether the resource request complies with central rules.
Understand audit, deny, modify and remediation
Azure Policy definitions evaluate conditions and use effects such as audit, deny, modify and deployIfNotExists. An audit policy reports a configuration issue without preventing deployment. A deny policy can stop a nonconforming create or update operation. Modify and deployIfNotExists effects involve additional mechanisms and often require a managed identity with appropriate permissions to remediate changes. Selecting a stronger-looking effect is not inherently better.
For a new regional deployment rule, begin by measuring what already exists. If a deny assignment would unexpectedly block necessary workloads, address those exceptions before enforcement. When remedial behavior is appropriate, verify permissions, remediation tasks and what happens to existing resources. Understand the difference between evaluating compliance, preventing a future operation and bringing an already deployed resource into compliance.
Treat a failed policy remediation as a separate problem from a noncompliant resource. A policy with an audit effect can report noncompliance without preventing deployment; deny blocks matching requests, while modify and deployIfNotExists commonly rely on a managed identity and its own permissions for remediation. Inspect the policy effect, parameters, existence conditions, remediation identity and role assignments. If a tag is missing, running a remediation task before confirming permissions can give the impression that policy is broken. Test the same definition against a disposable resource and observe the compliance event, successful change, and any unsupported resource types.
Use tags as accountable business metadata
Tags can represent owner, environment, cost center and data classification, but Azure does not automatically inherit every tag from a resource group to resources. A policy may add or inherit tags in supported situations; those effects need to be configured and checked. Avoid assuming a resource is financially attributable just because the group above it has a cost-center tag.
Build a small vocabulary with named owners and accepted values, not dozens of variations on `Production`, `Prod` and `production`. Define who corrects missing tags after mergers or reorganizations. Some costs are difficult to allocate solely by tags, and not every billing line behaves like a neatly tagged resource. Use cost allocation reports as a control signal, not as unquestionable proof of an individual team’s spending.
For a production cost-allocation tag, the hard question is the authoritative value, not the field name. A policy that automatically adds costCenter=unknown might appear to achieve full tag coverage while making finance reporting useless. Define allowed values and a workflow for ownership changes. Then verify how inherited tags are handled for resources that support them; tags placed on a resource group are not automatically inherited by every child resource without an explicit process. An audit should compare the Azure inventory with a business-system source of truth and count stale, not only blank, ownership values.
Treat resource locks as safety rails, not authorization
A CanNotDelete lock protects against certain management-plane delete actions; ReadOnly is stricter and can interfere with operations that need writes. Locks apply through their scope and can affect actions made by a legitimate administrator or automation. They are not a substitute for restricting access with RBAC, and they do not make application data immune to all data-plane deletes.
An engineer may put a ReadOnly lock on a resource group and inadvertently disrupt an application or infrastructure update that must change configuration. Before applying locks, identify normal maintenance, emergency recovery and break-glass procedures. Test the lock with a disposable resource and document removal authority. Treat locking production resources as a change that needs a rollback plan, not as a harmless security checkbox.
Budget alerts measure spending, not enforce a hard cap
Azure Cost Management budgets can send notifications at configured thresholds, but reaching a budget is not the same as automatically stopping every billable resource. Actual spending and forecast figures answer different questions. If finance needs stronger guardrails, pair budget monitoring with appropriate service quotas, policy restrictions, usage reviews and approval processes. None is a universal guaranteed cost cutoff.
For example, a laboratory subscription spends faster than expected when test VMs are left running overnight. A budget alert can help a responsible owner investigate, but a schedule to stop nonproduction VMs and a process for deleting unused resources act directly on consumption. Check the operational exceptions: suspending a database during an active migration can cost more than leaving it running.
An Azure Cost Management budget monitors spending and forecasts against configured limits; it is not a spending safety switch. If a disposable lab subscription exceeds a threshold, a budget alert by itself will not prevent the next VM from being created. Use an action group or governed automation if the organization wants an action, and explicitly document the risks of automation that deallocates resources. Production workloads need a different review process because shutting down a database to save a modest amount may cause far greater business damage. Budget controls therefore require an owner, response route, tolerance, and evidence that notifications arrive.
Read Azure Advisor recommendations with context
Azure Advisor can identify opportunities concerning cost, reliability, security, performance and operational excellence. Recommendations are starting points for review, not automatic instructions. Downsizing a VM because observed CPU utilization is low may be unsuitable when memory pressure, disk throughput or a predictable monthly peak drives the real capacity requirement.
A disciplined review records the recommendation, supporting metrics, responsible owner, expected savings or risk reduction, and post-change results. Avoid citing theoretical savings as realized benefits until the change has been applied and the bill reflects it. The administrator’s job is to turn a suggestion into a controlled operational decision with measurable evidence.
Investigate a governance failure from symptom to scope
Imagine a developer receives a deployment-denied message while creating a storage account. Before requesting Owner at the subscription level, inspect the policy compliance result, assigned definition, parameters and assignment scope. Check whether a higher-level initiative imposes an allowed-region or required-security-setting restriction. An exemption is a governed exception, not a generic bypass to quiet an error.
Now imagine a resource is compliant but missing a financial owner. Determine whether the chosen tag rule evaluates deployed resources, modifies new deployments or supports remediation for existing resources. If its managed identity cannot perform the required write, the remediation task will not repair the tags. Collect the assignment and operation IDs so the next administrator can reproduce the decision.
When a Bicep deployment says ‘RequestDisallowedByPolicy,’ capture the policy assignment and definition ID from the failure details. Determine which resource property violated the rule, whether the request came from the expected subscription, and whether an exemption exists with the right scope. Do not grant Owner to the pipeline as a first response. If the error is AuthorizationFailed, inspect RBAC separately; if the issue is ReadOnly lock behavior, inspect inherited locks. These failures share the symptom ‘deployment failed’ but call for different corrections and different approvers.
Build one AZ-104 governance exercise end to end
Create a test resource group, apply a location-tag audit policy, inspect compliance, then test a safe deny policy with a disposable deployment. Assign a tag that describes the owner, configure a budget alert at a deliberately low laboratory threshold and create a lock after understanding what will be blocked. Observe a rejected update and cleanly undo the lab-specific controls.
Document which mechanism answered which requirement. The exercise should distinguish subscription access, policy compliance, tagging consistency, management locks, forecast spending and real charges. That distinction matters more on a scenario-based AZ-104 task than memorizing the menu containing each feature.
In a safe lab, create a resource group with a valid owner tag and deploy a storage account through Bicep. Add an audit policy that reports a missing tag, then replace it with a narrowly scoped deny policy and confirm the intentionally noncompliant deployment is blocked. Correct the tag and rerun the deployment. Add a budget threshold and verify the alert recipient, but avoid intentionally running up costs. Finally test deletion with and without a CanNotDelete lock. Record which mechanism changed compliance, which blocked deployment, which blocked deletion and which merely warned about spending.