HashiCorp Terraform Associate (004) Question 132
Single answer5 Terraform modulesYour team maintains a reusable Terraform module that creates an AWS VPC, subnets, and route tables. Several application teams consume this module from a private Git repository using a module block like source = "git::https://example.com/network.git?ref=v1.2.0". You need to add support for optional VPC flow logs without breaking existing consumers. Which approach is the best way to update the module while minimizing risk for teams already using it?
- A
Add a new input variable such as enable_flow_logs with a default value of false, release a new module version, and have consumers upgrade when ready
- B
Modify the existing module to always create flow logs, then ask all teams to run terraform apply so their environments stay consistent
- C
Create a second root module in the same repository for flow logs and tell consumers to call both root modules together from the same working directory
- D
Remove the existing subnet outputs and replace them with flow log outputs so consumers are forced to adopt the new feature during their next plan
Show answer and explanation
Correct answer: A
Explanation
When maintaining reusable Terraform modules, the safest way to evolve functionality is to preserve backward compatibility whenever possible. Optional features should generally be introduced with new input variables and defaults that keep existing behavior unchanged. Consumers can then adopt the new version intentionally, often by updating the module source ref to a newer Git tag or version. This reflects common Terraform best practices for module design: treat variables and outputs as part of the module interface, avoid unnecessary breaking changes, and version modules so downstream users can control upgrades. HashiCorp documentation on modules and module structure emphasizes reusable child modules with clear inputs/outputs and predictable behavior, while versioning helps teams manage change safely.
- A. Correct.
Correct. This is the safest backward-compatible module change. Adding a new input variable with a sensible default preserves current behavior for existing consumers, while allowing teams to opt in to the new feature. Releasing a new version and letting consumers choose when to upgrade aligns with module versioning best practices and reduces the chance of unexpected infrastructure changes.
- B. Incorrect.
Incorrect. Forcing a new resource on all existing consumers is a breaking behavioral change, even if the module interface does not change. Existing teams may not want the extra cost, IAM permissions, or logging behavior. A reusable module should avoid surprising downstream users when introducing optional functionality.
- C. Incorrect.
Incorrect. Terraform modules are intended to encapsulate related infrastructure behind a stable interface. Telling consumers to coordinate multiple root modules from the same working directory is not a good module design pattern and increases operational complexity. Root modules are the entry point for a configuration, while reusable child modules should expose optional functionality through variables and outputs.
- D. Incorrect.
Incorrect. Removing or changing existing outputs in a way that downstream configurations depend on is a breaking change. Outputs are part of the module's public interface. Replacing subnet outputs with unrelated flow log outputs would likely break callers that reference those values and is not an appropriate way to introduce an optional feature.