Terraform Modules

The primary mechanism for passing input values from a parent module to a child module in Terraform is by using arguments in the module block that correspond to the child module's declared variables.

When you call a child module from a parent module, you use a module block and specify arguments that match the variable names declared in the child module. For example:

In the child module (variables.tf):
variable "instance_type" {
type = string
}

In the parent module:
module "my_module" {
source = "./child-module"
instance_type = "t2.micro"
}

This is the explicit and intended way Terraform handles module input passing.

The other options are incorrect for the following reasons:

• Environment variables are not automatically inherited by nested modules. While Terraform does support environment variables (TF_VAR_*), they only set values for root module variables and do not automatically propagate to child modules.

• The terraform.tfvars file only sets values for variables in the root module. It does not automatically propagate values to child modules in the configuration hierarchy. Child modules receive their values explicitly through module block arguments.

• Output blocks in the parent module are used to expose values from the module to external callers, not to pass values into child modules. There is no concept of 'input blocks' in Terraform - variables are used for inputs, and they receive values through module block arguments, not output-to-input linking.

Terraform automatically propagates the sensitive marking when constructing objects from sensitive input variables, and the child module's sensitive attribute provides additional protection for the entire object.

When you have sensitive input variables in the root module (like k8s_token and k8s_endpoint marked with sensitive = true), Terraform automatically tracks that sensitivity through expressions. When you construct an object from these sensitive values to pass to a child module, the resulting object inherits the sensitive marking from its components.

Additionally, when the child module's variable definition includes sensitive = true, this provides a second layer of protection. The child module's sensitive attribute ensures that even if somehow non-sensitive values were passed in, the entire object would still be treated as sensitive within that module's scope.

This dual-layer approach is a key feature of Terraform's sensitive value handling:
1. Sensitivity propagates automatically from input variables through expressions
2. Module variable definitions can add their own sensitive marking for defense in depth

The other options are incorrect for the following reasons:

• Using the sensitive() function to wrap values is not required when the source variables are already marked as sensitive. The sensitivity is automatically propagated through expressions and object construction.

• Terraform does respect sensitive marking on complex types, not just primitive types. When any component of an object is sensitive, the entire resulting object is treated as sensitive. You don't need to mark individual attributes within the type definition.

• Terraform does NOT treat all module inputs as sensitive by default. This would make the sensitive attribute meaningless and would also create unnecessary redaction in logs and outputs, reducing usability. The sensitive attribute has real functional implications and is not merely for documentation.

The correct answer is version = "~> 4.67.0" to restrict updates to patch releases within 4.67.x.

In Terraform, the ~> operator is called the 'pessimistic constraint operator' or 'tilde operator'. Its behavior depends on where you place the constraint:

• When you specify ~> 4.67.0 (with three version segments), Terraform allows only patch-level updates. This means it will accept versions 4.67.0, 4.67.1, 4.67.2, etc., but NOT 4.68.0 or higher. This is exactly what the team wants - staying within the 4.67.x patch releases only.

The other options are incorrect for the following reasons:

• Using ~> 4.67 (with only two version segments) would allow any version >= 4.67.0 and < 5.0.0. This includes minor version updates like 4.68.0, 4.69.0, etc., which could introduce breaking changes or new behaviors that the team wants to avoid.

• Using >= 4.67.0, < 5.0.0 creates a range that permits all minor and patch updates within version 4. While this prevents major version changes, it still allows minor version updates (4.68, 4.69, etc.) which may introduce significant feature changes.

• Using ~> 4.0 would allow any version from 4.0.0 up to but not including 5.0.0. This is far too permissive and would allow versions much older or newer than 4.67.0, defeating the purpose of version pinning for stability.

The ~> 4.67.0 constraint provides the best balance of stability (no minor or major version changes) while still allowing automatic patch updates that typically contain bug fixes and security patches.