Differences

This shows you the differences between two versions of the page.

--- marc:studie:hashicorp_terraform_certified_associate [2026/05/13 10:28] – [State:] marcv
+++ marc:studie:hashicorp_terraform_certified_associate [2026/05/14 11:01] (current) – marcv
@@ Line 1: / Line 1: @@
 ====== HashiCorp Terraform Associate ======
+FIXME
+Needed for terraform to provision on AWS:
+The Terraform CLI (1.2.0+) installed.
+The AWS CLI installed.
+An AWS account and associated credentials that allow you to create resources in the us-west-2 region, including an EC2 instance, VPC, and security groups.
 :!: __**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.
@@ Line 71: / Line 78: @@
   - **Collaboration:** State keeps track of the version of an applied configuration, and it supports the locking of state during updates. Combined with the storage of state in a remote, shared location, teams are able to collaborate on deployments without overwriting each other’s work.
+===== Providers =====
+A **provider** is an executable plug-in that contains the code necessary to interact with the **API of the service** it was written for. Typically this includes a way to authenticate to a service, manage resources, and access data sources.
+:!: Providers can be explicitly **defined** within a configuration, or **implied** by the presence of a resource or data source that uses the provider! The actual arguments in a provider block vary depending on the provider, but all providers support the meta-arguments of **version** and **alias**.
+Example of an Azure provider block:
+<code>1 provider azurerm {
+     version = "=1.41.0"
+     tenant_id = var.tenant_id
+     subscription = var.subscription_id
+}</code>
+  * In the case of the Azure provider, the authentication information could be supplied through an **environment variable** or **cached credentials** from the Azure CLI. The general best practice is to __avoid hard-coding secret information, like credentials,__ into the Terraform configuration.
+  * The version argument is used to **constrain** the provider to a **specific** version or a **range** of versions in order to prevent downloading a new provider that may possibly contain breaking changes. If the version isn’t specified, Terraform will automatically download the **most recent provider** during initialization.
+  * While you can specify the version of the provider in the provider block, HashiCorp recommends that you create a special //**__required_providers__**// block for Terraform configuration as follows:
+<code>
+terraform {
+     required_providers {
+         azurerm = "=1.41.0"
+     }
+}</code>
+  * Rather than setting the version of a provider for each instance of that provider, the **required_providers** block sets it for all instances of the provider, including child modules. Using the required_providers block makes it simpler to update the version on a complex configuration.
+  * There are multiple arguments for specifying the version number. It’s probably a good idea to know these:
+    * >= 1.41.0 is greater than or equal to the version.
+    * <= 1.41.0 is less than or equal to the version.
+    * ∼> 1.41.0 this one is funky. It means any version in the 1.41.X range.
+    * >= 1.20, <= 1.41 is any version between 1.20 and 1.41 inclusive.
+:!: One of the more common arguments is **∼>** which is meant to keep you on the same **major** version, while still allowing for **minor** version updates. For instance, let’s say there’s major change coming to the Azure provider in version 2.0. By setting the version to ∼>1.0, you would allow all version 1 updates that come down while still blocking the big 2.0 release.
+===== Plugin Based Architecture =====
+  * Terraform is provided as a **single binary** that includes **core components** required to parse and deploy Terraform configurations. What is does **not** include is the necessary code to interact with various providers and provisioners. That code is supplied via **plugins**. Each plugin is executed as a **separate process** communicating with the core Terraform binary using an **RPC** interface.
+  * Plugins keep the Terraform binary relatively small, lowers the potential attack surface, and simplifies debugging of core Terraform code. Allowing providers and provisioners to develop their plugins separately creates a firm delineation between what Terraform is meant to do and the plugins.
+===== Using Multiple Providers =====
+Even the most basic configurations will likely use multiple different providers. Let’s take the following configuration as an example:
+<code>
+provider "aws" {
+     region = "us-east-1"
+}
+resource "random_integer" "rand" {
+     min = 10000
+     max = 99999
+}
+resource "aws_s3_bucket" "bucket" {
+     name = "unique-name-${random_integer.rand.result}"
+     ...
+}</code>
+In this configuration we have already used two separate providers to create a single S3 bucket. The
+Random provider gives us a random integer for naming the bucket and the AWS provider gives us
+the S3 bucket resource. When using a provider it can be explicitly defined in a provider block, or
+implied by the presence of a resource that uses the provider.