# Azure Cost Budget and Quota Operations

Use this reference for current, source-grounded service behavior and the hard live-operation gates that the lean `SKILL.md` intentionally does not carry.

## What people get wrong

- Assuming a budget alert stops Azure spend.
- Approving GPU/HPC quota because current spend is low, while ignoring delayed cost data.
- Creating action groups with no owner or runbook.
- Raising budget thresholds without financial authority and expiry.
- Using quota increase as capacity planning rather than explicit spend-risk acceptance.

## Officially grounded service shape

Microsoft Learn evidence says Cost Management budgets monitor spending and trigger notifications or action groups, but budget alerts do not stop resources or consumption. Cost and usage data is typically delayed, and budgets are evaluated on a schedule. Budgeting guidance recommends alerts, anomaly detection, stakeholder ownership, and automation only with clear accountable response paths.

- Budgets can be scoped and filtered, and can alert on actual or forecast cost.
- Budget alerts notify stakeholders and can integrate action groups at supported scopes.
- Cost data is not real time; budget evaluations lag consumption.
- Quota controls capacity but is not a budget by itself.
- Emergency spend-stop actions can be disruptive and need owner approval and rollback criteria.

## Non-negotiable design rules

- Confirm billing/subscription/resource-group scope and financial owner before changes.
- State that budgets do not stop consumption unless paired with separate approved automation.
- Review actual, forecast, data freshness, threshold, recipients, action groups, and anomaly coverage.
- Treat GPU/HPC quota and high-cost scale-up as high-risk financial mutations.
- Prefer lower-risk alerts and temporary quotas before permanent threshold increases.

## Minimal safe implementation flow

- Scope cost owner, subscription/resource group, workload, SKU, quota, and budget action.
- Collect current budget definitions, alert thresholds, action groups, current/forecast costs, data freshness, and quota state.
- Classify proposed change as alert-only, automation, quota increase, deallocation, or spend-stop.
- Gate mutation on explicit financial approval and rollback/restore plan.
- Verify alert/action configuration and document residual spend risk.

## High-risk assumptions to kill

- A budget alert is not a spending stop. Microsoft Learn states resources are not affected and consumption is not stopped when thresholds are exceeded.
- Cost evidence is delayed; budget decisions based on current totals can be wrong because cost and usage data is typically available hours later and evaluated on a schedule.
- Action groups can trigger automation, but automation without an owner, runbook, and rollback path is an outage mechanism, not FinOps control.
- Quota increases authorize capacity to spend faster; they are financial-risk approvals even when no resource is created immediately.
- Forecast alerts are predictions, not guarantees; they must be labeled separately from actual-cost evidence.

## Safe command/code verification targets

- Verify budget scope, filters, reset period, amount, expiration, actual thresholds, forecast thresholds, recipients, and action groups.
- Confirm cost-data freshness and label actual versus forecast evidence in the final verdict.
- Inspect action-group receivers and automation targets without exposing secrets or customer data.
- Require business owner, duration, and spend ceiling for high-cost quota or budget-threshold increases.
- Verify post-change budget/action configuration and document that residual consumption can continue after alerting.

## Safe verification targets

- Budget thresholds and recipients match accountable stakeholders.
- Action group behavior and automation runbooks are tested and reversible where possible.
- Cost data freshness and forecast uncertainty are explicitly stated.
- Quota increase request has business justification, expiry/review, and spend ceiling.
- Emergency deallocation or quota reduction has owner approval and service-impact assessment.

## When to push back

- The user treats budget alerting as a hard spending stop.
- Financial approval is missing or vague.
- High-cost quota request lacks workload, duration, and maximum-spend boundary.
- Automation could deallocate production without an incident commander and rollback plan.

# Documentation and Evidence Path

## Preferred evidence order

1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
2. Sampled read-only Azure evidence, when safely available, for current configured-environment observations.
3. Sanitized user-provided evidence.
4. Clearly labeled inference.

## What each evidence type can prove

- Microsoft Learn documentation can prove documented service behavior, supported concepts, limitations, and recommended patterns.
- Sampled read-only evidence can prove the sampled configured state at the time observed.
- Sanitized user evidence can prove only what the snippet shows.
- None of these alone prove broad regional availability, future success, full account posture, or production readiness.

## Safe usage pattern

- State whether each claim is documentation-based, sampled-current-state, user-provided, or inference.
- Use read-only queries before recommending changes.
- Do not include sensitive internal identifiers, tenant identifiers, subscription identifiers, or secrets in committed docs or final findings.
- If no sampled evidence is available, say the review is documentation-based and list the exact evidence still needed.

## Live-operation rule

For live operations, documentation is never enough. Require target confirmation, current-state evidence, explicit approval, rollback constraints, and post-action verification.

# Official Sources

Use these sources to ground the skill. Microsoft Learn documentation proves documented Azure behavior; it does not prove the user's tenant, subscription, RBAC, quota, deployed resources, current cost, vault state, app health, or production readiness.

## Primary Microsoft Learn sources

