Free Terraform Associate (004) Practice Questions: Terraform Fundamentals

Topic snapshot

Sample questions

These are original IT Mastery practice questions aligned to this topic area. They are not official HashiCorp questions, copied live-exam content, or exam dumps. Use them to preview question style and explanation depth before continuing with topic drills, mixed sets, and timed mocks in IT Mastery.

Question 1

Topic: Terraform Fundamentals

Which statement best describes what terraform init does?

Options:

• A. It initializes the working directory, installs required providers, and prepares the configuration for plan or apply.

• B. It creates an execution plan that shows the proposed infrastructure changes.

• C. It provisions the infrastructure immediately and writes the resulting state.

• D. It checks the configuration for syntax errors and formatting problems.

Best answer: A

Explanation: terraform init is the setup step for a Terraform working directory. It installs required providers and initializes the directory so Terraform can later run plan or apply against that configuration.

The core concept is Terraform workflow setup. You run terraform init first in a new or changed working directory so Terraform can prepare the local environment for later commands. That preparation includes installing the required providers and initializing the working directory metadata Terraform needs before planning or applying.

terraform init does not decide what changes will occur or create infrastructure. Those actions belong to later workflow commands:

• terraform plan evaluates the configuration and shows proposed changes.
• terraform apply performs the approved changes.
• terraform validate checks whether the configuration is syntactically valid.

A useful way to remember it is: init prepares, plan previews, and apply executes.

• Validation confusion mixes up init with terraform validate or terraform fmt; those commands check configuration quality, not working directory setup.
• Planning confusion describes terraform plan, which compares configuration to state and shows proposed changes.
• Execution confusion describes terraform apply, which makes real infrastructure changes and updates state.

Question 2

Topic: Terraform Fundamentals

A team reuses the same Terraform root module in dev and prod HCP Terraform workspaces. Each workspace must use different AWS regions and credentials, but the resource blocks should stay unchanged. They also want provider version constraints managed separately from runtime settings. What is the best next change?

Options:

• A. Add an aws provider block using variables

• B. Put region and credentials in required_providers

• C. Set HCP Terraform workspace variables only

• D. Configure region and credentials in the backend

Best answer: A

Explanation: Provider-specific runtime settings belong in a provider block, not in the terraform or backend blocks. Using input variables lets each HCP Terraform workspace supply different region and credential values while keeping the same resource blocks and leaving provider version constraints in required_providers.

Terraform separates provider installation requirements from provider runtime configuration. The terraform block with required_providers selects the provider source and version, but the provider block sets provider-specific values such as region, endpoint, and authentication-related inputs. In a reusable root module, those settings are commonly assigned from input variables so each HCP Terraform workspace can provide its own values without editing resource blocks.

• required_providers manages provider source and version constraints.
• provider manages region, endpoint, and auth inputs.
• backend manages where Terraform stores state.

Setting workspace variables is useful, but they only affect behavior when the configuration references them, such as from a provider block.

• Variables alone setting workspace variables by itself fails because Terraform must reference them in configuration before they affect provider behavior.
• Wrong block placing region and credentials in required_providers fails because that block only declares provider source and version constraints.
• State confusion using the backend block is incorrect because it configures state storage, not provider region or authentication.

Question 3

Topic: Terraform Fundamentals

A cloud engineer clones this configuration into a new local working directory and has not run Terraform there before.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }

  backend "s3" {
    bucket = "team-tf-state"
    key    = "network/dev.tfstate"
    region = "us-east-1"
  }
}

Before they run terraform plan, what is the best next step?

Options:

• A. Run terraform init to install providers and initialize the directory

• B. Run terraform validate to install dependencies and verify the backend

• C. Run terraform fmt to initialize the backend and provider versions

• D. Run terraform plan to download providers and create the execution plan

Best answer: A

Explanation: terraform init is the first command for a new working directory. It installs required providers, initializes the configured backend, and prepares local Terraform metadata so plan or apply can run.

