Your Terraform root module must stamp the same owner, environment and cost-centre tags on every AWS resource, plus a per-resource Name tag. How do you structure that with locals, and what happens on the next plan when someone adds a tag?

## The pattern Almost every organisation requires a baseline tag set for cost allocation, ownership and cleanup automation. The Terraform expression of that is one map in a `locals` block, merged at each use site: ```hcl variable "environment" { type = string } variable "owner" { type = string } locals { name_prefix = "payments-${var.environment}" common_tags = { Environment = var.environment Owner = var.owner CostCentre = var.cost_centre ManagedBy = "terraform" } } resource "aws_instance" "web" { # ... tags = merge(local.common_tags, { Name = "${local.name_prefix}-web" Role = "frontend" }) } ``` Two things make this work. First, the local is *derived from variables*, not hardcoded — the same configuration produces the right tags in every environment. Second, `merge` combines maps left to right, with keys in later arguments overriding earlier ones, so the per-resource literal is free to add `Name` and `Role` and even to override `Owner` for one exceptional resource without anyone editing the shared map. ## Why a local and not a variable You could declare `variable "common_tags"` with a default, but then the tag policy becomes part of the module's public interface: any caller can replace the whole map, including dropping `ManagedBy`. As a local it is a decision the module owns, and the *inputs* to it — environment, owner, cost centre — stay as variables. That is the general shape: expose the parameters, keep the derivation internal. ## The change profile This is what interviewers usually probe. Adding a key to `local.common_tags` is one line, but the next `terraform plan` touches every resource that reads the local. For tags on most AWS resources that is an in-place update — Terraform shows `~ tags` with the added key and no `forces replacement` marker — because the provider maps tag changes onto tagging API calls rather than a recreate. A plan of two hundred in-place tag updates is expected here and is not a reason to panic; it *is* a reason to read the diff, because a genuinely large plan is where a destructive change hides in plain sight. Two cautions worth voicing. Not every taggable object is a plain in-place update — some resources expose tags on nested or separate objects, and a few third-party providers implement tag changes less gracefully — so you read the plan rather than assume. And a large tag-only apply is still an apply against production, so it belongs in the normal review-and-approve flow, not a quick unreviewed run. ## Interactions worth knowing **Provider `default_tags`.** The AWS provider supports a `default_tags` block in the provider configuration that applies a tag set to every resource that provider manages, which removes the need to write `tags =` on each resource. It is an alternative to the merge pattern, not a complement — running both invites confusion about which layer set a key. Pick one and state which in the repository's conventions. **Type consistency.** A tag map is `map(string)`, so every value must be a string. A boolean or number sneaking in through a variable causes a type error at plan time; wrap with `tostring()` when in doubt. **Case sensitivity.** Tag keys are case-sensitive in AWS. `Environment` and `environment` are two separate tags, and `merge` will not treat them as the same key — a common source of duplicated tags in a repository where two people wrote the map differently. **Do not put secrets in tags.** Tags are visible in the console, in state, in cost reports and in plan output. The shared map is exactly the wrong place for anything sensitive. ## Naming built from the same idea The same locals block usually carries `name_prefix`. A single derived prefix used by every resource name keeps naming consistent, makes an estate greppable, and means renaming a project is one edit — though be aware that for most resources the name *is* part of identity, so changing a prefix plans as destroy-and-create, not an update. That asymmetry between tags (mutable) and names (often identity) is the useful thing to be able to say out loud.