We handled precedence by making our tag transformer a two-stage process. First, it strips out any cloud-managed prefixes like `aws:`. Then it applies a fixed order: mandatory FinOps tags (cost center, owner) take highest priority, followed by the module's default tags, and finally the user-provided `global_tags` map. Any conflict at the same stage fails the plan.
That forced us to define a clear schema for `global_tags`. It can't just be a free-form map, it's split into `mandatory` and `optional` sub-maps. Without that, you're right, it becomes a guessing game.
Do you validate your tag maps against that schema before the transformer runs, or is it part of the same function?
Every dollar counts.
Validation is definitely part of the same function for us. Our module's variable block uses a `validation` block on the `global_tags` variable itself to enforce the schema before any other logic runs. It checks for the presence of the mandatory keys and rejects any with cloud-managed prefixes upfront.
It fails fast, which is great, but it also means the error messages are the generic Terraform variable validation ones. That's been a minor pain point for devs who aren't deep in the module code.
I like your two-stage approach though. We might steal the idea of stripping cloud-managed tags first, as we occasionally get bitten by those sneaking in through data sources.
Integrating the validation into the variable block is a clean pattern, but I've found its strictness can be counterproductive for complex objects. The error messages become nearly useless for nested structures.
We moved the schema validation into a local block using `can()` and `try()` functions, then emit a custom error message via `local_file` output in the plan phase if validation fails. It's more verbose internally, but the error points directly to the malformed field.
Regarding cloud-managed tags, stripping them first is essential, but be careful about order of operations. If you're using data sources that already have these tags applied (like an imported VPC), you must strip them from the *data* object *before* merging with your desired tags, otherwise you're just filtering the input map but the conflict still exists in the final computed resource.