Terraform modules

How does a module sourced from a local path differ from one sourced from the Terraform Registry in the way Terraform handles it?

• AA local module is referenced by a filesystem path and takes no version argument, whereas a registry module is referenced by a registry address and can be pinned with a version constraint.check_circle Correct
• BA local module must be downloaded during init, whereas a registry module is read directly from disk without any retrieval step.
• CA local module requires a version argument to select a release, whereas a registry module ignores any version argument supplied.
• DA local module can only define data sources, whereas a registry module can define managed resources as well.

Why A is correct: Local modules live alongside the configuration and are addressed by a relative path, so there is nothing to version, while registry modules are published releases that support a version argument for pinning.

Why B is wrong: This reverses the two. Registry modules are downloaded during init; local modules are already on disk and are simply referenced in place.

Why C is wrong: It is the registry module that honours a version argument. Local modules have no releases to choose between, so supplying version there is not how they work.

Why D is wrong: Both kinds of module can define the full range of resources, data sources, variables, and outputs. The source location does not restrict what a module may contain.

During which Terraform operation are the modules named in module blocks retrieved and installed into the working directory?

• ADuring terraform plan, immediately before Terraform builds the resource graph for the run.
• BDuring terraform init, when Terraform prepares the working directory.check_circle Correct
• CDuring terraform apply, at the moment Terraform begins creating or updating resources.
• DDuring terraform validate, as Terraform checks the syntax of the configuration.

Why A is wrong: Plan assumes modules are already installed. If they are not, plan fails and asks you to run init first, because plan does not perform module retrieval.

Why B is correct: init is the initialisation step that downloads and installs child modules alongside provider plugins and backend setup, so later plan and apply runs find the module code in place.

Why C is wrong: Apply also expects modules to be present already. Retrieval happens earlier, so relying on apply to fetch modules is a misunderstanding of the workflow.

Why D is wrong: validate checks configuration correctness and needs modules already installed to do so; it does not retrieve them, and it will report an error if init has not been run.

A team has been running with a registry module pinned at 2.3.0. They edit the constraint to allow a newer release and want Terraform to download the updated module code. After changing the version constraint, which command must they run for Terraform to fetch the newer module version?

module "database" {
  source  = "acme/database/aws"
  version = "~> 2.5"
}

• Aterraform plan, because planning re-reads the module block and pulls any newer version that the updated constraint allows.
• Bterraform init -upgrade, so Terraform re-evaluates the constraint and downloads the newest permitted module version.check_circle Correct
• Cterraform get, which always upgrades installed modules to the highest version the constraint permits.
• Dterraform apply -refresh-only, which reconciles module versions in state and installs the newer release.

Why A is wrong: Plan reads already-installed modules but does not download or upgrade module code; it would run against the still-cached 2.3.0.

Why B is correct: Once a module is installed Terraform keeps the cached version until init -upgrade tells it to re-resolve constraints and fetch a newer permitted release.

Why C is wrong: terraform get installs missing modules but, like a plain init, does not upgrade an already-installed module unless the -update flag is passed.

Why D is wrong: A refresh-only apply reconciles resource state with real infrastructure and has nothing to do with downloading module code from the registry.

Inside a child module a practitioner writes an expression that references 'var.region', but 'region' is only declared as a variable in the root module, not in the child. What does Terraform do when this configuration is initialised and planned?

# modules/compute/main.tf
resource "aws_instance" "this" {
  availability_zone = "${var.region}a"
}

• AIt inherits the value from the root's 'region' variable, because child modules can read any variable declared higher up the call tree.
• BIt substitutes an empty string for the undeclared variable and continues the plan with a warning.
• CIt reads the root value at plan time only if 'region' is also exported as a root output.
• DIt fails with an error that 'var.region' is not declared, because each module has its own variable scope and must declare the variables it uses.check_circle Correct

Why A is wrong: Tempting if you assume lexical inheritance, but Terraform modules do not inherit variables from their callers.

Why B is wrong: Plausible because Terraform tolerates some unset optional inputs, but an entirely undeclared variable is an error, not a silent default.

Why C is wrong: Tempting because it mixes real concepts, but outputs expose values to callers and never make a root variable visible inside a child.

Why D is correct: Correct: variable scope is confined to the declaring module, so referencing an undeclared variable inside the child is a configuration error.

A root module needs to reference the ID of a security group that is created inside a child module named 'firewall'. The resource address inside the child is 'aws_security_group.web'. What must the practitioner add so the root can read that ID as 'module.firewall.web_sg_id'?

# modules/firewall/main.tf
resource "aws_security_group" "web" {
  name = "web"
}

• ANothing; the root can reference 'aws_security_group.web.id' directly because resources in child modules share the root namespace.
• BDeclare 'output "web_sg_id" { value = aws_security_group.web.id }' in the child module.check_circle Correct
• CDeclare 'variable "web_sg_id"' in the child module and let Terraform populate it from the created resource.
• DAdd 'output "web_sg_id"' in the root module referencing the child resource by its full address.

Why A is wrong: Tempting if you treat modules as flat, but child resources are encapsulated and cannot be addressed from the root without an output.

Why B is correct: Correct: a child exposes an internal attribute to its caller only through a named output, which the root then reads as module.<name>.<output>.

Why C is wrong: Plausible because it names the right identifier, but variables are inputs to the child, not a way to publish a computed value upward.

Why D is wrong: Tempting since an output is involved, but placing it in the root still cannot reach an encapsulated child resource that has no output of its own.