Forty Subscriptions and Four Governance Symptoms

Structure: put the 40 subscriptions under a management group hierarchy - a root, one management group per department, and (optionally) dev/test and production management groups beneath. Azure Policy assignments and RBAC assignments inherit downward, so one assignment at the top covers every subscription added later, including ones that do not exist yet. This is why the hierarchy, not a per-subscription checklist, is the answer for a team of three.

Mechanism: an Azure Policy with allowedLocations and effect Deny, assigned at the department or root management group. Policy evaluates the properties of a resource request, so non-compliant deployments fail at deploy time - no ticket, no reviewer.

Two things you must say out loud:

• Deny is not retroactive. The existing 11% stays. Run the same policy in Audit first to size the problem, then create a remediation task or clean up manually, then switch to Deny.
• Policy is not RBAC. RBAC says who may act; Policy says what the result may look like. Neither substitutes for the other, and both are needed. Avoid the common wrong answer of 'deny the region in RBAC' - RBAC roles are not resource-property filters.

Partly. A CanNotDelete lock on the storage account or its resource group blocks the delete operation at the control plane. A ReadOnly lock would go further and block updates as well.

But it would not have saved the data on its own, for three reasons:

1. Locks are removable by whoever has permission to manage them. A contractor with the Owner role can simply delete the lock and then the resource. A lock is a guardrail against accident, not a defense against a privileged actor. The real defect here is the Owner role granted at subscription scope to a contractor.
2. Locks apply to the control plane, not the data plane. A CanNotDelete lock on the account does not stop someone deleting blobs inside it. For that you need blob soft delete, versioning, or Backup.
3. Locks do not survive someone deleting the whole resource group containing a locked resource - the operation is blocked while the lock exists, but again, a privileged user can remove it.

Correct layered answer: least-privilege RBAC (no standing Owner for contractors), Privileged Identity Management for just-in-time elevation, CanNotDelete locks on production resource groups, and soft delete plus backup for the data itself.

Attribution. Tags are only useful if their presence is guaranteed, so:

• Assign a Policy requiring costCenter on resources, using Deny for missing tags or Modify / append to inherit the tag from the resource group so users cannot forget it. Tag inheritance matters because untagged children otherwise break reports.
• Then use Microsoft Cost Management to group by tag and expose per-department views. Without the policy, the reports stay unreliable.

The hard budget request - this is the trap. A budget in Cost Management is a monitoring object: it tracks spend and fires alerts at thresholds. It does not stop or disable resources. There is no native 'switch off at $50,000' toggle, and anyone who says otherwise has not deployed one.

A real cutoff is an automation chain the team must build and own: budget → alert → action group → runbook or Logic App that stops or resizes resources. That carries its own risk - an automated shutdown of production is an outage with a schedule. The defensible answer is alerts plus a documented, tested response, and cost reduction upstream (reservations or savings plans for steady baselines, right-sizing, and deleting the idle resources the tags finally make visible).