Page locked

This page is currently locked for editing by another user. You have to wait until this user finishes editing or the lock expires.
Currently locked by: 216.73.216.201,192.168.32.1
Lock expires at: 2026/07/18 17:14 (14 min)
This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== HashiCorp Terraform Associate ======

:!: __**Infrastructure as Code**__ is the practice of defining infrastructure deployments using machine-readable files that can be used to provision infrastructure in an automated fashion.

===== Infrastructure-as-Code (IaC) Concepts: =====

**Terraform** is an example of **Infrastructure-as-Code (IaC)**, and therefore HashiCorp expects that
you have a fundamental understanding of what IaC is and some of its concepts and patterns.
This exam objective is not focused specifically around Terraform itself but covers general topics
of Infrastructure-as-Code.

**Infrastructure** can be thought of as the **resources an application runs on**. Traditionally this was
composed of **servers, storage**, and **networking**. With the advent of **virtualization**, servers were
now split into both **physical** resources and **virtual** machines. Cloud providers created additional
abstractions, starting with **Infrastructure-as-a-Service (IaaS)** and moving up to **Platform-as-a-
Service (PaaS)** and **Software-as-a-Service (SaaS)**. While traditional infrastructure was deployed using
manual and cumbersome processes fraught with potential for mistakes and inconsistencies, the
various services offered by cloud providers and other vendors introduce a software-driven model of
creation and configuration.

**Infrastructure-as-Code (IaC)** is the **practice** of **defining** and **provisioning** infrastructure resources
through a **machine-readable format**. The infrastructure provisioned and managed using IaC can
include **bare-metal** servers, **virtual machines**, **networking resources**, **storage volumes**, or even
**databases** provided as a service. While IaC is often used in a cloud environment, it is not necessary
to use the cloud for IaC. As long as your infrastructure management system has a programmatic
interface, it can participate in IaC.

The format can be **declarative** (defining the desired outcome) or **imperative** (defining the process
of provisioning.) **Declarative** provisioning solutions, such as **Terraform**, are focused on the desired
end state of a deployment and rely on an **interpretation engine** to create and configure the actual
resources. **Imperative** provisioning solutions, such as a **batch script**, focus on the actual **provisioning**
process and may reference a file containing a list of settings and configuration values. The code
created for IaC may be stored in a Version Control System (VCS) to enable change tracking and
team collaboration. IaC can also be combined with other common software development practices
like **automated testing**, **deployment pipelines**, and **reusable components**.

:!: The **key point** behind Iac is that **infrastructure** is __defined__ and __provisioned__ through **machine-readable
code** and is not provisioned by hand using a portal, command line, or API. If the commands or
process is performed manually by a person, it is not IaC.

===== Advantages of IaC: =====

The advantages of using IaC can be broken down into a few key categories: **consistency**, **repeatability**, and **efficiency**.

  * By defining infrastructure as code, the deployment of that infrastructure should be **consistent** across **multiple builds** and **environments**. When the same code is used to stand up infrastructure for __staging__ and __production__, the operations team no longer has to wonder if the two environments are at parity.
  * In a **cloud** context, using the same code to deploy infrastructure in **multiple regions** assures that each region is set up **consistently**.
  * There are many **common** **components** and **deployment patterns** in infrastructure. Using IaC allows these patterns to be defined **once** and used multiple times. For example, it may be a common pattern to deploy __web servers__ for a new application. By **defining** the web server deployment in code, it can be reused by each new deployment that requires a set of web servers. Additionally, if something changes about the desired configuration of those web servers, an update of the web server deployment code can be created and pushed to each application environment.
  * Defining infrastructure as code allows operations teams to more tightly integrate with their developer counterparts. The provisioning process of infrastructure can be incorporated into the existing application development workflow, creating a consistent and repeatable process that flows through development, QA, staging, and production environments. By automating and integrating with the development team, greater levels of efficiency can be achieved.


===== Understanding Terraform’s Purpose (vs Other IaC): =====

**Terraform** is **not** the only player in town when it comes to working with Infrastructure-as-Code (IaC.) There are public cloud provider solutions, like __**CloudFormation** from AWS__ or __**Azure Resource Manager (ARM)** Templates from Microsoft__. 

Various IaC solutions all have different features and approaches to achieve the goal of automated infrastructure deployment. HashiCorp wants you to know what makes Terraform different from these other solutions.