A subnet is created with 10.1.9.0/24 instead of 10.1.1.0/24. The root module declares variable app_cidr with default 10.1.1.0/24, sets local.subnet_cidr = var.app_cidr, and passes the local to a network module. The directory holds terraform.tfvars with app_cidr = 10.1.1.0/24 and prod.auto.tfvars with app_cidr = 10.1.9.0/24. Where does the wrong value come from?
Select an answer to reveal the explanation.
Short Explanation
Think of variable files as people talking in a meeting: whoever speaks later gets the final word. The .auto.tfvars file speaks after terraform.tfvars, so its value wins. The trap is forgetting that a file you didn't pass on the command line is still loaded automatically.
Full Explanation
When the same root variable is set in several places, Terraform applies a fixed precedence order, and later sources override earlier ones: the variable default, then environment variables, then terraform.tfvars, then terraform.tfvars.json, then any .auto.tfvars or .auto.tfvars.json files in lexical order, and finally -var and -var-file options on the command line. Both files here load automatically, but prod.auto.tfvars is processed after terraform.tfvars, so app_cidr resolves to 10.1.9.0/24; the local and the module input simply pass that value along. terraform.tfvars is not the last file read; it sits below every auto.tfvars file. A default applies only when no other source sets the variable, and a local that references var.app_cidr receives the variable's final resolved value, not its default. Child modules receive exactly what the module block passes them; their own defaults apply only to inputs the caller omits, and here the caller passes the CIDR explicitly. Exam caveat: an auto.tfvars file left in a shared directory affects every run there, which is a common source of environment bleed. Operational check: run terraform console and evaluate var.app_cidr, then list the directory for any *.auto.tfvars files.