AZ-305 Cost Governance Decision Guide: Policy, Budgets, Tags, or Advisor?

For AZ-305 cost-governance scenarios, start with the control objective. Use management groups for inherited governance across many subscriptions. Use subscriptions and resource groups for ownership, lifecycle, quota, or cost accountability. Use tags and Cost Management tag inheritance for cost allocation. Use Azure Policy to audit, deny, or remediate resource configuration. Use budgets and cost alerts for spend awareness and escalation. Use Azure Advisor, reservations, and savings plans after usage exists and the question asks how to optimize spend.

This is exam-relevant because Microsoft's current AZ-305 study guide lists governance under Design identity, governance, and monitoring solutions, including management groups, subscriptions, resource groups, tagging, compliance, and identity governance. The English exam page says the exam was updated on April 17, 2026 and lists this skill area at 25-30% (AZ-305 study guide, AZ-305 exam page).

Compact decision shortcut

• Need one policy or access model across many subscriptions: management group.
• Need workload, environment, or billing isolation: subscription.
• Need deployment lifecycle ownership: resource group.
• Need showback, chargeback, owner, app, or environment reporting: tags and Cost Management.
• Need missing tags, approved regions, allowed SKUs, diagnostics, or compliance guardrails: Azure Policy.
• Need notification when spend crosses actual or forecast thresholds: budgets and cost alerts.
• Need a first-pass optimization review after resources are running: Azure Advisor cost recommendations.
• Need rate optimization for stable usage: reservations or savings plans, after validating commitment risk.

Decision-flow diagram

The diagram is intentionally small. It is a decision lens for answer choices, not a full enterprise landing-zone architecture.

What AZ-305 is really testing

The trap is treating governance as one product. AZ-305 usually asks for the boundary that matches a business requirement: who owns spend, where policy should apply, how compliance is measured, or how cost waste is surfaced.

Microsoft describes management groups as a governance scope above subscriptions where applied conditions cascade by inheritance to associated subscriptions. The same Microsoft page warns that root management group assignments apply across the tenant hierarchy, so root-scope assignments should be limited to must-have controls (Azure management groups).

Azure Policy is the enforcement layer, not a budgeting tool. Microsoft describes Azure Policy as a way to enforce organizational standards and assess compliance at scale. It can audit, deny, alter, deploy related resources, or remediate noncompliant resources depending on the policy effect (Azure Policy overview).

Cost Management is the visibility and optimization layer. Microsoft says tags add business context to cost details, tag inheritance copies subscription and resource group tags into cost data without saving those inherited tags on the resources, budgets can notify recipients when actual or forecast cost crosses a threshold, and Advisor should be a first stop for optimizing existing resources (Cost Management overview).

Decision cards

Management groups

Use management groups when the organization needs inherited governance across subscriptions: allowed regions, policy baselines, platform landing zones, subscription grouping, or centralized role assignments. Do not choose management groups only because you want cost reports. Microsoft notes that management groups can organize subscriptions for policy and access inheritance, and also notes a current Cost Management limitation for Microsoft Customer Agreement subscriptions (Azure management groups).

Exam clue: "all production subscriptions must inherit this baseline."

Subscriptions and resource groups

Use subscriptions when the boundary is isolation, ownership, quota, environment separation, or billing accountability. Use resource groups when the boundary is deployment lifecycle, role assignment at a smaller scope, and resource ownership for one workload component. Both can also host budgets and cost analysis scopes (Create and manage budgets).

Exam clue: "separate dev/test/prod spending."

Tags and tag inheritance

Use tags when the design needs business context such as cost center, owner, application, environment, or data classification. Tags do not replace hierarchy; they make cost and operational views understandable across hierarchy boundaries.

Microsoft's Cost Management docs say tag inheritance can apply billing, subscription, and resource group tags to child usage records, depending on scope and agreement type, but the inherited tags are applied to usage records and not to the resources themselves (Tag inheritance).

Exam clue: "allocate shared cost by business unit or app owner."

Azure Policy

Use Azure Policy when a requirement says "must enforce," "deny," "audit," "remediate," "allowed locations," or "required tags." Microsoft lists cost and management as common Azure Policy use cases (Azure Policy overview).

For tag governance, Microsoft's tutorial uses deny and modify policies, then groups tag policies into an initiative and assigns the initiative to a management group or subscription. It also states that existing noncompliant resources require remediation tasks; policy assignment alone does not automatically fix every existing resource (Manage tag governance with Azure Policy).

Exam clue: "resources must not be created without CostCenter."

Budgets and cost alerts

Use budgets when the requirement is spend awareness, threshold notification, forecast warning, or escalation. Budgets do not stop consumption by default. Microsoft states that budget notifications are triggered when thresholds are exceeded, resources are not affected, and consumption is not stopped (Create and manage budgets).

Budgets can use actual or forecast thresholds, and subscription or resource group budgets can call action groups for escalation or automation (Create and manage budgets).

Exam clue: "notify owners at 80% and FinOps at 100%."

Azure Advisor, reservations, and savings plans

Use Azure Advisor when resources already exist and the goal is to identify waste. Microsoft says Advisor cost recommendations should be a first stop for optimizing existing resources, and the Advisor VM guidance explains that recommendations can include resizing or shutting down underutilized VMs and VM scale sets (Cost Management overview, Advisor cost recommendations).

Use reservations or savings plans only when the scenario has stable usage and the organization accepts commitment tradeoffs. Microsoft describes Azure Reservations as one-year or three-year commitments that can lower eligible resource costs compared with pay-as-you-go. Savings plans include one-year or three-year compute commitments and a one-year database commitment (Azure Reservations, Azure savings plans).

Exam clue: "steady VM usage for three years" can support reservations.

Worked example: clean up a growing tenant

Scenario:

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.

Step 1: choose the inherited scope.

Create a management group hierarchy for platform, production, nonproduction, and sandbox. Apply only baseline controls at broad scopes. Avoid putting experimental rules at the tenant root because root assignments affect the whole hierarchy.

Step 2: define the accountability boundary.

Use subscriptions for environment and workload accountability, then resource groups for lifecycle ownership. Finance reporting should not depend on names alone because shared services and cross-cutting costs will break naming-only reports.

Step 3: make cost visible.

Standardize tags such as CostCenter, App, Environment, and Owner. Use Azure Policy to require or modify tags where supported. Enable Cost Management tag inheritance if the billing scope and permissions support it, then build Cost Analysis views around tags.

Step 4: add guardrails.

Use Azure Policy initiatives at the right management group or subscription scope. For nonproduction, deny expensive VM SKU families unless an exception process exists. For production, start with audit when the blast radius is unclear, then move to deny or modify after impact is understood.

Step 5: add spend alerts.

Create budgets at sandbox subscription and high-variance resource group scopes. Use actual and forecast thresholds to notify owners before spending becomes a month-end surprise. If automation is attached through an action group, keep it conservative for production.

Step 6: optimize what is already running.

Review Advisor cost recommendations for idle or underutilized VMs. Validate each recommendation against seasonality, reservations, savings plans, and disaster recovery requirements before resizing or shutting down anything.

Exam-ready answer:

Use management groups for inherited policy scope, subscriptions and resource groups for accountability boundaries, tags for cost allocation, Azure Policy for required tag and SKU guardrails, budgets for spend escalation, and Advisor plus commitments for post-deployment optimization.

Diagnostic walkthrough: what your wrong answer reveals

If you choose budgets to stop resource creation, you are confusing notification with enforcement. Budgets inform and escalate; Policy blocks or remediates.

If you choose tags without Policy for a mandatory tagging requirement, you are missing enforcement. Tags provide metadata; Policy audits or enforces.

If you choose Policy for monthly spend notification, you are applying a guardrail to an alerting problem. Use budgets.

If you choose management groups for cost allocation alone, you are over-weighting hierarchy. Management groups carry inherited governance; tags and Cost Management carry cost allocation.

If you choose reservations before proving stable usage, you are optimizing rate before validating demand. Use Advisor and Cost Analysis first.

How to study this topic without memorizing product names

Practice by writing the objective before the Azure service: visibility, scope, enforcement, notification, or optimization. Then map that objective to the smallest durable control. That habit is closer to AZ-305 than memorizing every portal blade.

Where CramHQ fits

CramHQ is not a Microsoft product and does not guarantee a pass. For this topic, CramHQ can help turn a missed governance question into a targeted learning loop: identify whether the miss came from scope selection, tagging, policy effects, budget behavior, or optimization timing, then use focused remediation, lessons, targeted practice, and readiness planning instead of rereading every governance page.

When you are ready, take the AZ-305 assessment. After each missed cost-governance question, write one sentence: "I chose the wrong control because I missed ____." Fix that decision boundary, then retest with a few related scenarios.

Quick recap

• Management groups are for inherited governance across subscriptions.
• Subscriptions and resource groups are accountability and lifecycle boundaries.
• Tags add business context to cost and operational data.
• Azure Policy audits, denies, modifies, deploys, or remediates configuration drift.
• Budgets and cost alerts notify; they do not stop consumption by default.
• Advisor, reservations, and savings plans fit optimization after usage evidence exists.
• AZ-305 cost-governance questions are usually asking for the right control objective, not the flashiest service.