Terraform Associate Interact with Terraform Modules: 50 practice questions

12 of the 50 Interact with Terraform Modules questions in the Certsqill Terraform Associate bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for Terraform Associate? Take the free 5-min readiness check →

1. Local filesystem path: What type of module source is this?

1. Local filesystem path — the module is in a subdirectory relative to the calling configuration ✓

   Correct. Sources beginning with ./ or ../ are local filesystem paths resolved relative to the calling module's directory.
2. Terraform Registry module referenced with the standard namespace/module/provider address format

   Incorrect. Registry modules use the namespace/module/provider form with no leading ./; the ./ prefix explicitly denotes a local path.
3. Git repository source where the module is cloned from a remote GitHub repository over SSH

   Incorrect. Git sources start with git:: or github.com/; a leading ./ means the local filesystem, not a clone.
4. HTTP URL source where the module archive is downloaded from a remote web server endpoint

   Incorrect. HTTP sources start with https://; the ./ prefix indicates a local directory instead.

Module sources starting with `./` or `../` reference local filesystem directories — Terraform reads them directly without downloading.

2. In the module block: How is the input passed?

1. By setting TF_VAR_vpc_cidr=10.0.0.0/16 as an exported environment shell variable

   Incorrect. TF_VAR_ environment variables set root-module variables only; they do not populate a child module's variables, which must come through the module block.
2. In the module block: module "network" { source = "./network"; vpc_cidr = "10.0.0.0/16" } ✓

   Correct. Inputs are passed to a child module as arguments inside its module block, where each declared child variable becomes an argument.
3. By defining the variable inside a terraform.tfvars file placed in the child module directory

   Incorrect. terraform.tfvars is read only for the root module; child module inputs must be passed via module-block arguments.
4. Child modules automatically inherit all input variables from the parent module scope

   Incorrect. Modules are encapsulated and do not inherit parent variables automatically; every input must be passed explicitly.

Child module inputs are passed as arguments in the parent's module block — each variable in the child becomes an argument the parent can set.

3. module.vpc.subnet_id references the subnet_id output: How does the parent module reference this output value?

1. module.vpc.output.subnet_id reads the exported subnet_id from the module

   Incorrect. The reference path has no .output. segment; the correct form is module.<name>.<output> with nothing in between.
2. var.subnet_id automatically exposed as a child module variable

   Incorrect. Child outputs do not become parent variables; they must be referenced explicitly through module.<name>.<output>.
3. module.vpc.subnet_id references the subnet_id output of the vpc module ✓

   Correct. A child module's outputs are read in the parent as module.<module_name>.<output_name>, so module.vpc.subnet_id returns the vpc module's subnet_id.
4. output.vpc.subnet_id reads the subnet_id output via the output namespace

   Incorrect. output. is not a valid namespace in expressions; the correct prefix is module.<module_name>.

Child module outputs are accessed as `module.<module_name>.<output_name>` — e.g., `module.vpc.subnet_id`.

4. source = "git: Which module source format is correct?

1. source = "github.com/company/terraform-modules//aws/modules/networking"; version = "v2.3.0"

   Incorrect. The `version` argument only works with Terraform Registry sources, not Git sources. For a Git source the tag is pinned with `?ref=` inside the URL, not a separate `version` argument.
2. source = "git::[email protected]/company/terraform-modules.git//networking#v2.3.0"

   Incorrect. Terraform does not recognize a `#v2.3.0` URL fragment for version selection; a Git ref must be supplied through `?ref=v2.3.0` even when using an SSH-style source.
3. source = "https://github.com/company/terraform-modules.git//networking&tag=v2.3.0"

   Incorrect. There is no `tag` query parameter, and without the `git::` prefix Terraform treats this as a plain HTTP archive download rather than a Git checkout; pin the tag with `?ref=`.
4. source = "git::https://github.com/company/terraform-modules.git//networking?ref=v2.3.0" ✓

   Correct. Git sources use the `git::` prefix with the repository URL. The `//` separator indicates a subdirectory path, and `?ref=` specifies a branch, tag, or commit SHA for version pinning.

Git module sources use `git::` prefix with `?ref=` for branch/tag/commit pinning — the `//` separator points to a subdirectory within the repository.

5. No, modules are encapsulated. The parent must explicitly: Can a child module access `var.region` directly?

