Module registry for organization in Terraform - Commands & Configuration

Introduction

When you build infrastructure with Terraform, you often reuse code called modules. A module registry for your organization helps you share and manage these modules easily in one place.

When you want to share Terraform modules with your team without sending files manually.

When you want to keep your infrastructure code organized and reusable across projects.

When you want to control versions of your modules to avoid breaking changes.

When you want to discover and use modules created by your coworkers quickly.

When you want to publish modules securely within your company without exposing them publicly.

Config File - main.tf

main.tf

terraform {
  required_version = ">= 1.3.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 4.0"
    }
  }
  
  cloud {
    organization = "example-org"
  }
}

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

  cidr_block = "10.0.0.0/16"
}

provider "aws" {
  region = "us-east-1"
}

The terraform block sets the Terraform version and provider requirements.

The cloud block specifies your organization name to connect to the private module registry.

The module block uses a module from your organization's registry with a specific version.

The provider block configures AWS region for resources.

Commands

This command logs you into Terraform Cloud to authenticate and access your organization's private module registry.

Terminal

terraform login

Expected Output

Token saved to configuration file.

You are now logged in.

This command initializes your Terraform working directory, downloads the module from your organization's registry, and sets up providers.

Terminal

terraform init

Expected Output

Initializing the backend...



Initializing provider plugins...

- Finding hashicorp/aws versions matching ">= 4.0"...

- Installing hashicorp/aws v4.50.0...

- Installed hashicorp/aws v4.50.0 (signed by HashiCorp)



Initializing modules...

- vpc in .terraform/modules/vpc



Terraform has been successfully initialized!

This command applies the Terraform configuration, creating or updating infrastructure using the module from your organization's registry.

Terminal

terraform apply -auto-approve

Expected Output

module.vpc.aws_vpc.main: Creating...

module.vpc.aws_vpc.main: Creation complete after 10s [id=vpc-0abcd1234efgh5678]



Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

→

-auto-approve - Automatically approve the plan without asking for confirmation

This command shows the Terraform version and confirms that the setup is using the correct version compatible with the module registry.

Terminal

terraform version

Expected Output

Terraform v1.3.9

on linux_amd64

+ provider registry.terraform.io/hashicorp/aws v4.50.0

Key Concept

If you remember nothing else from this pattern, remember: the module registry lets your team share and reuse Terraform modules easily and safely inside your organization.

Common Mistakes

Not running 'terraform login' before using modules from the private registry

Terraform cannot authenticate to download modules from your organization's registry, causing errors.

Always run 'terraform login' once to authenticate before running 'terraform init' or 'terraform apply'.

Using incorrect module source address without the organization prefix

Terraform cannot find the module because the source path is incomplete or wrong.

Use the full source address including your organization name, like 'app.terraform.io/example-org/module-name/provider'.

Not specifying module version, leading to unexpected module updates

Terraform may use the latest module version, which could introduce breaking changes.

Always specify the module version explicitly in the module block to control updates.

Summary

Run 'terraform login' to authenticate with your organization's Terraform Cloud registry.

Use the full module source address with your organization name in your Terraform configuration.

Run 'terraform init' to download modules and providers, then 'terraform apply' to create infrastructure.

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