Module registry for organization in Terraform - Step-by-Step Execution

Process Flow - Module registry for organization

Create Module Code

↓

Publish Module to Org Registry

↓

Module Available in Registry

↓

Use Module in Terraform Config

↓

Terraform Init Downloads Module

↓

Terraform Apply Uses Module

This flow shows how you create a module, publish it to your organization's registry, then use it in Terraform configurations.

Execution Sample

Terraform

terraform {
  required_providers {
    aws = { source = "hashicorp/aws" }
  }
}

module "vpc" {
  source = "app.terraform.io/org-name/vpc/aws"
  version = "1.0.0"
}

This Terraform config uses a module named 'vpc' from the organization's module registry.

Process Table

Step	Action	Input/Condition	Result/Output
1	Create module code locally	Write reusable Terraform code	Module files ready for publishing
2	Publish module	Push module to org registry with version 1.0.0	Module stored in org registry
3	Write Terraform config	Reference module source as org registry path	Config ready to use module
4	Run terraform init	Detect module source	Module downloaded from org registry
5	Run terraform apply	Use downloaded module	Resources created as defined by module
6	End	All steps complete	Infrastructure deployed using org module

💡 All steps complete, module used successfully from organization registry

Status Tracker

Variable	Start	After Step 3	After Step 4	Final
module_code	Not created	Created and published	Downloaded by terraform init	Used in terraform apply
terraform_config	Not written	Written with module source	Initialized with module	Applied to create resources

Key Moments - 3 Insights

Why do we need to publish the module to the organization registry before using it?

Because terraform init downloads modules from the registry. Without publishing, terraform cannot find or download the module (see execution_table step 2 and 4).

What does the 'source' attribute in the module block represent?

It tells Terraform where to find the module code. For organization registry modules, it uses the format 'app.terraform.io/org-name/module-name/provider' (see execution_table step 3).

What happens if the module version is not specified?

Terraform will use the latest version available in the registry, but specifying a version ensures consistent and repeatable deployments (related to step 3 in execution_table).

Visual Quiz - 3 Questions

Look at the execution table, at which step is the module code downloaded to your local machine?

A Step 3

B Step 2

C Step 4

D Step 5

💡 Hint

Check the 'Result/Output' column for step 4 in the execution_table.

According to the variable tracker, what is the state of 'terraform_config' after step 3?

A Written with module source

B Not written

C Initialized with module

D Applied to create resources

💡 Hint

Look at the 'terraform_config' row and the 'After Step 3' and 'After Step 4' columns in variable_tracker.

If you skip publishing the module (step 2), what will happen during terraform init (step 4)?

A Module downloads successfully

B Terraform init fails to find the module

C Terraform apply creates resources anyway

D Module version defaults to latest

💡 Hint

Refer to the key_moments explanation about publishing before usage.

Concept Snapshot

Module registry for organization:
- Create reusable Terraform module code
- Publish module to your organization's registry with version
- Reference module in Terraform config using org registry source
- Run 'terraform init' to download module
- Run 'terraform apply' to deploy resources
- Versioning ensures consistent deployments

Full Transcript

This visual execution shows how to use a module registry for your organization in Terraform. First, you create module code locally. Then you publish it to your organization's registry with a version number. Next, you write a Terraform configuration that references the module using the registry source path. When you run 'terraform init', Terraform downloads the module from the registry. Finally, 'terraform apply' uses the module to create infrastructure resources. The variable tracker shows the state changes of module code and Terraform config through these steps. Key moments clarify why publishing is necessary and how the source attribute works. The quiz tests understanding of when the module is downloaded, the state of the config, and consequences of skipping publishing.

Practice

1. What is the main purpose of using a module registry in Terraform for an organization?

easy

A. To share and reuse Terraform modules easily within the organization

B. To store Terraform state files securely

C. To automatically deploy infrastructure without configuration

D. To monitor cloud resource usage in real-time

Solution

1. Step 1: Understand what a module registry does

   A module registry is a place where Terraform modules are stored and shared.

2. Step 2: Identify the organizational benefit

   It allows teams to reuse modules easily, promoting consistency and saving time.

