How do I make resources inherit a tag from the resource group?

Assign the built-in 'Inherit a tag from the resource group' policy, which uses the Modify effect to copy a tag's value from the resource group onto the resource. This is friendlier than a hard Deny for tags that are naturally set at the resource-group level, because deployments don't have to specify the tag themselves. Modify requires a managed identity on the assignment with permission to change the resource, and you run a remediation task to apply it to existing resources.

How do I tag existing untagged resources with Azure Policy?

Deny only affects new resources, so use a Modify policy (such as 'Inherit a tag from the resource group' or 'Add or replace a tag on resources') and run a remediation task. The remediation task walks the existing non-compliant resources and applies the tag. Because Modify changes resources, the assignment needs a managed identity with a role like Tag Contributor or Contributor at the scope.

Why enforce tags on Azure resources?

Tags are how you slice cost, ownership, and lifecycle in Azure. Without a consistent CostCenter or Owner tag, cost reports can't attribute spend to teams, orphaned resources have no owner to ask about, and automation that acts on Environment or Expiry tags can't find its targets. Enforcing a small set of required tags at creation keeps the whole estate legible for billing, accountability, and cleanup.

Field notes · Governance

Require tags with Azure Policy

Requiring tags on every resource with Azure Policy

Q: How do I require tags on Azure resources?

Assign the built-in Azure Policy 'Require a tag on resources', parameterized with the tag name you want to enforce. Its effect is Deny, so a resource created without that tag is blocked. Assign one instance of the policy per required tag (for example CostCenter, Owner, Environment) at a management group or subscription scope, and test in audit mode first if you have existing untagged resources.

By Captain O6 min read

An untagged estate is a cost report nobody can read and a pile of resources nobody will claim. Two built-in policies fix it — one that blocks untagged resources, one that fills the tag in for you.

New to cloud? CAMPUX is a free, build-first course. Start here →

Enforce tags with Azure Policy's built-ins: "Require a tag on resources" (Deny) blocks anything created without the tag, and "Inherit a tag from the resource group" (Modify) copies the value down from the RG so deployments don't have to set it. For resources that already exist, run a remediation task with the Modify policy — which needs a managed identity on the assignment. One policy per required tag, and your estate becomes legible for cost and ownership.

Tags are how you answer the questions that matter at scale: who owns this, which team pays for it, is this production, can we delete it? Without them, a cost report is a wall of resource names, orphaned resources have nobody to ask about, and any automation keyed off Environment or Expiry is blind. Tag governance is unglamorous and it's the difference between a run estate and a junk drawer.

Pick a small set of required tags

Don't enforce twenty tags — enforce the few that carry weight, so people actually comply:

CostCenter (or Team/BU) — for cost allocation.
Owner — a person or DL to contact.
Environment — prod / non-prod, which drives a lot of automation and policy.

Add Expiry or Project if your ops genuinely use them. Every required tag is friction at deploy time, so require only what earns its keep.

Two approaches: Deny vs inherit

	Require a tag (Deny)	Inherit from RG (Modify)
Effect	Blocks creation without the tag	Copies the tag value from the resource group
Deploys must	Set the tag themselves	Nothing — it's filled in
Best for	Tags unique per resource (Owner)	Tags natural at RG level (CostCenter, Environment)

A common pattern: inherit the tags that are set once per resource group (CostCenter, Environment) so nobody has to type them, and Deny the ones that must be resource-specific (Owner). Inherit is gentler — it doesn't fail deployments — so lead with it where it fits.

Assigning them

# Deny: require an "Owner" tag ("Require a tag on resources" built-in)
az policy assignment create \
  --name "require-owner-tag" \
  --policy "871b6d14-10aa-478d-b590-94f262ecfa99" \
  --scope "/subscriptions/<sub>" \
  --params '{ "tagName": { "value": "Owner" } }'

The "Inherit a tag from the resource group" policy uses Modify, so its assignment needs a managed identity with a role that can change resources (Tag Contributor or Contributor). Assign that with --mi-system-assigned and grant the role, then run remediation.

Fixing what already exists

Deny only stops new untagged resources — it won't retroactively tag your current estate. For that, use the Modify policy and run a remediation task, which walks existing non-compliant resources and applies the tag:

az policy remediation create \
  --name "tag-existing" \
  --policy-assignment "inherit-costcenter" \
  --resource-group "<rg>"

Roll it out gently

Lead with inherit (Modify) to backfill tags without breaking anything, remediate the existing estate, and only then add Deny policies for the resource-specific tags — after an audit pass so a required tag doesn't block a legitimate pipeline on day one. Same audit-then-enforce rhythm as the rest of the governance guardrails.

You can't manage what you can't name. Tags are how an estate names itself.

Questions people also ask

How do I require tags on Azure resources?

Assign the built-in "Require a tag on resources" (Deny) with the tag name; resources created without it are blocked. Use one assignment per required tag at a management group or subscription, and audit first if you have untagged resources.

How do resources inherit a tag from the resource group?

Assign "Inherit a tag from the resource group" (Modify), which copies the RG's tag value onto the resource — so deployments don't set it themselves. Modify needs a managed identity on the assignment and a remediation task for existing resources.

How do I tag existing untagged resources?

Deny only affects new resources; use a Modify policy (inherit, or add/replace a tag) and run a remediation task, which applies the tag to existing non-compliant resources. The assignment needs a managed identity with a role like Tag Contributor.

Why enforce tags?

Tags drive cost allocation, ownership, and lifecycle. Without a consistent CostCenter/Owner/Environment, cost reports can't attribute spend, orphaned resources have no owner, and tag-driven automation can't find its targets.