terraform init prepares a Terraform working directory before normal operations. In this example, Terraform must read the required_providers block to install the AWS provider and read the backend "s3" block to initialize remote state settings. It also creates local working data, such as the .terraform directory, and records dependency information needed for later commands.

• Install required providers
• Initialize the configured backend
• Prepare the directory for terraform plan and terraform apply

Commands like plan and validate are useful later, but they do not replace initialization.

• The option claiming terraform validate installs dependencies is wrong because validation checks configuration correctness; it does not initialize providers or the backend.
• The option claiming terraform plan downloads providers is wrong because planning depends on an already initialized working directory.
• The option claiming terraform fmt initializes Terraform is wrong because formatting only adjusts file layout and style.

Question 4

Topic: Terraform Fundamentals

A team runs Terraform in HCP Terraform so plans are reviewed before apply. Most resources must stay in us-west-2, but a reusable child module named dr must create only its resources in us-east-1.

provider "aws" {
  region = "us-west-2"
}

provider "aws" {
  alias  = "dr"
  region = "us-east-1"
}

What is the best next configuration choice?

Options:

• A. Set provider = aws.dr directly on the module block

• B. Create a separate HCP Terraform workspace for the DR module

• C. Add a default provider "aws" block inside the child module

• D. Pass the alias to the module with providers = { aws = aws.dr }

Best answer: D

Explanation: A child module normally inherits the caller’s default provider configuration. Because the default aws provider points to us-west-2, the module must be given the aliased aws.dr configuration explicitly with the module providers argument.

The key concept is provider inheritance. If you do nothing, a child module uses the root module’s default provider configuration, which would send its resources to us-west-2 here. When only one module must use a different region or endpoint, define an aliased provider in the root module and pass it to that module explicitly.

module "dr" {
  source    = "./modules/dr"
  providers = { aws = aws.dr }
}

This keeps provider configuration centralized in the root module, preserves module reusability, and still fits the normal HCP Terraform plan-and-review workflow. The closest trap is confusing module syntax with resource syntax.

• Wrong meta-argument using provider = aws.dr applies to resources, not module blocks.
• Less reusable putting a provider block inside the child module makes the module harder to reuse across callers and environments.
• Unnecessary workspace split creating another HCP Terraform workspace changes state and workflow when explicit provider mapping already solves the requirement.

Question 5

Topic: Terraform Fundamentals

A Terraform configuration contains the following block:

resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = "t3.micro"
}

Which Terraform component understands the aws_instance resource type and implements how to manage it?

Options:

• A. The root module

• B. The AWS provider plugin

• C. Terraform core

• D. The configured backend

Best answer: B

Explanation: Terraform core handles the overall workflow, state graph, and execution planning, but it does not contain cloud-specific resource logic. A provider plugin is the component that knows what aws_instance means and how to manage it.

Terraform separates responsibilities between core and providers. Terraform core reads configuration, builds the dependency graph, creates plans, and coordinates state and execution. Provider plugins extend Terraform with resource types and data sources for a specific platform.

In this case, aws_instance is an AWS resource type, so the AWS provider plugin is the component that understands its schema and knows how to call AWS APIs to create, read, update, or delete it. Terraform core orchestrates the process, but it does not natively understand provider-specific resource types. Backends store and manage state, and modules organize configuration for reuse.

A good rule: core manages Terraform behavior; providers manage platform-specific resources.

• Terraform core is tempting because it runs plan and apply, but it does not define cloud-specific resource types.
• Backend confusion fails because a backend controls where state is stored and how it is accessed, not resource implementation.
• Module confusion fails because a root module is just configuration structure; it can use resource types but does not implement them.

Question 6

Topic: Terraform Fundamentals

Which Terraform concept is the plugin-based integration Terraform uses to communicate with external APIs, manage resources, and read data sources?

Options:

• A. Backend

• B. Data source

