A module declares variable instance_type with default t3.small, and terraform.tfvars sets it to t3.large. A local is defined as instance_type = var.environment == "prod" ? "m5.xlarge" : var.instance_type. With environment set to prod, an output shows m5.xlarge although the team expected t3.large. What explains the result?
Select an answer to reveal the explanation.
Short Explanation
A conditional is a fork in the road: when the condition's true, you take the left path and never see the right one. With environment set to prod, the hard-coded value wins every time. The trap is blaming variable precedence when the variable never got a vote.
Full Explanation
Tracing a value means following the expression that actually produces it. The local uses a conditional expression, condition ? true_val : false_val, and returns the true result when the condition holds. Because var.environment equals prod, the local returns the literal m5.xlarge, and var.instance_type, which correctly resolved to t3.large from terraform.tfvars, is never selected. The fix is a design decision, such as letting the variable override the prod default or removing the hard-coded branch. Definition files outrank defaults, not the other way around, so terraform.tfvars did set the variable as expected. A conditional selects one result based on the condition; Terraform requires both branches to have compatible types but does not pick by position or return both. Local values are evaluated fresh on every plan from current inputs, and refresh concerns remote object attributes, so there is no cached local to refresh. Exam caveat: this pattern, where a local silently overrides a variable for one environment, is a frequent root cause of configuration surprises and should be documented or made explicit in the variable's description. Operational check: open terraform console and evaluate var.instance_type, var.environment and local.instance_type separately to see which input selects the branch.