Gain insights into Infrastructure as Code with Terraform, sharpen your skills, and prepare for the HashiCorp Terraform Associate certification in a cloud-agnostic way.

HashiCorp Terraform Certified Associate Preparation Guide.png

Terraform_e.tar.gz

access_key_id

secret_access_key

init

validate

config

needed-copy

not-needed-copy

needed-copy-copy

This course is designed to help learners obtain the Terraform Associate certification from HashiCorp. 

You’ve likely picked up this course because you dabbled in Terraform as a hobbyist or in a
development environment, and you’re excited about the possibilities of deploying Infrastructure 
as Code (IaC). It will enable you to sharpen your skills and prove your knowledge with a certification from HashiCorp. Terraform is an amazing tool to deploy Infrastructure as Code in a cloud-agnostic way. We’re excited to share our accumulated knowledge with you through this course.

HashiCorp Terraform Certified Associate Preparation Guide

# What is a Terraform module?

A Terraform module is simply a configuration that defines inputs, resources, and outputs. All are optional! When we create a set of `tf` or `tf.json` files in a directory, that’s a module. The main configuration we’re working with is the root module, and it can invoke other modules to create resources.

Modules have a hierarchical structure,  where the root module invokes a child module, which in turn can invoke another child module. Consider a root module that invokes a child module (`lb-vms`) to create a load-balanced cluster of Azure virtual machines. The `lb-vms` module may invoke a `vnet` module to create the necessary VNet and subnets for the load-balanced cluster. If we were to use `terraform state list`, we’d see a resource address for the subnet like `module.lb-vms.module.vnet.azurerm_subnet.subnet[0]`.

Modules are invoked by using the module script block keyword and applying a name label, written like module `<name_label> {}`.

In Terraform jargon, the `module` invoking the module code block is called the **calling module**, and the module being invoked is referred to as the **child module**. 

# Module source options

To use a module, Terraform needs to know where to find the files it consists of. The `source` argument in the `module` block defines where the module files can be found.

The actual files can be stored in a number of locations:

* [Local paths](https://www.terraform.io/docs/modules/sources.html#local-paths)
* [Terraform Registry](https://www.terraform.io/docs/modules/sources.html#terraform-registry)
* [GitHub](https://www.terraform.io/docs/modules/sources.html#github)
* [Bitbucket](https://www.terraform.io/docs/modules/sources.html#bitbucket)
* Generic [Git](https://www.terraform.io/docs/modules/sources.html#generic-git-repository), [Mercurial](https://www.terraform.io/docs/modules/sources.html#generic-mercurial-repository) repositories
* [HTTP URLs](https://www.terraform.io/docs/modules/sources.html#http-urls)
* [S3 buckets](https://www.terraform.io/docs/modules/sources.html#s3-bucket)
* [GCS buckets](https://www.terraform.io/docs/modules/sources.html#gcs-bucket)

> The Terraform Registry, in particular, is important to highlight. On the publicly available Terraform Registry, found at [registry.terraform.io](https://registry.terraform.io/), there are verified modules maintained by third-party vendors. There are verified modules for common cloud components like an AWS VPC or an Azure AKS cluster. Because they’re maintained and verified by the vendors, it’s likely that the module will function as expected.

If the source is a remote destination, Terraform copies the files to the local `.terraform` directory of the root module when `terraform init` is run. We can also use `terraform get` to retrieve the modules separately from the initialization routine.

When we’re trying to determine where to store modules we’re writing, HashiCorp’s recommendation is to store modules that are tightly coupled with the configuration locally. If a module is a reusable component that other teams might leverage, then it should be stored in a shared location, either public or private.

# Key takeaways

Modules are reusable configurations that can be called by a root module or other child modules. The source for the module can be the local filesystem or a remote repository, including the Terraform Registry that has verified modules from third-party vendors.


Learn about the Terraform module and its source options.


Introduction to the Course

Introduction to Infrastructure as Code

Basics of Terraform

Outside the Workflow: Using the Terraform CLI

Terraform Modules

Navigate Terraform Workflow

Implement and Maintain State

Read, Generate, and Modify Configuration

Understand Terraform Enterprise Capabilities

Conclusion

Module Source Options

What is a Terraform module?