marc:studie:hashicorp_terraform_certified_associate
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| marc:studie:hashicorp_terraform_certified_associate [2026/05/13 20:59] – [Plugin Based Architecture] marcv | marc:studie:hashicorp_terraform_certified_associate [2026/05/14 11:01] (current) – marcv | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== HashiCorp Terraform Associate ====== | ====== 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. | :!: __**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 80: | Line 87: | ||
| < | < | ||
| - | 2 version = " | + | 2 |
| - | 3 tenant_id = var.tenant_id | + | 3 |
| - | 4 subscription = var.subscription_id 5 }</ | + | 4 |
| + | 5 }</ | ||
| * 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, | * 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, | ||
| Line 90: | Line 98: | ||
| < | < | ||
| 1 terraform { | 1 terraform { | ||
| - | 2 required_providers { | + | 2 |
| - | 3 azurerm = " | + | 3 |
| - | 4 } | + | 4 |
| 5 }</ | 5 }</ | ||
| * 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. | * 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. | ||
| Line 126: | Line 134: | ||
| 12 ... | 12 ... | ||
| 13 }</ | 13 }</ | ||
| + | |||
| + | 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. | ||
marc/studie/hashicorp_terraform_certified_associate.1778698761.txt.gz · Last modified: by marcv