You read an AZ-305 scenario where the requirement says no resource may be created without a CostCenter tag, and finance must be warned when sandbox spend crosses 80% of budget. Azure Policy and budgets both look like the answer. They do different jobs. Policy enforces the tag rule; budgets raise the spend alert. In cost-governance questions, the job named in the requirement picks the control.
The exam's governance skill is a job list
Microsoft's AZ-305 study guide (skills measured as of April 17, 2026) lists a design governance skill with three tasks: recommend a structure for management groups, subscriptions, and resource groups, and a strategy for resource tagging; recommend a solution for managing compliance; and recommend a solution for identity governance. The domain that carries it, design identity, governance, and monitoring solutions, is weighted 25-30% of the exam, per the exam page (updated April 17, 2026).
The scenario states the job before it states the tool. Inherit a baseline across subscriptions, hold an accountability boundary, split shared cost, enforce a rule, alert on spend, or cut waste. Read the requirement for the job, then map the job to the smallest control that owns it.
Six jobs, one control each
- Inherited governance across subscriptions. The requirement says all production subscriptions must inherit the same baseline. Map it to management groups.
- An accountability boundary. The requirement separates spending or isolation by environment, workload, or owner. Map it to subscriptions and resource groups.
- Cost allocation. The requirement wants shared cost split by business unit, app, or environment. Map it to tags, and to tag inheritance where the billing scope supports it.
- Enforcement. The requirement says resources must not be created without a required tag, must not leave approved regions, or must not use an SKU outside the list. Map it to Azure Policy.
- Spend alerting. The requirement wants a notification when spend crosses an actual or forecast threshold. Map it to budgets and cost alerts.
- Optimization after usage exists. The requirement mentions idle or underutilized VMs, or steady usage that should cost less. Map it to Azure Advisor first, then to reservations or savings plans.
The controls and their limits
The six controls, the job each one owns, and the documented limit:
| Control | Job it owns | The limit |
|---|---|---|
| Management groups | Inherited governance. A governance scope above subscriptions; the conditions you apply cascade by inheritance to all associated subscriptions. | The root management group folds every subscription in the directory into one scope, so a root assignment reaches everything. Not currently supported in Cost Management features for Microsoft Customer Agreement (MCA) subscriptions. |
| Subscriptions and resource groups | Accountability. Isolation, ownership, quota, environment separation, deployment lifecycle. Budgets can be created at both scopes. | A policy, role, or budget scoped to one subscription does not reach the next. A management group is what binds subscriptions for shared governance. |
| Tags and tag inheritance | Cost allocation. Resource tags are the only way to add your own business context to cost details. | Inherited tags land on usage records, not on the resources, and only inside Cost Management. Azure Policy cannot read them. |
| Azure Policy | Enforcement. Effects include audit, deny, modify, and deployIfNotExists, and it remediates existing non-compliant resources. | Effects act when a resource is created or updated. A non-compliant resource that already exists needs a remediation task. |
| Budgets and cost alerts | Spend alerting. Actual or forecast thresholds, up to five per budget, with up to five email addresses. | Resources aren't affected, and your consumption isn't stopped. Action groups are only supported at subscription and resource group scopes. |
| Azure Advisor, reservations, and savings plans | Optimization. Advisor identifies low utilization and recommends resizing or shutting down VMs and VM scale sets, with the estimated savings for each action. Reservations and savings plans are 1- or 3-year commitments. | Advisor is available at subscription and resource group scope. A commitment does not change the runtime state of your resources, and a savings plan's unused hourly commitment expires. |
Where the rule bends
When tags and Policy both seem to fit
The verb decides. A requirement that resources must carry a CostCenter tag is an enforcement job, and the control is a Policy deny or modify effect. A requirement that finance can split spend by CostCenter is an allocation job, and the control is tags plus Cost Management. Both jobs can appear in the same scenario, and the scenario asks which control does the named one.
Tag inheritance fills the gap when resources do not carry their own tags. It copies billing, subscription, and resource group tags into child usage records within 24 hours of enabling, and it is available for Enterprise Agreement (EA), Microsoft Customer Agreement (MCA), and Microsoft Partner Agreement (MPA, with Azure plan subscriptions) billing. Inherited tags never reach the resource itself, and Policy cannot read them, so a mandatory tag still needs a Policy effect.
When the verb is notify, the control is a budget
Budget alerts fire when a threshold is crossed. The budgets doc is explicit about what a budget does not do: "Resources aren't affected, and your consumption isn't stopped." If the requirement says stop, block, or deny, a budget cannot do the job, and the control is a Policy deny effect. The other direction fails the same way. A Policy assignment for a monthly spend notification has no rule to enforce, because the requirement asks for an alert.
Budgets also have a timing limit. Cost and usage data is typically available within 8-24 hours, and budgets are evaluated against it every 24 hours. A budget alert is a lagging warning. Of the controls in this guide, only a Policy deny effect acts at the moment of the request.
The root scope reaches everything
All subscriptions and management groups fold up into one root management group within the directory. Microsoft's docs describe the root as the scope for global policies and Azure role assignments at the directory level. So the root gets the must-have baseline controls, and the narrow or experimental rules stay at a lower scope where they apply.
The MCA case
The management groups doc notes that management groups are not currently supported in cost management features for MCA subscriptions. If the scenario says the tenant runs on MCA and the job is cost allocation across subscriptions, the hierarchy cannot carry it. The answer moves to tags and tag inheritance, which is available for MCA billing profiles, and to budgets at the billing scopes Cost Management supports for MCA tenants.
Commitments come after the usage evidence
The Cost Management overview says Advisor cost recommendations should be your first stop when optimizing existing resources. Advisor identifies low utilization and recommends resizing or shutting down, with the estimated savings shown for each action. Treat that output as the evidence step. Reservations lock a discount to a specific resource, size, and region, and the docs say reservations work best when usage is stable and predictable. Savings plans are a fixed dollar-per-hour commitment across eligible services, and the docs call them ideal for changing or dynamic workloads. Both come in 1- or 3-year terms, and neither changes the runtime state of your resources. A savings plan's unused hourly commitment expires and does not roll over, so a commitment sized above real usage is wasted.
A worked scenario on a growing tenant
A company has six Azure subscriptions: two production, two nonproduction, shared connectivity, and sandbox. Finance cannot tell which app owns 30% of monthly spend. Developers sometimes deploy large VM SKUs in nonproduction. The platform team wants early warning when sandbox cost spikes, but it does not want production deployments blocked by a budget alert. Several VMs have been idle for months.
The scenario carries six jobs. Apply them in order:
- Inherited scope. A management group hierarchy for production, nonproduction, and sandbox. Baseline controls at the broad scopes, and the root gets only the global controls, because a root assignment reaches every subscription in the directory.
- Accountability. Subscriptions per environment and workload, resource groups for lifecycle ownership. Finance reporting should not depend on names alone, because shared services and cross-cutting costs break naming-only reports.
- Allocation. Standardize tags such as CostCenter, App, Environment, and Owner. Require the mandatory ones with a Policy effect, and turn on tag inheritance so child usage records pick up the subscription and resource group tags. Build the Cost Analysis reports around the tags.
- Guardrails. A Policy deny on expensive VM SKUs in nonproduction, with an exception process. In production, start at audit to see how the rule lands, then move to deny once the impact is understood.
- Alerts. Budgets at the sandbox subscription and the high-variance resource group scopes, with actual and forecast thresholds. The alerts fire and escalate; they do not block production deployments, which is what the requirement asks for.
- Optimize. Review the Advisor cost recommendations for the idle VMs, checking each against seasonality and disaster recovery before resizing or shutting anything down.
The exam-ready shape of the answer: management groups for the inherited scope, subscriptions and resource groups for accountability, tags for allocation, Policy for the tag and SKU guardrails, budgets for the spend alert, and Advisor before any commitment.
What your wrong answer reveals
Five wrong picks each cross one boundary. Check your last scenario against them.
- Budgets to stop resource creation. You confused notification with enforcement. Budgets inform and escalate; the deny effect blocks.
- Tags alone for a mandatory tagging requirement. You have metadata without enforcement. Tags add context to cost data; Policy audits or denies the missing tag.
- Azure Policy for a monthly spend notification. You applied a guardrail to an alerting problem. Policy enforces rules; the budget raises the alert at a threshold.
- Management groups for cost allocation alone. Hierarchy carries inherited governance. Allocation rides on tags and Cost Management, and on an MCA tenant the hierarchy does not carry cost management at all.
- Reservations before usage evidence. You optimized the rate before validating the demand. Advisor first. It names the idle and underutilized VMs, shows the estimated savings, and the commitment follows the evidence.
Your next step
Take the free AZ-305 assessment. It needs no credit card, and it returns your Readiness Report with your top gaps. After a missed cost-governance question, note the job the requirement named and the control you picked. The difference between the two is the boundary to drill, and retesting a few related scenarios tells you whether it held. The AZ-305 course is the paid path after the assessment, at US$34.99 for 12 months of access, with the first repair free. At its center is the Pass Plan, the list of repair tasks CramHQ ranks and orders for you. The free assessment is only the starting point; after that, the gaps it tracks come from your own work on the course over time. It puts the gap that costs the most exam points first, and each task drills the boundary a missed question exposed. Practice tests and the timed final simulation check readiness.