Academmia

The Purpose of Tags

az-900•mixed•

Management and governance

The Purpose of Tags

Short Summary

Azure tags are key/value labels you attach to resources to make them easier to organize and report on. Used consistently, tags help you filter resources and allocate costs without changing your resource hierarchy. Tags are metadata only: they don’t enforce access, and they don’t automatically propagate from a resource group to every resource inside it.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define an Azure tag and explain what it’s used for.
  • Describe how tags support organization, filtering, and cost reporting.
  • Distinguish tags from resource groups/subscriptions and from Azure role-based access control (Azure RBAC).
  • Identify common tagging mistakes and choose a practical correction.

Core Concepts

A tag in Azure is a name/value pair (also called a key/value pair) that you attach to an Azure resource, resource group, or subscription. Think of it as metadata you can search and group by later, like Environment=Prod or CostCenter=FIN.

What tags are for

Tags are mainly for organization and reporting:

  • Organize and search: filter resource lists quickly in the Azure portal (for example, “show me everything with App=Checkout”).
  • Standardize ownership: mark who owns what (Owner=PlatformTeam) without forcing everything into a single subscription or resource group layout.
  • Cost allocation and reporting: group costs by business dimensions like cost center, department, application, or environment.

What tags are not

Tags are useful, but they have clear limits:

  • Not security: tags do not grant or block access. Access control is handled by Azure RBAC (roles/permissions for users, groups, and service principals).
  • Not a replacement for hierarchy: resource groups are for lifecycle management (deploy/update/delete together), and subscriptions/management groups are for governance and scale. Tags complement these by adding flexible labels across any structure.
  • Not secret storage: tags are stored as plain text. Don’t put sensitive data (passwords, keys, personal data) into tag values.

Tag consistency matters

Tags only stay useful when you keep them consistent. A small, agreed tag set beats a large, chaotic one.

Two details that help avoid “tag drift”:

  • Tag names are treated as case-insensitive for many operations, but you can still end up with inconsistent casing in reports if people aren’t disciplined.
  • Tag values can be case-sensitive, so Prod and prod may show up as different buckets in reporting.

Inheritance and enforcement

By default, resources don’t inherit tags from a resource group or subscription. If you want “everything must have these tags,” you need enforcement.

A common approach is Azure Policy to:

  • require specific tags at creation time, and/or
  • add/append tags during deployment (and in some cases remediate existing resources).

Tags in cost reporting: what to expect

Cost reporting by tag is very useful, but it isn’t magic:

  • Tags need to be applied to the resource for many usage records to include them (they aren’t automatically inherited from the resource group).
  • Tag-based views show up after Cost Management data refreshes, and not all charges will include tags (some services and some purchase types may not surface tags the way you expect).

Practical Understanding

Practical Situation 1: When you need to split cloud spend by department

Your finance team wants to see how much each department costs each month. Many resources are shared and sit in the same subscription, so “subscription = department” isn’t realistic.

How to think about it: Use tags to add a business dimension, such as Department=Sales or CostCenter=1234. Then you can group and review costs by that tag in Azure Cost Management.

Common misunderstanding: “Tags automatically appear for every cost line, instantly.” Tag-based reporting depends on usage records and data refresh. Some costs may not carry tags as you expect.

Practical Situation 2: When you want fast filtering during troubleshooting

You’re investigating a production issue and need to quickly find only the production resources for a specific app across multiple resource groups.

How to think about it: Tags are great for cross-cutting filters like Environment=Prod and App=Checkout. You can filter resource lists using tags without reorganizing resource groups.

Common misunderstanding: “Resource groups already solve this; tags are redundant.” Resource groups reflect lifecycle and deployment boundaries; tags provide additional labels that can cut across those boundaries.

Practical Situation 3: When someone tries to use tags for security

A team suggests tagging a resource with DataClassification=Confidential and assumes only a security group will be able to access it.

How to think about it: Tags are descriptive, not protective. To control access, use Azure RBAC. A classification tag can help with reporting or automation, but it doesn’t enforce permissions by itself.

Common misunderstanding: “If it’s tagged confidential, Azure will block access.” Azure won’t change permissions based on tags unless you explicitly implement enforcement (for example, with policy and role assignments).

Practical Situation 4: When you expect tags to “cascade” automatically

You tag a resource group with Owner=PlatformTeam and assume every resource inside it will automatically get the same tag.

How to think about it: Inheritance isn’t automatic. If you want consistent tagging at scale, you need a plan (standards + enforcement), often using Azure Policy.

Common misunderstanding: “Once the container is tagged, everything inside stays tagged forever.” Consistency comes from rules and enforcement, not from assumptions.

Common Pitfalls

  • Mistake: Treating tags as a security mechanism. Correction: Use Azure RBAC for access control; use tags only as metadata for organization and reporting.

  • Mistake: Storing sensitive information in tags. Correction: Treat tags as plain text metadata and keep sensitive values out of them.

  • Mistake: Using tags as a replacement for resource groups, subscriptions, or management groups. Correction: Use resource groups for lifecycle management and governance structures for control; use tags to add flexible labels across those structures.

  • Mistake: Inconsistent tag names or values (for example, Env vs Environment, or prod vs Prod). Correction: Define a small standard tag set and allowed values, then enforce it with governance and team conventions.

  • Mistake: Expecting tag-based cost reporting to work perfectly for every charge and every past month. Correction: Apply tags early, keep them consistent, and remember that some services and purchase types may not include tags in cost analysis.

Check Your Understanding

  • Write a simple tagging standard for a small project: pick 4–6 tag names (keys) and example allowed values.
  • Describe a scenario where a resource group is the right tool, and a different scenario where tags are the right tool.
  • Explain, in your own words, why a tag like DataClassification=Confidential does not restrict who can access a resource.
  • Think of a case where two teams share the same subscription. How would you still allocate costs and ownership cleanly?
  • Pick one tag you would enforce with policy (for example, Environment) and explain why enforcing it is worth the effort.

Further Reading