Bird
Raised Fist0
Terraformcloud~5 mins

Module sources (local, registry, git) in Terraform - Time & Space Complexity

Choose your learning style10 modes available
LearnWhyDeepVisualTryChallengeProjectRecallTime
Time Complexity: Module sources (local, registry, git)
O(n)
Understanding Time Complexity

When Terraform uses modules from different sources, it needs to fetch and prepare them before use.

We want to understand how the time to get these modules grows as we add more modules or change their sources.

Scenario Under Consideration

Analyze the time complexity of fetching modules from various sources.

module "local_mod" {
  source = "./modules/local"
}

module "registry_mod" {
  source = "terraform-aws-modules/vpc/aws"
}

module "git_mod" {
  source = "git::https://github.com/example/repo.git"
}

This sequence shows modules sourced locally, from the Terraform registry, and from a Git repository.

Identify Repeating Operations

Each module source requires fetching and preparing the module code.

  • Primary operation: Download or copy module files from source locations.
  • How many times: Once per module used in the configuration.
How Execution Grows With Input

As you add more modules, Terraform fetches each one separately.

Input Size (n)Approx. Api Calls/Operations
1010 fetch operations
100100 fetch operations
10001000 fetch operations

Pattern observation: The number of fetches grows directly with the number of modules.

Final Time Complexity

Time Complexity: O(n)

This means the time to fetch modules grows linearly as you add more modules.

Common Mistake

[X] Wrong: "Fetching modules from local, registry, or git sources all take the same time regardless of number."

[OK] Correct: Each module requires a separate fetch or copy operation, so more modules mean more time.

Interview Connect

Understanding how module fetching scales helps you design efficient Terraform projects and troubleshoot slow runs.

Self-Check

"What if multiple modules share the same git repository source? How would the time complexity change?"

Practice

(1/5)
1. What does the source argument specify in a Terraform module block?
easy
A. The location where Terraform finds the module code
B. The version of Terraform to use
C. The cloud provider for the module
D. The output variables of the module

Solution

  1. Step 1: Understand the role of source in a module

    The source argument tells Terraform where to get the module code from, such as a local folder, registry, or Git repo.

  2. Step 2: Identify what source does not specify

    It does not specify Terraform version, cloud provider, or outputs; those are separate configurations.

  3. Final Answer:

    The location where Terraform finds the module code -> Option A

  4. Quick Check:

    Module source = module location [OK]
Hint: Remember: source means 'where to get the module' [OK]
Common Mistakes:
  • Confusing source with Terraform version
  • Thinking source defines outputs
  • Assuming source sets cloud provider
2. Which of the following is the correct syntax to use a local module located in a folder named modules/network?
easy
A. module "net" { source = "modules/network" }
B. module "net" { source = "registry/modules/network" }
C. module "net" { source = "git::https://example.com/network.git" }
D. module "net" { source = "network" }

Solution

  1. Step 1: Identify local module source syntax

    Local modules use a relative or absolute path as the source. Here, "modules/network" is a relative path.

  2. Step 2: Check other options for correctness

    module "net" { source = "registry/modules/network" } uses registry syntax incorrectly; module "net" { source = "git::https://example.com/network.git" } is for Git sources; module "net" { source = "network" } lacks the folder path.

  3. Final Answer:

    module "net" { source = "modules/network" } -> Option A

  4. Quick Check:

    Local module source = folder path [OK]
Hint: Local modules use folder paths as source [OK]
Common Mistakes:
  • Using registry or git syntax for local modules
  • Omitting folder path in source
  • Confusing source with module name
3. Given this module block:
module "web" {
  source = "git::https://github.com/example/terraform-web.git"
  version = "v1.0.0"
}

What will Terraform do when you run terraform init?
medium
A. Download the module from the local folder named terraform-web
B. Download the module from the Terraform Registry
C. Clone the Git repository at the given URL and checkout version v1.0.0
D. Fail because version is not supported for Git sources

Solution

  1. Step 1: Understand Git source syntax in Terraform

    The source starting with "git::" tells Terraform to clone a Git repository from the URL.

  2. Step 2: Interpret the version argument with Git sources

    The version here refers to a Git tag or branch to checkout, so Terraform will checkout "v1.0.0" after cloning.

  3. Final Answer:

    Clone the Git repository at the given URL and checkout version v1.0.0 -> Option C

  4. Quick Check:

    Git source + version = clone and checkout tag [OK]
Hint: Git source means clone repo; version is Git tag/branch [OK]
Common Mistakes:
  • Thinking version is Terraform Registry version
  • Assuming source is local folder
  • Believing version is unsupported for Git
4. You wrote this module block:
module "db" {
  source = "git::https://github.com/example/terraform-db.git"
  version = "1.0.0"
}

When running terraform init, you get an error. What is the likely cause?
medium
A. The module name 'db' is invalid
B. The version should be prefixed with 'v' like 'v1.0.0' to match Git tags
C. The source URL must be a local path for modules
D. Git URLs cannot be used as module sources

Solution

  1. Step 1: Check Git tag naming conventions

    Git tags often start with 'v' (e.g., 'v1.0.0'). If the tag is named with 'v', specifying '1.0.0' causes a mismatch.

  2. Step 2: Verify other options for errors

    Git URLs are valid sources; local path is not required; module name 'db' is valid.

  3. Final Answer:

    The version should be prefixed with 'v' like 'v1.0.0' to match Git tags -> Option B

  4. Quick Check:

    Git version tag must match exact Git tag name [OK]
Hint: Match version exactly to Git tag name (often starts with 'v') [OK]
Common Mistakes:
  • Omitting 'v' prefix in version for Git tags
  • Thinking Git URLs are invalid module sources
  • Assuming module names have strict rules
5. You want to reuse a module from the Terraform Registry named hashicorp/aws with version 4.0.0. Which is the correct module block to use?
hard
A. module "aws_module" { source = "git::https://github.com/hashicorp/aws.git" version = "4.0.0" }
B. module "aws_module" { source = "registry/hashicorp/aws" version = "4.0.0" }
C. module "aws_module" { source = "./hashicorp/aws" version = "4.0.0" }
D. module "aws_module" { source = "hashicorp/aws" version = "4.0.0" }

Solution

  1. Step 1: Identify Terraform Registry module source syntax

    Modules from the Terraform Registry use the format "namespace/module" as the source, e.g., "hashicorp/aws".

  2. Step 2: Check other options for correctness

    module "aws_module" { source = "git::https://github.com/hashicorp/aws.git" version = "4.0.0" } uses Git URL which is incorrect for Registry modules; module "aws_module" { source = "./hashicorp/aws" version = "4.0.0" } uses local path; module "aws_module" { source = "registry/hashicorp/aws" version = "4.0.0" } uses invalid prefix "registry/".

  3. Final Answer:

    module "aws_module" { source = "hashicorp/aws" version = "4.0.0" } -> Option D

  4. Quick Check:

    Registry modules use "namespace/module" source format [OK]
Hint: Registry modules use "namespace/module" as source [OK]
Common Mistakes:
  • Using Git URL for Registry modules
  • Adding extra prefixes like 'registry/'
  • Using local paths for Registry modules
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard