TF-004 Read, generate and modify configuration Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  They forgot to include the -var-file flag; add -var-file='dev.tfvars' to the plan command.

  Why this is correct

  Terraform has specific conventions for automatically loading variable definition files, which include `terraform.tfvars`, `terraform.tfvars.json`, and any files ending with `*.auto.tfvars` or `*.auto.tfvars.json`. A file named `dev.tfvars` does not adhere to these automatic loading patterns. Therefore, to ensure that the variable definitions within `dev.tfvars` are applied during a `terraform plan` operation, it must be explicitly included using the `-var-file='dev.tfvars'` flag on the command line.

• ✗

  The variable is defined in the child module; they need to reference it with module.cidr_block in the root module.

  Why it's wrong here

  Variables declared within any module, whether it's the root module or a child module, are always referenced directly by their name within that module's scope using the `var.` prefix (e.g., `var.cidr_block`). The `module.` prefix is exclusively used to access *outputs* exported by a child module (e.g., `module.my_module.output_name`), not to reference input variables defined within it. Attempting to use `module.cidr_block` for an input variable would result in a syntax error or an unknown reference.

• ✗

  The workspace is not selected; run 'terraform workspace select dev' again.

  Why it's wrong here

  Terraform workspaces are designed to manage distinct state files for different environments or isolated deployments, allowing multiple instances of the same configuration to coexist. While selecting a workspace ensures the correct state is used for subsequent operations, it does not inherently dictate how variable definition files are loaded or automatically apply environment-specific `.tfvars` files unless they follow the `*.auto.tfvars` naming convention. Since the user confirmed the `dev` workspace is already selected, re-running `terraform workspace select dev` would be redundant and would not resolve the issue of an unapplied variable file.

• ✗

  The variable must be passed through the module block; they should add a module input assignment.

  Why it's wrong here

  While variables can indeed be passed directly to a child module via its `module` block (e.g., `module "my_module" { cidr_block = var.root_cidr }`), this option suggests modifying the module's input assignment. The problem statement implies the variable `cidr_block` is expected to be provided to the overall Terraform configuration, likely at the root module level, or as an input to a child module that already defines it. If the module already expects `variable "cidr_block" {}`, then supplying its value via a loaded `.tfvars` file or CLI flag is the correct mechanism for providing its value to the configuration, rather than altering the module's input definition.

Go deeper

Related to this question