• C. Module

• D. Provider

Best answer: D

Explanation: A provider is Terraform’s plugin integration for a platform or service. Terraform uses providers to call external APIs so it can create, read, update, and delete resources and read data sources defined in configuration.

A provider is Terraform’s integration plugin for a target platform or service, such as a cloud, SaaS tool, or other API-driven system. After terraform init installs the required providers, Terraform uses them during planning and applying to translate HCL configuration into API calls. The provider contains the logic for resource operations like create, read, update, and delete, and it also supports data source reads. Terraform core handles the workflow and dependency graph, but the provider knows how to talk to the external system. That is why providers are the bridge between Terraform configuration and real infrastructure or external data.

• Backend stores state remotely or locally and may support locking, but it does not perform API operations against managed services.
• Module is a reusable package of Terraform configuration; it uses providers rather than replacing them.
• Data source reads existing information through a provider, but it is not the plugin that communicates with the external API.

Question 7

Topic: Terraform Fundamentals

A cloud engineer needs this configuration to create AWS resources in region us-west-2. Based on the snippet, where should that provider-specific setting be added?

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

resource "aws_s3_bucket" "logs" {
  bucket = "team-logs-example"
}

Options:

• A. In a provider "aws" block

• B. In the backend configuration

• C. In the aws_s3_bucket resource block

• D. In the required_providers block

Best answer: A

Explanation: The required_providers block only declares which provider plugin Terraform should use and which version is acceptable. Settings like region, endpoint, or authentication-related inputs are configured in the provider block.

Terraform separates provider requirements from provider configuration. In this snippet, required_providers tells Terraform to use the AWS provider from hashicorp/aws and to accept versions matching ~> 5.0. It does not tell Terraform how to connect to AWS or which region to target.

Provider-specific operational settings belong in a provider block, such as:

• region
• custom endpoints
• authentication-related arguments

Resource blocks describe the infrastructure objects to manage, and backend configuration controls where Terraform state is stored. The key takeaway is that provider-wide connection and behavior settings are configured in the provider block.

• Version vs. configuration Putting region in required_providers is wrong because that block only declares provider source and version constraints.
• Resource scope confusion Putting region in the bucket resource is wrong because the provider configuration applies to provider behavior, not to the resource schema shown.
• State vs. provider Backend configuration is for state storage and related behavior, not for cloud provider region or authentication settings.

Question 8

Topic: Terraform Fundamentals

A team uses the same Terraform root module in dev, stage, and prod through HCP Terraform. They need repeatable provider selections across all workspaces today, but they also want to evaluate newer compatible provider releases later during a planned, reviewed change. Which approach best meets these requirements?

Options:

• A. Use an exact = pin so newer compatible releases are adopted automatically.

• B. Use a ~> constraint, commit .terraform.lock.hcl, and upgrade intentionally with terraform init -upgrade.

• C. Use no version constraint so each workspace installs the latest provider.

• D. Use terraform plan -upgrade to test newer provider versions safely.

Best answer: B

Explanation: The best fit is to allow a compatible version range, record the exact selected version in the lock file, and upgrade only when the team chooses to. That preserves consistent builds across workspaces without over-restricting future reviewed upgrades.

Terraform uses version constraints and the dependency lock file for different purposes. A constraint in required_providers defines which provider versions are acceptable, such as a compatible release series with ~>. The .terraform.lock.hcl file then records the exact provider version Terraform selected, which helps keep local runs and HCP Terraform workspaces consistent.

When the team wants to consider a newer provider release within the allowed range, terraform init -upgrade tells Terraform to select a newer matching version and update the lock file. The resulting plan can then be reviewed before apply. An exact pin with = is more restrictive: it guarantees one specific version, but it does not support adopting newer compatible releases until the configuration is edited.

• Exact pinning keeps one fixed version, but it does not allow newer compatible releases until the version is changed manually.
• No constraint can lead to different provider selections across runs or workspaces, which breaks repeatable builds.
• Wrong command fails because provider selection changes happen during terraform init, not terraform plan.