1. No, modules are encapsulated. The parent must explicitly pass the value as a module block argument ✓

   Correct. Terraform modules are isolated, so a child module cannot read parent variables directly. The parent must pass values explicitly via module block arguments.
2. Only if the child module declares the variable and the root sets `scope = "inherited"` on it

   Incorrect. There is no `scope` argument on Terraform variable blocks; variable scope is always module-local and cannot be widened by any declaration.
3. Yes, because child modules in the same repository automatically inherit every variable declared in the root

   Incorrect. Being in the same repository is irrelevant; a child module has its own isolated variable scope regardless of where its files physically live.
4. Yes, any variable marked `sensitive = false` becomes readable from every nested child module below it

   Incorrect. The `sensitive` flag only controls output redaction; it never exposes a variable across module boundaries. Cross-module sharing always requires explicit argument passing.

Terraform modules are fully encapsulated — child modules cannot access parent variables. All inputs must be explicitly passed via module block arguments.

6. source = "terraform-aws-modules/eks/aws": Which configuration achieves this?

1. source = "terraform-aws-modules/eks/aws/19"; version = "latest"

   Incorrect. Embedding the version in the source path is invalid for Registry modules, and `version = "latest"` is not a valid constraint. Use an operator such as `~> 19.0`.
2. source = "terraform-aws-modules/eks/aws"; version = "~> 19.0" ✓

   Correct. The `version` argument on a module block accepts version constraints. `~> 19.0` allows >=19.0, <20.0, permitting minor updates within major version 19.
3. source = "terraform-aws-modules/eks/aws"; version = ">= 19, 20"

   Incorrect. The comma form `>= 19, 20` is not valid HCL constraint syntax. To allow minor-only updates within major 19, use the pessimistic operator `~> 19.0`.
4. source = "terraform-aws-modules/eks/aws"; pin = "19.x"

   Incorrect. There is no `pin` argument on module blocks. Version pinning uses the `version` argument with a constraint operator such as `~> 19.0`.

Registry module version pinning uses the `version` argument with constraint operators — `version = "~> 19.0"` allows 19.x updates but prevents version 20+.

7. The directory where Terraform commands are executed: When a team runs `terraform plan` from `/projects/infra/`

1. The directory defined in the `root_module` argument of the Terraform configuration

   Incorrect. There is no `root_module` configuration argument in Terraform. The root module is implicitly the current working directory.
2. The directory specified in the TERRAFORM_ROOT environment variable

   Incorrect. There is no TERRAFORM_ROOT environment variable. The root module is the current working directory when Terraform runs.
3. The directory where Terraform commands are executed (/projects/infra/) ✓

   Correct. The root module is always the directory where Terraform CLI commands are run. All .tf files in that directory form the root module.
4. The directory containing the first main.tf file in the file tree

   Incorrect. main.tf is a convention, not a requirement. The root module is determined by the directory where CLI commands run — not by file names.

The root module is always the directory where Terraform CLI commands are executed — all .tf files in that directory make up the root module.

8. Local filesystem path: Which of the following are valid Terraform module source types?

Select two. More than one option is correct — every correct one is ticked below.

1. Local filesystem path (e.g., ./modules/vpc) ✓

   Correct. Local filesystem paths (starting with ./ or ../) are a valid module source type — Terraform reads the module directly from the local directory.
2. Terraform state file (e.g., ./terraform.tfstate)

   Incorrect. State files are not module sources — they store infrastructure state, not reusable module code.
3. Terraform Registry (e.g., hashicorp/consul/aws) ✓

   Correct. The Terraform Registry is a valid module source — public modules are freely available at registry.terraform.io.
