skip to content

What does the default_tags block in Terraform's aws provider do, and what does it not cover?

level: middleimportance: nice to knowfreq 40%

answer

  1. tags without repeating yourself
  2. the specific beats the general
  3. only what this provider manages
  4. not every resource takes a tags map
  5. ignore_tags stops the plan churn

basics

~20 s

It sets tags applied to every taggable resource that provider instance manages, so cost and ownership tags stop being copy-pasted per resource. It does not reach resources managed elsewhere, data sources, or tagging shapes that are not a plain tags map.

solid answer

~50 s

`default_tags` is a block inside the `provider "aws"` configuration holding a `tags` map that the provider merges into every taggable resource it manages. It exists because ownership, cost-centre and `ManagedBy` tags would otherwise be pasted into hundreds of resource blocks and drift apart. A resource's own `tags` argument still wins for a key that appears in both. What it does not cover is worth stating explicitly: resources created outside this configuration, data sources, and resources whose tagging is not a straightforward `tags` map — an autoscaling group's `tag` blocks or an instance's `volume_tags`, for instance. Its sibling `ignore_tags` handles the opposite problem: tags applied by an external system that would otherwise show as drift on every plan. And when you first add `default_tags` to an existing estate, expect a very large plan — every managed resource acquires the new tags at once.

code

hcl · 24 lines
hcl
provider "aws" {
  region = "eu-west-1"

  default_tags {
    tags = {
      Environment = "prod"
      ManagedBy   = "terraform"
    }
  }

  ignore_tags {
    key_prefixes = ["backup:", "compliance:"]
  }
}

resource "aws_s3_bucket" "artifacts" {
  bucket = "example-artifacts"

  # Wins over the provider default for the same key.
  tags = {
    ManagedBy = "terraform"
    Owner     = "platform"
  }
}

go deeper

for a junior

Know that the provider can carry a map of tags applied to the resources it manages, so common tags like an owner or environment do not have to be repeated in every resource block.

for a middle

Explain the merge and its precedence, name what the block does not reach — other systems' resources, data sources, non-standard tagging shapes — and know that ignore_tags exists for tags an external system applies.

for a senior

Be ready for the rollout: adding defaults to an existing configuration produces an estate-wide plan, most changes are in-place but you read rather than assume, and you sequence configurations so the highest blast radius is reviewed last.

for a principal

Own tagging as a policy question: which tags are mandatory, whether they are enforced in code, by a policy-as-code check, or by a cloud-side rule, and how you keep the answer consistent when several tools create resources in the same accounts.

## What it is for Organisations tag for cost allocation, ownership and lifecycle. Expressed per resource, those tags are pure duplication and diverge the moment someone copies a block without them: ```hcl provider "aws" { region = "eu-west-1" default_tags { tags = { Environment = "prod" Owner = "platform" ManagedBy = "terraform" } } } ``` Every taggable resource that this provider instance manages now carries those three tags without mentioning them. Each provider instance has its own `default_tags`, so a configuration with several provider configurations can tag each one's resources differently. ## Precedence and the merge For a key present in both `default_tags` and a resource's `tags` argument, the resource wins — the specific overrides the general, which is the behaviour you would want. Earlier releases in the v4 series handled duplicate keys poorly and could produce confusing perpetual differences; from provider v5 the override behaviour is the straightforward one. If you need to read the effective set inside the configuration, resources expose their merged result as a separate attribute. ## What it does not cover This is the half of the answer that separates someone who has used it from someone who has read about it. - **Anything not managed by this configuration.** Console-created resources, another team's stack, a Kubernetes controller provisioning load balancers — none of them see your defaults. - **Data sources.** Defaults are applied on write, not on read. - **Non-standard tagging shapes.** Not every resource takes a plain `tags` map. An autoscaling group declares `tag` blocks with `propagate_at_launch`; an EC2 instance's attached volumes are tagged through `volume_tags`. These are the classic surprises when someone checks a cost report and finds untagged volumes. - **Resources whose tags a different system owns.** Which leads directly to the next point. ## ignore_tags, the mirror image Many estates have an external tagging system — a compliance automation, a backup tool, a cost platform — that stamps its own tags onto live resources. Terraform sees tags it did not put there, wants to remove them, and every plan is noisy. `ignore_tags` in the same provider block, with `keys` or `key_prefixes`, tells the provider to leave matching tags alone: ```hcl provider "aws" { region = "eu-west-1" default_tags { tags = { ManagedBy = "terraform" } } ignore_tags { key_prefixes = ["backup:", "compliance:"] } } ``` The pair is the practical answer to "our plans always show tag churn". ## Rolling it out Adding `default_tags` to an existing configuration produces a plan touching every managed taggable resource. That is expected — they are all acquiring new tags — but it is an alarming first plan and worth flagging to reviewers. Most tag updates are in-place changes with no disruption; a small number of resource types treat tag changes more heavily, so read the plan rather than assuming it is cosmetic. Rolling it out per configuration, largest blast radius last, keeps each review manageable. ## Where it fits in an interview `default_tags` is not a headline topic, but it is a good signal question: it is the difference between someone who has maintained a real estate and someone who has only written greenfield modules. The strong answer covers the merge precedence, names at least one thing the block does not reach, mentions `ignore_tags` unprompted, and warns about the size of the first plan.

  • A team applies default_tags, then finds their EBS volumes and autoscaling groups still untagged. What happened?
    Those resources do not take a plain `tags` map in the same way. An autoscaling group declares `tag` blocks with `propagate_at_launch`, and an instance's attached volumes are tagged through `volume_tags`. The provider's defaults cover standard tagging arguments; these shapes need their tags supplied explicitly. It is the usual reason a cost report shows untagged storage in a supposedly fully-tagged estate.
  • Every plan shows Terraform trying to remove tags that a compliance tool adds. What do you configure?
    An `ignore_tags` block in the provider configuration, listing the offending `keys` or, better, `key_prefixes` if the external system namespaces them. The provider then leaves those tags out of its comparison, so they stop appearing as drift. It is the correct answer whenever another system legitimately owns part of a resource's tag set.
  • What should reviewers expect the first plan to look like after default_tags is introduced?
    Large — every managed taggable resource in that configuration shows a change, because they are all acquiring the new keys at once. Most are in-place updates, but you read the plan rather than assuming it is cosmetic, since a few resource types handle tag changes more heavily. Rolling it out one configuration at a time keeps each review reviewable.

saying these in an interview costs you the question

  • It tags resources created outside Terraform too
  • The provider default overrides a resource's own tag
  • Every taggable resource type picks it up identically
  • Adding it produces no plan changes
  • It retro-tags existing untagged infrastructure automatically

context

resolving links…