3. Final Answer:

   To share and reuse Terraform modules easily within the organization -> Option A

4. Quick Check:

   Module registry = share & reuse modules [OK]

Hint: Module registry = easy sharing of modules [OK]

Common Mistakes:

• Confusing module registry with state storage
• Thinking it automates deployment without config
• Mixing it up with monitoring tools

2. Which of the following is the correct syntax to use a module from your organization's Terraform registry?

easy

A. source = "github.com/org-name/module-name"

B. source = "app.terraform.io/org-name/module-name/aws"

C. source = "terraform.io/module-name"

D. source = "registry.terraform.io/module-name"

Solution

1. Step 1: Recall the format for organization module source

   The source for an organization's registry uses the format: app.terraform.io/org-name/module-name/provider.

2. Step 2: Match the correct option

   source = "app.terraform.io/org-name/module-name/aws" matches this format exactly, including the organization and module name.

3. Final Answer:

   source = "app.terraform.io/org-name/module-name/aws" -> Option B

4. Quick Check:

   Org registry source format = app.terraform.io/org-name/module-name/provider [OK]

Hint: Org registry source starts with app.terraform.io [OK]

Common Mistakes:

• Using GitHub URL instead of Terraform registry format
• Omitting the provider name at the end
• Using registry.terraform.io without org prefix

3. Given this Terraform module block:

module "vpc" {
  source  = "app.terraform.io/myorg/vpc/aws"
  version = "1.2.0"
}

What happens if version "1.2.0" is not available in the registry?

medium

A. Terraform will use the latest available version automatically

B. Terraform will ignore the version and use the source code locally

C. Terraform will download an empty module

D. Terraform will throw an error and stop the plan or apply

Solution

1. Step 1: Understand versioning in Terraform modules

   Terraform requires the specified version to exist in the registry to ensure consistent infrastructure.

2. Step 2: Behavior when version is missing

   If the version is not found, Terraform stops and shows an error to prevent unexpected changes.

3. Final Answer:

   Terraform will throw an error and stop the plan or apply -> Option D

4. Quick Check:

   Missing version causes error, no fallback [OK]

Hint: Missing version = error, no automatic fallback [OK]

Common Mistakes:

• Assuming Terraform uses latest version automatically
• Thinking Terraform ignores version and uses local code
• Believing Terraform downloads empty module silently

4. You wrote this module block:

module "db" {
  source = "app.terraform.io/myorg/db/aws"
  version = "1.0"
}

Terraform fails with an error about version format. What is the likely problem?

medium

A. Version should be a full semantic version like "1.0.0"

B. Source URL is missing the organization name

C. Module name "db" is invalid

D. Version attribute is not supported in module blocks

Solution

1. Step 1: Check version format requirements

   Terraform module versions must follow semantic versioning, e.g., "1.0.0".

2. Step 2: Identify the error cause

   Using "1.0" is incomplete and causes a format error.

3. Final Answer:

   Version should be a full semantic version like "1.0.0" -> Option A

4. Quick Check:

   Version format = semantic (x.y.z) [OK]

Hint: Use full semantic version (e.g., 1.0.0) [OK]

Common Mistakes:

• Using short version like 1.0 instead of 1.0.0
• Forgetting organization name in source
• Thinking version attribute is invalid

5. Your team wants to ensure all Terraform modules used from the organization registry are locked to specific versions to avoid unexpected changes. Which practice should you follow?

hard

A. Remove the version attribute and rely on Terraform to pick stable versions

B. Use the latest version without specifying version to get updates automatically

C. Specify exact module versions in the module block using the version attribute

D. Download modules manually and use local paths instead of registry

Solution

1. Step 1: Understand version locking importance

   Locking module versions prevents unexpected changes and keeps infrastructure stable.

2. Step 2: Apply version locking in Terraform

   Use the version attribute in the module block to specify exact versions from the registry.

3. Final Answer:

   Specify exact module versions in the module block using the version attribute -> Option C

4. Quick Check:

   Version attribute locks module version [OK]

Hint: Always specify exact version to lock modules [OK]

Common Mistakes:

• Using latest version without locking causes surprises
• Thinking manual download is better than registry
• Removing version attribute leads to unstable infra