4. CloudFormation template (e.g., aws://cloudformation/template)

   Incorrect. CloudFormation templates are AWS-specific and are not valid Terraform module sources.

Valid module sources include: Terraform Registry, local filesystem paths, Git repositories, Mercurial repositories, HTTP URLs, S3 buckets, and GCS buckets.

9. In the ec2 module block: How should the root module wire `module.vpc`'s output to `module.ec2`'s input?

1. In the ec2 module block: `vpc_id = module.vpc.vpc_id` ✓

   Correct. The root module passes module.vpc's output to module.ec2 as a module argument. This creates an implicit dependency — Terraform applies module.vpc before module.ec2.
2. In the vpc module: `depends_on = [module.ec2]`

   Incorrect. depends_on should point from the dependent to the dependency — ec2 depends on vpc, not the other way. Also, depends_on between modules goes in the consuming module block.
3. In the ec2 module: `variable "vpc_id" { default = module.vpc.vpc_id }`

   Incorrect. Variable defaults cannot reference other modules — defaults must be literal values or expressions using variables only. Module references belong in the parent's module block.
4. Both modules can access shared outputs through the root module's global namespace automatically

   Incorrect. There is no automatic global namespace sharing between sibling modules — all values must be explicitly passed through the parent.

The root module passes module outputs to sibling module inputs via module block arguments — `vpc_id = module.vpc.vpc_id` in the ec2 module block creates the dependency chain.

10. terraform-aws-vpc: For a VPC module on AWS, what is the correct repository name?

1. terraform-vpc-aws

   Incorrect. The convention is `terraform-<provider>-<name>` where the provider comes second, so it must be `terraform-aws-vpc`, not `terraform-vpc-aws`.
2. terraform-aws-vpc ✓

   Correct. Terraform Registry modules must live in GitHub repositories named `terraform-<PROVIDER>-<NAME>`. For an AWS VPC module that is terraform-aws-vpc.
3. vpc-terraform-aws

   Incorrect. The repository name must start with `terraform-`. Leading with the module name is not valid for the Terraform Registry naming convention.
4. aws-terraform-vpc

   Incorrect. The naming convention requires `terraform-` as the prefix, not the provider name; the correct format is `terraform-aws-vpc`.

Terraform Registry modules must follow `terraform-<provider>-<name>` naming — e.g., `terraform-aws-vpc`, `terraform-google-network`.

11. The root module configures a provider alias for eu-west-1: How can the child module use a different region wit

1. The root module sets `AWS_REGION=eu-west-1` in a `locals` block that the child module reads automatically at plan time

   Incorrect. A `locals` block cannot set process environment variables, and environment variables apply globally rather than per module call. Provider aliases via the `providers` argument are the correct mechanism.
2. The child module inherits the parent's default provider, so it creates the eu-west-1 resources without any extra wiring

   Incorrect. The inherited default provider is configured for us-east-1, so resources land there. Reaching eu-west-1 requires passing an aliased provider explicitly.
3. The root module configures a provider alias for eu-west-1 and passes it to the child using the `providers` argument ✓

   Correct. The `providers` argument in the module block maps a provider alias from the calling module to the provider configuration the child module expects.
4. The child module adds a nested `provider { region = "eu-west-1" }` block inside each of its resource blocks

   Incorrect. Provider blocks are not valid inside resource blocks. Providers are configured at the module level and referenced by resources, not embedded within them.

The `providers` argument on a module block passes specific provider configurations (including aliases) to child modules, enabling different regions per child module.

12. Avoid hardcoding values and use input variables for all: Which of the following is a best practice for designi

1. Embed a provider block with hardcoded access keys inside the module so it authenticates the same way everywhere

   Incorrect. Modules should never include provider blocks with credentials; providers are configured by the calling module. Hardcoded credentials in a module are a serious security violation.
2. Pin every resource to one specific AWS region inside the module so its behavior stays identical across deployments

   Incorrect. Hardcoding a region defeats reusability. The region should be an input variable or inherited from the caller's provider configuration.
3. Build one large module that provisions the entire application stack so all resources are managed together

   Incorrect. Monolithic modules are hard to reuse and maintain. Modules should focus on a single logical component such as a VPC, database, or compute tier.
4. Avoid hardcoding values and use input variables for all configuration that may differ between environments ✓

   Correct. Reusable modules should be parameterized with input variables for any value that varies between use cases, such as environment names, instance sizes, region, and tags.

Good modules avoid hardcoded values — they use input variables for all configurable aspects, making them reusable across environments, regions, and teams.

Other Terraform Associate domains

• Understand Terraform Basics — 197 questions →
• Implement and Maintain State — 77 questions →
• Use and Apply the Terraform Workflow — 49 questions →
• Understand Infrastructure as Code (IaC) Concepts — 45 questions →
• Understand Terraform's Purpose (vs Other IaC) — 40 questions →
• All 495 Terraform Associate questions →