This chapter covers two distinct but often confused GCP features: Labels and Resource Tags. You will learn their definitions, use cases, limitations, and how they interact with IAM. For the ACE exam, approximately 5-8% of questions touch on resource metadata and tagging, often in scenarios involving cost allocation, access control, or resource organization. Mastering the differences between labels and resource tags is critical to avoid losing points on trick questions that test your understanding of their separate purposes and behaviors.
Jump to a section
Imagine a large corporate office with thousands of filing cabinets, each containing documents (resources). Labels are like color-coded sticky tags you put on the cabinet drawers. You can tag a drawer with 'Finance' and 'Confidential' to quickly find all finance-related files. Anyone can see these tags, and you can use them to sort or filter cabinets. They are metadata that helps you organize, search, and group resources. Resource tags, on the other hand, are like electronic access badges worn by employees. Each badge has embedded security attributes (e.g., 'Clearance Level 5', 'Department: Engineering'). When an employee tries to enter a secured area, the door reader checks the badge's attributes against an access policy. Crucially, the badge itself is not visible to everyone; its attributes are evaluated at the door, not used for sorting. Similarly, resource tags are not visible in the resource metadata by default; they are only evaluated by IAM policies at access time. You can't filter resources by resource tags in the console because they are not indexed for search. This mechanistic difference—labels for organization and search, resource tags for access control—is exactly how GCP separates the two features.
What are Labels?
Labels are key-value pairs that you can attach to resources to organize them, search for them, and allocate costs. They are metadata that is visible in the resource's metadata, in the Cloud Console, and in billing reports. Labels are not used for access control—they cannot be referenced in IAM policies. They are purely for organization and filtering. Each label consists of a key and an optional value. For example, environment: production or cost-center: finance. Labels are inherited by some child resources (like Compute Engine instances inherit from instance templates), but this is not consistent across all services.
What are Resource Tags?
Resource tags are also key-value pairs, but they are used exclusively for access control. They are not visible in the Cloud Console's resource metadata by default; they are stored separately and only evaluated when an IAM policy condition references them. Resource tags can be attached to resources (e.g., Compute Engine instances, persistent disks) and to organizations, folders, or projects. IAM policies can include conditions that check for a specific tag binding on the resource being accessed. For example, you can create an IAM condition that grants access only if the resource has the tag access-level: sensitive. Resource tags are NOT inherited—they must be explicitly attached to each resource.
How Labels Work Internally
When you create a label on a resource, the label is stored as part of the resource's metadata. In Compute Engine, for example, labels are stored in the labels field of the instance resource. You can view labels via the gcloud compute instances describe command. Labels are indexed by Cloud Asset Inventory and can be used in filters for gcloud commands, Cloud Console search, and billing reports. They are also used by the Cloud Billing export to CSV or BigQuery, where each billing line item includes the labels of the resource that generated the cost. Labels have a maximum of 64 keys per resource, each key up to 63 characters, and each value up to 63 characters. Keys must start with a lowercase letter, and can contain lowercase letters, digits, underscores, and hyphens. Values can be empty. Labels are not automatically propagated; you must set them explicitly on each resource.
How Resource Tags Work Internally
Resource tags are stored in the Cloud Resource Manager (CRM) system, not in the resource's metadata. When you attach a tag to a resource, CRM creates a binding between the tag and the resource. This binding is evaluated at access time. When a user makes an API call, IAM checks the policy bindings that apply to the user, the resource, and the API method. If a policy condition references a tag, IAM queries CRM to see if the resource has that tag. This adds latency to authorization decisions, but it is typically negligible. Resource tags are hierarchical: you can create tag keys and values at the organization level, and then attach those values to resources. Tag keys and values must be created before they can be attached. Tag keys have a maximum length of 63 characters, and tag values up to 63 characters. Resource tags are not visible in the Cloud Console's resource detail pages by default; you must use the Tags section or the gcloud resource-manager tags commands. Resource tags are not included in billing exports.
Key Differences at a Glance
Purpose: Labels for organization, search, cost allocation; Resource tags for access control.
Visibility: Labels visible in resource metadata and Console; Resource tags not visible by default.
IAM usage: Labels cannot be used in IAM policies; Resource tags can be used in IAM conditions.
Inheritance: Labels may be inherited by some child resources (but not guaranteed); Resource tags are never inherited.
Hierarchy: Labels are flat key-value pairs; Resource tags are hierarchical (key > value).
Management: Labels can be set directly on resources; Resource tags require creating the tag key/value first in CRM.
Billing: Labels are included in billing exports; Resource tags are not.
Filtering: Labels can be used to filter resources in gcloud and Console; Resource tags cannot be used for filtering.
Creating and Managing Labels
You can add labels at resource creation or later. For Compute Engine:
gcloud compute instances create my-instance --labels=environment=production,cost-center=itTo update labels on an existing instance:
gcloud compute instances add-labels my-instance --labels=environment=stagingTo remove a label:
gcloud compute instances remove-labels my-instance --labels=environmentLabels can also be set via the Cloud Console in the resource's detail page under the Labels section. You can filter resources by label using --filter:
gcloud compute instances list --filter='labels.environment=production'Creating and Managing Resource Tags
First, create a tag key at the organization level:
gcloud resource-manager tags keys create access-level --parent=organizations/123456789 --purpose=GCE_FIREWALL --purpose-data=network=defaultThen, create a tag value:
gcloud resource-manager tags values create sensitive --parent=tagKeys/12345Attach the tag value to a resource (e.g., a Compute Engine instance):
gcloud compute instances add-tags my-instance --tags=tagValues/67890To use the tag in an IAM policy condition:
resource.matchTag('organizations/123456789/access-level/sensitive')Note that the tag must be attached to the resource, and the condition checks for that specific tag value.
Interaction with Other Services
Cloud Billing: Labels are exported in billing data; you can break down costs by label. Resource tags are not exported.
Cloud Asset Inventory: Both labels and resource tags are indexed, but labels are searchable, resource tags only appear in the asset's tag bindings.
IAM: Resource tags are the only way to conditionally grant access based on resource metadata. Labels cannot be used in IAM.
Compute Engine: Firewall rules can use resource tags (network tags) but those are different from resource tags. Network tags are a legacy feature; resource tags are newer and can be used in IAM conditions for Compute Engine resources.
Cloud Logging: Labels can be used to filter logs; resource tags are not available as log filters.
Best Practices
Use labels for cost allocation and resource grouping. Ensure consistency by enforcing label keys via organization policies.
Use resource tags for fine-grained access control when you need to grant permissions based on resource characteristics (e.g., only allow access to instances tagged as production).
Avoid using labels for access control; they are not evaluated by IAM.
Remember that resource tags are not inherited; you must attach them to each resource individually.
Tag keys and values are immutable after creation except for the description; plan your hierarchy carefully.
Common Pitfalls
Trying to use labels in IAM conditions: This will not work. Use resource tags instead.
Expecting resource tags to appear in the resource's metadata: They are stored separately in CRM.
Assuming resource tags are inherited: They are not. Each resource must have the tag explicitly attached.
Confusing resource tags with network tags: Network tags are a Compute Engine legacy feature used for firewall rules, not for IAM conditions. Resource tags are a newer, more powerful feature.
Exam Relevance
On the ACE exam, you will likely see questions that ask you to choose between labels and resource tags for a given scenario. Remember: if the requirement involves cost allocation, reporting, or resource grouping, use labels. If the requirement involves conditional access control based on resource attributes, use resource tags. Also, know that resource tags can be used in IAM conditions only after they are attached to the resource. You cannot use a tag that is only defined but not attached.
Identify the Requirement
Read the scenario carefully. Determine if the requirement is about organizing resources, cost tracking, or filtering (use labels) or about controlling access based on resource attributes (use resource tags). For example, if the question says 'allow only members of the finance team to access instances that are used for financial reporting,' that is an access control requirement—use resource tags. If it says 'group all development instances together for cost reporting,' use labels.
Create Label or Tag Key-Value Pair
For labels, you can directly add them to the resource during creation or afterward using the Console, gcloud, or API. For resource tags, you must first create the tag key and tag value at the organization level using the Cloud Resource Manager API or gcloud. The tag key can have a purpose (e.g., GCE_FIREWALL) that restricts where it can be attached. This step is mandatory; you cannot attach a tag that doesn't exist.
Attach to the Resource
For labels, use the resource's API or gcloud command to add the label. For resource tags, use the `add-tags` command on the resource (e.g., `gcloud compute instances add-tags`). The tag is attached as a binding between the tag value and the resource. This binding is stored in Cloud Resource Manager, not in the resource itself. You can attach multiple tags to a single resource.
Use in Billing or IAM Policy
For labels, once attached, they appear in billing export data. You can filter billing reports by label. For resource tags, you can now write an IAM policy condition that references the tag. For example, `resource.matchTag('organizations/123456789/access-level/sensitive')`. This condition is evaluated at access time. If the resource does not have that tag, the condition fails and access is denied.
Verify and Troubleshoot
For labels, verify by describing the resource (e.g., `gcloud compute instances describe my-instance --format='value(labels)'`). For resource tags, use `gcloud compute instances describe my-instance --format='value(tags)'` (note: this shows network tags, not resource tags). To see resource tags, use `gcloud resource-manager tags bindings list --parent=//compute.googleapis.com/projects/my-project/zones/us-central1-a/instances/my-instance`. If the IAM condition is not working, ensure the tag is attached to the resource and that the condition syntax is correct.
Enterprise Scenario 1: Cost Allocation by Department
A large enterprise with multiple departments (Engineering, Marketing, Sales) uses GCP for various projects. Each department has its own project but shares some resources like Cloud Storage buckets. The finance team needs to allocate costs accurately. They implement a labeling strategy: each resource gets a label cost-center with the department code (e.g., cost-center: eng). They also add environment labels (prod, staging, dev). The billing export is configured to include labels, and BigQuery queries break down costs by cost-center and environment. This works well because labels are visible in billing data. However, they must enforce label consistency using Organization Policies (e.g., compute.requireOsLogin is not related, but they use constraints/compute.requireLabels to require specific label keys). Misconfiguration: if a resource is created without a label, it might be missed in cost reports, leading to unallocated costs. They use Cloud Asset Inventory to find resources missing labels.
Enterprise Scenario 2: Fine-Grained Access Control for Sensitive Data
A healthcare company stores patient data in Cloud Storage buckets. Only authorized researchers should access buckets containing PHI (Protected Health Information). They use resource tags: create a tag key data-classification with values phi, pii, public. They attach the phi tag to specific buckets. IAM conditions are added to the researcher role: resource.matchTag('organizations/123456789/data-classification/phi'). Only researchers with the role and whose request matches the condition can access the bucket. This is more secure than using labels because labels are visible to all users and cannot be used in IAM. Misconfiguration: if a bucket is accidentally not tagged, the condition fails and access is denied, which is a good failure mode. However, if the tag is removed, access is immediately revoked. They must ensure tag attachments are audited.
Enterprise Scenario 3: Environment-Based Access to Compute Instances
A SaaS company uses Compute Engine instances for different environments: production, staging, and development. Developers should be able to SSH into dev and staging instances, but only operations team can access production. They use resource tags: create tag key environment with values prod, staging, dev. Attach appropriate tags to instances. IAM conditions on the roles: developer role has condition resource.matchTag('.../environment/staging') OR resource.matchTag('.../environment/dev'). Operations role has condition resource.matchTag('.../environment/prod'). This ensures that even if a developer is granted compute.instances.get, they cannot access production instances. Misconfiguration: if an instance is tagged incorrectly, a developer might gain access to production. They use automated scripts to tag instances based on the project or deployment pipeline. They also use Organization Policies to restrict who can attach tags to resources.
What the ACE Exam Tests
This topic falls under Objective 4.2: 'Manage resource labels and resource tags.' The exam expects you to:
Differentiate between labels and resource tags.
Know that labels are for organization/cost allocation, resource tags for access control.
Understand that labels can be used in billing exports, resource tags cannot.
Know that resource tags can be used in IAM conditions, labels cannot.
Recognize that resource tags are hierarchical and must be created before attachment.
Know that network tags (legacy) are different from resource tags.
Common Wrong Answers and Why
'Use labels to restrict access to resources' – This is wrong because labels are not evaluated by IAM. Candidates confuse labels with resource tags because both are key-value pairs.
'Resource tags are visible in the Cloud Console resource details' – Wrong. Resource tags are not displayed by default; you must go to the Tags section or use gcloud. Candidates assume they work like labels.
'Resource tags are inherited from the project' – Wrong. Resource tags are not inherited; they must be attached to each resource. Candidates might think they behave like IAM policies which are inherited.
'Labels can be used in IAM conditions if you use the `resource.labels` attribute' – Wrong. There is no such attribute in IAM conditions. Only resource tags support resource.matchTag().
Specific Values and Terms That Appear on the Exam
resource.matchTag('tagKeys/12345') or full path: resource.matchTag('organizations/123456789/environment/prod')
gcloud resource-manager tags keys create and gcloud resource-manager tags values create
gcloud compute instances add-tags (for resource tags) vs gcloud compute instances add-labels (for labels)
Maximum 64 labels per resource, key/value length 63 characters.
Resource tag key and value lengths also 63 characters.
The --purpose flag when creating tag keys (e.g., GCE_FIREWALL).
Edge Cases and Exceptions
Network tags vs resource tags: Network tags are a legacy feature of Compute Engine used for firewall rules and network access. They are not resource tags. The exam may test that network tags can be used in firewall rules but not in IAM conditions (unless you use a specific firewall rule condition, but that's different). Resource tags are newer and can be used in IAM.
Tag attachments on deleted resources: When a resource is deleted, its tag bindings are automatically removed. You don't need to clean them up.
Tag keys and values are immutable: Once created, you cannot change the key or value name. You can only change the description. If you need a different name, you must create a new key/value and re-attach.
Billing export: Labels appear in the billing export only if they were present at the time of usage. If you add a label after the billing period, it won't retroactively appear.
How to Eliminate Wrong Answers
If the question mentions 'cost allocation,' 'filtering,' or 'searching,' the answer is labels.
If the question mentions 'access control,' 'IAM condition,' or 'conditional access,' the answer is resource tags.
If the answer option says 'network tags' and the context is IAM access control, it's likely wrong unless the question specifically mentions firewall rules.
Remember: resource tags require creating a tag key/value first. If the scenario doesn't mention that step, consider whether it's feasible.
Labels are for organization and cost allocation; resource tags are for access control.
Labels can be used in billing exports; resource tags cannot.
Resource tags can be used in IAM conditions via resource.matchTag(); labels cannot.
Resource tags are not inherited; they must be attached to each resource individually.
Labels are visible in resource metadata; resource tags are not by default.
Tag keys and values must be created before attaching resource tags; labels can be created on the fly.
Maximum 64 labels per resource; no hard limit on resource tags but best to keep under 50.
Network tags (Compute Engine) are different from resource tags; network tags are for firewall rules.
These come up on the exam all the time. Here's how to tell them apart.
Labels
Used for organization, search, and cost allocation
Visible in resource metadata and Cloud Console
Can be used in billing exports
Cannot be used in IAM policies
Flat key-value pairs, no hierarchy
Up to 64 labels per resource
Can be added directly to resources without prior creation
Resource Tags
Used for access control via IAM conditions
Not visible in resource metadata by default
Not included in billing exports
Can be used in IAM conditions using resource.matchTag()
Hierarchical: tag key > tag value, defined at org level
No limit on number of tags per resource (but practical limits apply)
Must create tag key and value before attaching to resources
Mistake
Labels and resource tags are interchangeable.
Correct
Labels are for organization and cost allocation; resource tags are for access control. They have different APIs, behaviors, and limitations. Labels cannot be used in IAM policies; resource tags cannot be used in billing exports.
Mistake
Resource tags are visible in the Cloud Console resource details page by default.
Correct
Resource tags are not displayed in the main resource details page. They are visible only in the 'Tags' tab or via gcloud commands. Labels are shown directly in the resource metadata.
Mistake
Resource tags are inherited from the project or folder.
Correct
Resource tags are not inherited. Each resource must have the tag explicitly attached. This is different from IAM policies which are inherited.
Mistake
Labels can be used in IAM conditions using the `resource.labels` attribute.
Correct
IAM conditions do not support `resource.labels`. The only way to condition on resource metadata is using `resource.matchTag()` for resource tags. Labels are not available in IAM.
Mistake
Network tags and resource tags are the same thing.
Correct
Network tags are a legacy Compute Engine feature used for firewall rules and networking. Resource tags are a newer feature for IAM-based access control. They are separate and have different APIs.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. Labels are not evaluated by IAM. They are metadata for organization and cost allocation only. To grant conditional access based on resource attributes, you must use resource tags with IAM conditions. For example, you cannot write an IAM condition that checks `resource.labels.environment == 'prod'`. Instead, you would use `resource.matchTag('organizations/123/environment/prod')` with a resource tag attached.
Resource tags are not shown in the standard `gcloud compute instances describe` output. Use `gcloud resource-manager tags bindings list --parent=//compute.googleapis.com/projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME`. In the Console, go to the instance details page and click the 'Tags' tab. Labels are shown directly in the instance details under 'Labels'.
No. Resource tags are not inherited. Each resource must have the tag explicitly attached. If you want all resources in a project to have a certain tag, you must attach it to each resource individually, or use automated tooling like Deployment Manager or Terraform to ensure tags are applied.
Yes. Labels are the primary mechanism for cost allocation in GCP. You can add labels to resources and then view cost breakdowns by label in the Cloud Billing reports or by exporting billing data to BigQuery. Resource tags are not included in billing exports.
Network tags (legacy) are used for Compute Engine firewall rules and networking. They are strings attached to VM instances and can be used in firewall rule sources/targets. Resource tags are a newer feature for IAM-based access control. They are key-value pairs attached via Cloud Resource Manager and can be used in IAM conditions. Network tags cannot be used in IAM conditions (unless you use a specific firewall rule condition, but that's different).
You can attach up to 64 labels per resource. Each label key can be up to 63 characters, and each value up to 63 characters. Keys must start with a lowercase letter and can contain lowercase letters, digits, underscores, and hyphens. There is no documented limit on the number of resource tags per resource, but best practices suggest keeping it under 50.
No. Tag keys and values are immutable after creation. You can only change the description. If you need a different key or value name, you must create a new one and re-attach it to resources. This is to ensure consistency in IAM policies that reference them.
You've just covered GCP Labels and Resource Tags — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?