A platform team must make sure every AWS resource in dev, staging and prod carries CostCenter and Owner tags. Engineers currently add a tags argument to each of roughly 200 resources by hand, and audits keep finding gaps. Which approach meets the requirement once, in code, with the least per-resource effort?
Select an answer to reveal the explanation.
Short Explanation
Think of default_tags as a stamp on the provider's door: everything that walks out gets the label without anyone remembering to add it. You write the rule once and the gaps disappear. The trap is picking something that only complains about missing tags instead of actually applying them.
Full Explanation
A cross-cutting requirement that applies to every resource belongs at the layer every resource shares. The AWS provider's default_tags block defines tags at the provider configuration level, and the provider merges them into the tags of every taggable resource it manages, so the requirement is expressed once rather than in 200 separate arguments. Resource-level tags still work and can add or override keys, which keeps team-specific labels possible. A check block only reports a warning after the plan or apply; it detects the gap but never fills it, and it never blocks a run. A validation rule on a tags variable inspects that variable alone; it cannot see whether each resource block actually references the variable, so a resource that forgets the argument still ships untagged. Using ignore_changes on tags tells Terraform to stop managing tag drift, which is the opposite of enforcing a standard and lets console edits silently replace the required values. Exam caveat: default_tags is a provider feature, not a Terraform language feature, so for other providers the equivalent pattern is a shared local map merged into each resource's tags. Operational check: run terraform plan on a resource with no tags argument and confirm the planned tags_all attribute shows both CostCenter and Owner.