- https://learn.microsoft.com/azure/cost-management-billing/costs/tutorial-acm-create-budgets
- https://learn.microsoft.com/azure/cost-management-billing/costs/cost-mgt-alerts-monitor-usage-spending
- https://learn.microsoft.com/azure/cost-management-billing/costs/cost-mgt-best-practices
- https://learn.microsoft.com/cloud-computing/finops/framework/quantify/budgeting
- https://learn.microsoft.com/azure/quotas/quickstart-increase-quota-portal
- https://learn.microsoft.com/azure/azure-resource-manager/management/azure-subscription-service-limits

## Grounding notes

- Documentation-based claim: Microsoft Learn evidence says Cost Management budgets monitor spending and trigger notifications or action groups, but budget alerts do not stop resources or consumption. Cost and usage data is typically delayed, and budgets are evaluated on a schedule. Budgeting guidance recommends alerts, anomaly detection, stakeholder ownership, and automation only with clear accountable response paths.
- Current-state claim: requires sampled read-only Azure evidence or sanitized user-provided evidence.
- Live-operation claim: requires target, principal, approval, preflight evidence, rollback constraints, and post-action verification.
- Inference: allowed only when labeled and tied to observed fields or documented behavior.
- Do not include sensitive internal identifiers or secret material in findings.

## Source use rules

- Prefer Microsoft Learn documentation through the user's configured documentation MCP for current Azure service behavior.
- Use sampled read-only Azure evidence only to validate current configured-environment observations.
- If documentation and sampled evidence appear to conflict, report both and stop short of a production-ready verdict.
- Re-check official sources before changing high-risk guidance, because cloud behavior and feature availability can change.

# Permission Model: Azure Live Cost Budget Action Guard

## Custom role — budget read/write, quota read, no VM creation

```json
{
  "Name": "Cost Budget Action Guard",
  "IsCustom": true,
  "Description": "Read and modify subscription budgets and read compute quotas. Cannot create VMs. Cannot delete budgets.",
  "Actions": [
    "Microsoft.Consumption/budgets/read",
    "Microsoft.Consumption/budgets/write",
    "Microsoft.CostManagement/budgets/read",
    "Microsoft.CostManagement/budgets/write",
    "Microsoft.CostManagement/query/action",
    "Microsoft.Compute/locations/usages/read",
    "Microsoft.Compute/locations/vmSizes/read",
    "Microsoft.Quota/quotas/read",
    "Microsoft.Quota/usages/read"
  ],
  "NotActions": [
    "Microsoft.Compute/virtualMachines/write",
    "Microsoft.Compute/virtualMachineScaleSets/write",
    "Microsoft.Quota/quotas/write",
    "Microsoft.Consumption/budgets/delete",
    "Microsoft.CostManagement/budgets/delete"
  ],
  "AssignableScopes": [
    "$APPROVED_AZURE_SCOPE"
  ]
}
```

`Microsoft.Quota/quotas/write` is excluded: quota increase requests carry spending risk
and must go through a separate approval workflow, not this role. VM creation is
explicitly excluded to prevent the cost guard from becoming a provisioning path.

`Microsoft.Consumption/budgets/delete` and `Microsoft.CostManagement/budgets/delete`
are excluded: deleting a budget silently removes the only cross-region financial
guardrail and disables every threshold alert on the subscription. Cleanup of stale or
test budgets must go through a separate PIM-eligible role with MFA + justification gates.

## Azure Policy guardrail (deploy alongside the role)

Deny GPU VM SKU provisioning without an approved budget tag:

```json
{
  "if": {
    "allOf": [
      {"field": "type", "equals": "Microsoft.Compute/virtualMachines"},
      {"field": "Microsoft.Compute/virtualMachines/sku.name", "in": [
        "Standard_ND96asr_v4", "Standard_NC24rs_v3", "Standard_ND40rs_v2"
      ]},
      {"field": "tags.BudgetApproval", "exists": "false"}
    ]
  },
  "then": {"effect": "Deny"}
}
```

## Do not assign

- `Cost Management Contributor` at management-group scope
- `Billing Account Contributor`
- `Microsoft.Compute/virtualMachines/write` to this role

Use exact resource scopes from approved change records; do not paste raw subscription identifiers into chat.

# Preflight Commands: Azure Live Cost Budget Action Guard

Run these before any budget modification. Paste sanitized output as evidence.

## 1. Confirm identity and subscription

```bash
az account show --query "{subscription:id, name:name, user:user.name}"
```

## 2. List current budgets

```bash
az consumption budget list --query \
  "[].{name:name, amount:properties.amount, timeGrain:properties.timeGrain, currentSpend:properties.currentSpend.amount}"
```

## 3. Inspect a specific budget detail

```bash
az consumption budget show -n <BUDGET_NAME> \
  --query "{amount:properties.amount, filter:properties.filter, notifications:properties.notifications}"
```

## 4. Check current spend vs. budget

```bash
az costmanagement query \
  --type ActualCost \
  --dataset-aggregation '{"totalCost":{"name":"PreTaxCost","function":"Sum"}}' \
  --timeframe MonthToDate \
  --scope "$APPROVED_AZURE_SCOPE"
```

## 5. Check compute quota usage before action

