Task 5.2: Describe variable scope within modules

• AReference it in the child module's resources as parent.var.environment

  Incorrect

  There is no parent reference; a child sees only its own variables.

• BAdd the variable to a locals block in the child module

  Incorrect

  A local value is not an input, and it still cannot read the parent's variable.

• CDeclare it in the child and pass it as an argument of the module block

  Correct

  Child modules receive their inputs from the parent as arguments of the module block, which correspond to variables declared in the child.

• DMark the root module's variable with global = true

  Incorrect

  Variable blocks have no global argument; every module declares its own inputs.

Variables do not leak downward; each module declares its inputs, and the caller passes them in.

• AThe database module reads module.network.subnet_ids directly in its own resources

  Incorrect

  A child module cannot reference a sibling module; only the calling module can.

• BThe database module declares a data source that reads the network module's local values

  Incorrect

  Data sources read infrastructure through providers, not values inside other modules.

• CBoth modules share a common locals.tf file through a symbolic link in each directory

  Incorrect

  Sharing files does not share values across module boundaries.

• DThe network module outputs them, and the root passes them to the database module

  Correct

  Modules communicate through inputs and outputs; the parent wires one module's output into another's input.

Siblings never talk directly; the root module connects outputs to inputs.

• AIn a variables block nested inside the module block, one entry per input

  Incorrect

  There is no nested variables block; arguments are set directly.

• BAs arguments in the module block

  Correct

  Inputs let you customize a module's behavior; they are set as arguments in the module block.

• CWith an inputs.json file placed next to the module

  Incorrect

  Terraform has no such file; inputs come from the module block.

• DBy editing the child module's variable defaults

  Incorrect

  Editing the module changes it for every caller.

Module block arguments are the child's inputs.

• ATF_VAR_ values are read only during apply, so the plan still shows the old size

  Incorrect

  Environment variable values are part of planning; the timing is not the problem here.

• BChild modules read TF_VAR_ values only when the root declares a variable of the same name

  Incorrect

  Even then the child would not see it; a root variable reaches a child only through an argument in the module block.

• CThe variable needs the module's name in it, as TF_VAR_app_instance_type

  Incorrect

  There is no per-module form of TF_VAR_; the prefix maps to root module variable names.

• DTF_VAR_, -var and .tfvars set root module variables; a child's inputs come from its module block

  Correct

  The CLI options, variable files and environment variables assign values to root module variables, while child modules receive their inputs from the parent as module block arguments.

Values enter a configuration at the root. To change a child's input, set the argument in the module block, for example from a root variable that the environment variable then sets.

• ATerraform rejects the name, because version is reserved for module block arguments

  Correct

  source, version, providers, count, for_each, lifecycle, depends_on and locals are reserved and cannot be used as variable names, because a module block already gives them a meaning.

• BIt works, and callers set the release with version = "2.4.1" in the module block

  Incorrect

  In a module block, version is already the argument for the module's version constraint, so it could never reach a variable; that is why the name is reserved.

• CIt works, and Terraform also uses the value as the module's version constraint

  Incorrect

  Terraform does not give one argument two jobs; the name is refused before that could happen.

• DIt works for local modules, which have no version argument to clash with

  Incorrect

  The reserved names apply to every module, wherever its source comes from.

Inputs share the module block with its own arguments, such as source and version, so the reserved names are off limits; a name such as app_version avoids the clash.

• AAn empty string, because terraform.workspace is available in the root module only

  Incorrect

  terraform.workspace is a named value that every module of the configuration can read.

• Bdefault, because each child module keeps a workspace of its own

  Incorrect

  Modules do not have workspaces; the workspace belongs to the working directory and its state.

• Cstaging, the workspace selected for the whole configuration

  Correct

  terraform.workspace is the name of the currently selected workspace, and a child module sees the same value as its caller.

• DNo value until the module block passes workspace = terraform.workspace

  Incorrect

  Unlike input variables, built-in named values need no argument to reach a child module.

Input variables are scoped to the module that declares them, but built-in named values such as terraform.workspace describe the run itself and read the same in every module.

• AEach level declares a region variable and passes it down

  Correct

  Each module receives inputs only from its direct caller, so every level declares and passes the value.

• BNothing; grandchild modules can read root variables

  Incorrect

  No module reads another module's variables directly.

• Cdb can read var.region if the root marks it sensitive

  Incorrect

  Sensitivity changes how values are displayed, not which modules can see them.

• DThe root passes region directly to module.app.module.db in its module block

  Incorrect

  A module block can pass arguments only to the module it calls.

Values flow one level at a time, down through inputs.