# Atlas tag enforcement through Terraform and APIs > Source-anchored research for Atlas tag enforcement through Terraform and APIs. Run status: COMPLETED. Parent: [Atlas tag taxonomy for showback and chargeback](https://llms-explorer.com/tree/atlas-tag-taxonomy-for-showback-and-chargeback/) · 4 facets · 15 facts · page: https://llms-explorer.com/tree/atlas-tag-enforcement-through-terraform-and-apis/ ## How it works - A Terraform tag gate applies to the Terraform execution path that runs it. Because Atlas also permits tag management through its UI and APIs, treating that gate as universal enforcement leaves other write paths uncovered. Recommended architecture, inferred from these interfaces: validate API provisioning requests and audit existing Atlas resources for missing required tags. (medium confidence) (verified as of 2026-10-14) — [source](https://www.openpolicyagent.org/docs/terraform) - Plan-based tag checks must handle unknown values explicitly. OPA warns that some values are unavailable until apply, while Terraform can defer condition evaluation when values are not yet known; a plan-time policy should not silently equate unknown tag values with verified compliance. (medium confidence) (verified as of 2026-10-30) — [source](https://www.openpolicyagent.org/docs/terraform) ## Problems, failure modes and limitations - Implementation pattern inferred from the provider and Terraform documentation: accept a standard tag map in an Atlas module, validate required keys and allowed values, and pass that validated value into the cluster tags argument. Variable validation or resource preconditions can stop the relevant Terraform operation when their conditions fail; merely declaring tags optional in the provider does not enforce this policy. (medium confidence) (verified as of 2026-10-30) — [source](https://github.com/mongodb/terraform-provider-mongodbatlas/blob/master/docs/resources/advanced_cluster.md) - A Terraform check block alone is insufficient for blocking required-tag enforcement: a failed check reports a warning and continues execution. Use blocking variable validation or preconditions when failure must stop provisioning. (low confidence) (verified as of 2026-10-30) — [source](https://developer.hashicorp.com/terraform/language/validate) ## Comparisons and alternatives - Atlas resource tags are user-managed key-value metadata for organizing projects and clusters by environment, application, team, or billing center. They differ from predefined replica-set tags and should not be treated as database read-routing controls. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/tags.md) ## Facts and statements - Atlas resource tags are key-value metadata managed through the UI, Administration API, CLI, or MongoDB Atlas Terraform provider. Standardize environment and application keys for consistent resource identification and cost attribution. (high confidence) — [source](https://www.mongodb.com/docs/atlas/tags.md) - Tag assignment is optional in the reviewed advanced_cluster resource documentation. Atlas suggests environment and application tags; those recommendations do not establish that Atlas rejects an untagged cluster. (high confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/atlas/tags.md) - OPA can inspect a Terraform plan converted with terraform show -json and evaluate organizational rules before apply, including whether resources have tags. Applying this to Atlas is an implementation pattern; the delivery pipeline must consume and enforce the policy decision, and handle unknown tag values explicitly. (medium confidence) — [source](https://www.openpolicyagent.org/docs/terraform) - In provider issue 2006, reported with Terraform 1.1.9 and an Atlas provider constraint >=1.15.1 in March 2024, Terraform apply overwrote externally changed tags. A maintainer confirmed tags were then a set of objects without addressable element keys; selective ignore_changes by tag key was unavailable in that implementation. Treat this as historical evidence, not a verified statement about every current provider version. (low confidence) — [source](https://github.com/mongodb/terraform-provider-mongodbatlas/issues/2006) - The reviewed Atlas Resource Policies documentation lists configuration controls and Cedar context fields but no tag-presence or required-tag control. Consequently this probe does not verify native Atlas-wide rejection of missing tags; treat Terraform policy gates and auditing of API/UI-created resources as separate controls. This is a scoped finding from documentation, not proof that native enforcement can never exist. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/atlas-resource-policies.md) - Tag policy inputs should use consistent case and avoid sensitive data. Atlas treats differently capitalized tag keys as distinct, and its documentation warns that billing and monitoring integrations can access tags. Tag values are operational metadata, not a secret store. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/tags.md) - Atlas documents programmatic tag management through the Administration API, Atlas CLI, and MongoDB Atlas Terraform provider. The advanced_cluster resource documents tags as optional; the existence of this field does not itself require an organization-specific owner or environment tag. (medium confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/atlas/tags.md) - MongoDB recommends applying environment and application tags and defining a strategy for mandatory tags. Its tagging blog describes this as a customer best practice using automation; it does not document an Atlas-wide mandatory-tag switch. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/tags.md) - Atlas Resource Policies provide server-side organization-level configuration guardrails with project exceptions. The AWS architecture article describes request-time rejection of violating configurations, but does not establish a required-tag policy capability; generic Cedar attribute-based authorization must not be assumed to expose Atlas tag attributes. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/atlas-resource-policies.md) - OPA can evaluate Terraform plan JSON before apply, and its documentation explicitly identifies ensuring resources have tags before creation as a use case. An Atlas-specific policy must inspect the provider resource type and actual tags representation; the OPA tutorial is generic and does not supply a tested MongoDB Atlas rule. (medium confidence) (verified as of 2026-10-30) — [source](https://www.openpolicyagent.org/docs/terraform)