3.3 Tagging Strategy and Cost Allocation

Why tags matter in AZ-104

Azure tags are key-value metadata applied to resources, resource groups, and subscriptions. Administrators use them for cost allocation, ownership, automation, operational reporting, environment classification, and policy enforcement. A tag such as Environment=Prod can help filter resources, drive automation, and split Cost Management reports. It does not grant access, deny access, encrypt data, or prevent deletion.

A useful tag strategy is small, controlled, and enforced. Many organizations start with required tags such as Environment, Owner, CostCenter, Application, DataClass, and Criticality. The exact names matter less than consistency. CostCenter, costcenter, and Cost Centre are different keys in practice, and inconsistent values such as Production, Prod, and prd break reports.

Do not design tags as a substitute for management groups or subscriptions. Tags are excellent labels, but they do not create hard boundaries. If two workloads require different administrators, different compliance baselines, or separate quotas, tags alone are not enough. Use tags with RBAC, Policy, resource groups, and subscriptions.

Applying and managing tags

Tags can be applied in the portal from a resource, resource group, or subscription blade. They can also be set during deployment. In CLI, the common commands are simple:

az tag create --resource-id <resourceId> --tags Environment=Prod CostCenter=FIN-100 Application=Payments
az resource tag --ids <resourceId> --tags Environment=Prod Owner=team-payments
az group update --name rg-app-payments-prod --set tags.Environment=Prod tags.CostCenter=FIN-100

Be careful with command behavior. Some commands replace the entire tag set, while others merge or update keys. On an exam, if the scenario says existing tags must be preserved, choose an operation that updates or merges rather than replacing all tags. In scripts, read the current tag set before writing when preservation matters.

Cost allocation behavior

Cost Management can group and filter costs by tags, but only when the tags exist on charge-generating resources and are consistent during the billing period. Tags applied today do not reliably reclassify all historical usage. Also, not every charge behaves like a simple tagged resource cost in every billing context. The exam usually stays at the administrator level: use tags for cost allocation, then use budgets and Cost Management reports to alert and analyze.

A practical workflow for cost allocation is:

1. Define required keys and allowed values.
2. Apply tags at deployment time through Bicep, ARM templates, or portal standards.
3. Use Azure Policy to require or inherit tags.
4. Audit missing or invalid tags.
5. Use Cost Management to group by tag.
6. Correct resources and improve deployment templates when gaps appear.

Cost question workflow
Is the goal to classify spend? Use tags.
Is the goal to alert on overspend? Use budgets.
Is the goal to reduce waste? Use Advisor and right-sizing analysis.
Is the goal to block noncompliant creation? Use Azure Policy.
Is the goal to restrict who can spend? Use RBAC and subscription design.

Tag inheritance and Azure Policy

Tags are not automatically inherited from a subscription or resource group by every child resource in a universal way that solves governance by itself. Azure Policy can enforce inheritance patterns. For example, a policy can require a tag on resource groups, add or modify a tag on resources, or inherit a tag value from the resource group when missing. Built-in policies can help, and custom policies can handle special rules.

The policy effect matters. Deny blocks noncompliant requests. Audit reports noncompliance. Modify can add or update tags when the assignment has a managed identity with permission to make the change. Append can add fields to a request in some scenarios, though modern tag governance often uses Modify. Remediation tasks are needed to fix existing resources after a modify policy assignment.

Scenario workflow

A finance team wants monthly cost by application and cost center. Start with required tags Application and CostCenter. Use policy at a management group or subscription to deny resource group creation when tags are missing. Then use a modify or inherit-tag policy so resources created inside tagged resource groups receive the same values. Update Bicep templates to include tags explicitly, because policy should guard the process rather than be the only source of metadata.

Next, build a Cost Management view grouped by Application or CostCenter. If some costs appear untagged, inspect whether the resources were created before policy assignment, whether tags were applied to the resource group but not the charge-generating resources, or whether an operator used inconsistent keys. Fix the source process, then remediate existing resources where possible.

Exam traps

A question that asks to prevent deletion is not asking for tags. Use locks and RBAC. A question that asks to prevent users from deploying resources without CostCenter is asking for Policy. A question that asks to show chargeback by department is asking for tags and Cost Management. A question that asks to give a team access to only its resources is usually asking for RBAC at an appropriate scope, not tag-based access.

Also watch tag limits and service support. Azure has limits on number and length of tags, and some resource types or inherited costs have special behavior. AZ-104 rarely tests numeric edge cases in depth, but it does test the principle that tags are metadata for management and reporting, not security boundaries.