```bash
az vm list-usage -l <LOCATION> \
  --query "[?contains(name.value,'cores') || contains(name.value,'GPU')].{name:name.localizedValue, current:currentValue, limit:limit}"
```

## 6. Verify budget action groups are configured

```bash
az consumption budget show -n <BUDGET_NAME> \
  --query "properties.notifications"
# All notification.actionGroups should point to valid Action Group resource IDs
```

# Rollback Playbook: Azure Live Cost Budget Action Guard

## Evidence-variable convention

Shell variables in examples are local operator placeholders from an approved change record or already configured shell context. Do not commit real values, and redact them from shared evidence unless disclosure is explicitly approved.

## Budget update rollback

```bash
# Inspect current state before revert
az consumption budget show -n <BUDGET_NAME>

# Re-apply the original budget values without deleting the budget when possible
az consumption budget create \
  -n <BUDGET_NAME> \
  --amount <ORIGINAL_AMOUNT> \
  --time-grain <Monthly|Quarterly|Annually> \
  --start-date <YYYY-MM-01> \
  --end-date <YYYY-MM-01> \
  --notification $ORIGINAL_NOTIFICATION_FIELDS_JSON
```

## Remove a runaway action group from a budget

```bash
# Show notification rules
az consumption budget show -n <BUDGET_NAME> --query "properties.notifications"

# Update budget to clear action groups on a specific notification key
az consumption budget create -n <BUDGET_NAME> \
  --amount <AMOUNT> \
  --time-grain Monthly \
  --start-date <DATE> \
  --end-date <DATE>
# Re-specify only the notification rules you want to keep
```

## Rollback limitations

- Spend that already occurred before the budget alert triggered cannot be reversed.
- Deleting a budget does NOT stop any VMs or resources — it only removes the alerting rule.
- Quota increases, once approved by Microsoft, cannot be reduced below the original limit.


## Cost-data latency caveat

Microsoft Learn documents that cost and usage data is typically available within 8-24 hours and budget evaluation runs every 24 hours. A rollback or threshold reduction does not undo spend that already occurred and might not immediately reflect current consumption.

# Safety Checklist

## Evidence labels

- `documentation-based`: grounded in Microsoft Learn or listed official documentation.
- `sampled-current-state`: grounded in read-only Azure or Kubernetes observations from the user's configured tools.
- `user-provided`: grounded in sanitized snippets supplied by the user.
- `inference`: reasoned from evidence but not directly proven.

## Mutation boundary

- Default to read-only review.
- Do not perform create, update, delete, rotate, purge, recover, apply, swap, reset, complete, deploy, assign, revoke, deallocate, quota, budget, or policy changes unless the user explicitly asks and approval is clear.
- Prefer preview, what-if, dry-run, status, describe, list, show, diff, activity-log, and policy evaluation evidence before any mutation.

## Credential and data boundary

- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, kubeconfig contents, CA requester credentials, secret values, connection strings, or raw environment dumps.
- Summarize sensitive evidence by field presence, control state, and risk; do not reproduce secret material.

## Risk gates

- Stop on ambiguous target, ambiguous principal, missing approval, missing rollback, missing financial owner, or missing asset owner for high-impact assets.
- Treat broad permissions, permanent privileged access, public exposure, purge authority, destructive deployment behavior, quota increases, budget automation, and production slot swaps as high-risk.
- Separate documented product behavior from sampled configured-environment evidence.

## Asset-specific hard line

Never approve quota increases, budget threshold raises, automated cost actions, or high-cost SKU provisioning without explicit financial owner approval, cost data latency caveat, rollback or stop action, and scope confirmation.

# Workflow and Output Contract

## Execution flow

1. Scope the exact target, environment boundary, owner, requested operation, approval state, and rollback owner.
2. Load `official-sources.md`, then the component operations guide for service behavior and risk gates.
3. Gather sampled read-only evidence only when available and safe.
4. Compare observed posture against documented behavior, least-privilege expectations, and live-operation safety rules.
5. Refuse or defer mutation if target, approval, rollback, or evidence is incomplete.
6. Return a verdict with evidence level, blockers, safe next actions, and open questions.

## Required output

- `verdict`: pass, warn, fail, or blocked.
- `evidence_level`: documentation-based, sampled-current-state, user-provided, inference, or mixed.
- `scope`: what was reviewed and what was not reviewed.
- `approval_status`: explicit approval, missing approval, or not applicable for read-only review.
- `blockers`: issues that prevent a safe or production-ready conclusion.
- `findings`: severity-labeled risks with source labels.
- `rollback_posture`: exact rollback path or explicit non-reversibility caveat.
- `safe_next_actions`: reversible actions first; mutation only with explicit approval.
- `open_questions`: missing facts that would change the verdict.

## Stress checks

- What assumption would make this recommendation unsafe?
- Which role, policy, budget, quota, deployment, swap, or purge action has the largest blast radius?
- What evidence would disprove the claimed readiness?
- Is the answer accidentally treating documentation as environment-specific proof?

## Response discipline

Use Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior. Use sampled read-only Azure evidence only for current configured-environment observations and label it as sampled evidence.