Question 9

Topic: Terraform Fundamentals

A cloud engineer deleted a resource outside Terraform and recreated it manually. The configuration still uses the same resource address, but the remote object now has a different ID. Instead of using supported Terraform workflows, the engineer wants to open the state file in a text editor and replace the old ID by hand. Why is this risky?

Options:

• A. It can map the resource address to the wrong object, causing misleading drift and bad lifecycle actions.

• B. State affects outputs only, not create, update, or destroy decisions.

• C. Manual edits are safe when the new object has the same type.

• D. Terraform ignores manual state edits because plan reads only configuration.

Best answer: A

Explanation: Terraform state is the record Terraform uses to map each resource address to a specific real object. If you hand-edit that mapping carelessly, Terraform can misread drift and act on the wrong object during later plans or applies.

Terraform state is not just a cache. It stores the relationship between a resource address in configuration and the real remote object Terraform believes it manages, plus metadata used during planning. If you manually swap an ID or edit entries carelessly, Terraform may believe the wrong object belongs to that address. That can hide real drift, confuse future plans, and cause broken lifecycle behavior such as unexpected replacement or destruction.

• Configuration declares the desired objects.
• State records which real objects are already managed.
• plan compares configuration, state, and provider-read data.

Because state directly affects those decisions, manual text editing is risky. Safer approaches use supported workflows such as terraform import or Terraform state commands.

• The option claiming plan reads only configuration fails because Terraform uses state to know what it already manages.
• The option claiming matching resource type makes manual edits safe fails because the address-to-object binding can still be wrong.
• The option claiming state affects only outputs fails because state directly influences create, replace, and destroy behavior.

Question 10

Topic: Terraform Fundamentals

A team keeps most AWS resources in us-west-2, but one child module must create its resources in us-east-1.

provider "aws" {
  region = "us-west-2"
}

provider "aws" {
  alias  = "use1"
  region = "us-east-1"
}

module "logs" {
  source = "./modules/log_bucket"
  name   = "app-logs"
}

What is the best next step to ensure the logs module uses the non-default provider configuration?

Options:

• A. Run terraform init so Terraform selects the aliased provider automatically.

• B. Add providers = { aws = aws.use1 } to the module block.

• C. Add provider = aws.use1 to the module block.

• D. Change the default aws provider region to us-east-1.

Best answer: B

Explanation: A module call inherits the default provider configuration unless you pass a different one explicitly. Since the default aws provider points to us-west-2, the module must be mapped to the aliased aws.use1 configuration to target us-east-1.

This question tests how Terraform handles multiple provider configurations. When a root module defines both a default provider and an aliased provider, child modules do not automatically choose the alias based on region intent. They inherit the default provider unless the caller passes a provider mapping.

For a child module, the correct pattern is to add:

• providers = { aws = aws.use1 }

That tells Terraform to satisfy the child module’s aws provider with the aws.use1 configuration from the root module. A similar idea exists for individual resources, but resources use the provider meta-argument, while modules use the providers map. The key takeaway is that Terraform will not switch a module to a non-default endpoint or region unless you associate that module with the correct aliased provider configuration.

• Wrong meta-argument: provider = aws.use1 is used on a resource block, not on a module call.
• Too broad a change: changing the default provider would also affect other resources that should stay in us-west-2.
• Wrong workflow step: terraform init installs and prepares providers, but it does not automatically bind a module to an aliased configuration.

Continue in the web app

Use IT Mastery for interactive Terraform Associate (004) practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking.

Try Terraform Associate (004) on Web

Related focused pages

• Free Terraform Associate (004) Full-Length Practice Exam
• IaC with Terraform
• Core Terraform Workflow
• Terraform Configuration
• Terraform Modules
• Terraform State Management
• Terraform Maintenance
• HCP Terraform