How to Ace the TERRAFORM: HashiCorp Certified: Terraform Associate

Question 1 · Infrastructure as Code (IaC) with Terraform

Your organization needs to deploy identical infrastructure across AWS, Azure, and GCP without rewriting code for each cloud provider. Which Terraform approach best enables this multi-cloud strategy?

• Use provider aliases and variables to abstract cloud-specific differences, allowing the same module to work across multiple cloud providers
• Create separate Terraform configurations for each cloud provider and manually synchronize changes across all three
• Use cloud-specific CLI tools for each provider instead of Terraform to maintain provider-native configurations
• Store infrastructure definitions in JSON format rather than HCL to ensure cloud compatibility

Correct answer: Use provider aliases and variables to abstract cloud-specific differences, allowing the same module to work across multiple cloud providers

Terraform's provider abstraction layer and variable system allow you to write cloud-agnostic modules that can deploy to multiple providers by simply changing variable values or provider configurations. Option B is inefficient and error-prone, while C and D contradict Terraform's core design principles of using HCL and provider plugins.

Question 2 · Terraform Basics

You need to provision resources across AWS, Azure, and Google Cloud in a single Terraform configuration. What is the primary mechanism that enables this capability?

• Using multiple provider blocks configured with different cloud credentials
• Creating separate Terraform projects for each cloud provider
• Using remote state backends to synchronize across cloud providers
• Defining all resources in a single module without provider specification

Correct answer: Using multiple provider blocks configured with different cloud credentials

Terraform providers are plugins that enable interaction with specific platforms. Multiple provider blocks allow you to authenticate and manage resources across different cloud platforms in a single configuration. Option B is inefficient, Option C manages state but doesn't enable multi-cloud provisioning, and Option D won't work because resources must be associated with providers.

Question 3 · Core Terraform Workflow

You are initializing a new Terraform project in a directory that will be shared across your team. Which command should you run first to set up the working directory with necessary plugins and backend configuration?

• terraform init
• terraform plan
• terraform validate
• terraform apply

Correct answer: terraform init

terraform init is the first step in the Terraform workflow and initializes the working directory by downloading provider plugins, setting up the backend, and preparing the environment. While terraform validate checks syntax, it cannot run until init has completed and providers are available.

Question 4 · Terraform Configuration

You need to reference the IP address of an AWS EC2 instance created in your configuration from another resource. The instance resource is named 'web_server'. Which syntax correctly retrieves this attribute?

• aws_instance.web_server.private_ip
• resource.aws_instance.web_server.private_ip
• aws_instance[web_server].private_ip
• data.aws_instance.web_server.private_ip

Correct answer: aws_instance.web_server.private_ip

Resource attributes in Terraform are referenced using the syntax resource_type.resource_name.attribute. Option B is incorrect because 'resource' is not part of the reference syntax. Option D refers to data sources, not resources. Option C uses incorrect bracket syntax for referencing resource attributes.

Question 5 · Terraform Modules

You need to use a module stored in a Git repository with a specific version tag. Which source syntax should you use in your module block?

• source = "git::https://github.com/example/repo.git//modules/vpc?ref=v1.0.0"
• source = "[email protected]:example/repo.git//modules/vpc" version = "v1.0.0"
• source = "github.com/example/repo/modules/vpc" version = "1.0.0"
• source = "git::https://github.com/example/repo.git" tag = "v1.0.0"

Correct answer: source = "git::https://github.com/example/repo.git//modules/vpc?ref=v1.0.0"

The correct syntax for Git sources uses the git:: prefix with the repository URL, a double slash (//) to specify the subdirectory path, and the ref parameter for version control. Option B incorrectly uses a separate version argument outside the source string, and option C omits the git:: prefix which is required for Git-based sources.