Terraform Associate (004): IaC with Terraform

Topic snapshot

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Infrastructure as Code (IaC) with Terraform

A platform team wants one Terraform workflow to provision infrastructure in both AWS and Azure for the same application. They review this configuration:

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

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

provider "azurerm" {
  features {}
}

What is the best interpretation of this configuration?

Options:

• A. Terraform can install both providers, but each plan can target only one cloud at a time.

• B. Terraform can manage both clouds in one workflow through provider plugins and a common configuration language.

• C. This configuration is valid only when runs execute in HCP Terraform, not with the Terraform CLI.

• D. Terraform must use one cloud vendor’s native provisioning model as the base for both providers.

Best answer: B

Explanation: This configuration shows Terraform using multiple providers in the same root module. That demonstrates Terraform’s multi-cloud model: one workflow and one language can coordinate resources across vendors without requiring you to adopt a single vendor-specific provisioning approach.

Terraform is service-agnostic because it uses providers to translate a common Terraform workflow into API calls for each platform. In this snippet, aws and azurerm are both declared under required_providers, and both are configured in the same configuration, so Terraform can work with AWS and Azure from the same project.

The important idea is that Terraform does not require you to switch to one cloud’s native template or provisioning model. You still use the same core steps:

• write HCL configuration
• run terraform init
• run terraform plan
• run terraform apply

A nearby misconception is that multi-cloud requires HCP Terraform, but the capability comes from Terraform providers and works with the CLI as well.

• Vendor-native base model is wrong because Terraform uses its own workflow and HCL, not one cloud vendor’s provisioning system as the standard.
• One cloud per plan is wrong because a single Terraform plan can include resources managed through multiple providers.
• HCP Terraform required is wrong because multi-cloud support is a core Terraform capability, not something limited to HCP Terraform runs.

Question 2

Topic: Infrastructure as Code (IaC) with Terraform

Which Terraform concept lets you manage AWS, Azure, and other platforms in one Terraform workflow without adopting a single cloud vendor’s native provisioning model?

Options:

• A. Providers

• B. State files

• C. Backends

• D. Modules

Best answer: A

Explanation: Terraform is multi-cloud because providers connect Terraform to different platforms’ APIs. Terraform Core keeps a consistent workflow and configuration model, so you do not have to switch to one vendor’s native provisioning toolset.

The core concept is the provider. A provider is the component Terraform uses to interact with a specific platform or service, such as AWS, Azure, Google Cloud, or SaaS tools. Terraform Core handles the common workflow—writing HCL, creating a plan, tracking dependencies, and applying changes—while providers translate that intent into API calls for each target system.

That separation is what makes Terraform cloud-agnostic. You can use multiple providers in the same configuration and coordinate resources across different clouds without adopting one vendor’s provisioning model as the standard for everything.

The closest distractor is modules, but modules organize and reuse configuration; they do not connect Terraform to external platforms.

• Backends store and manage state; they do not provision resources on cloud platforms.
• Modules package reusable Terraform code, but they still rely on providers to create infrastructure.
• State files record Terraform’s known infrastructure objects; they are not the integration point with cloud APIs.

Question 3

Topic: Infrastructure as Code (IaC) with Terraform

A platform team uses one HCP Terraform workspace for a root module. Exhibit:

Terraform will perform the following actions:

  # aws_s3_bucket.logs will be created
  + resource "aws_s3_bucket" "logs"

  # vsphere_virtual_machine.app will be created
  + resource "vsphere_virtual_machine" "app"

Plan: 2 to add, 0 to change, 0 to destroy.

What is the best interpretation of this plan?

Options:

• A. It means the vSphere object can only be a data source.

• B. It is invalid because one workspace can use only one provider.

• C. It requires separate state files for cloud and on-prem resources.

• D. It shows a hybrid workflow using multiple providers in one configuration.

Best answer: D

Explanation: The plan shows Terraform preparing changes for both AWS and vSphere from the same workspace. That is a hybrid workflow: Terraform can manage cloud and on-premises resources together when the configuration uses the appropriate providers.

Terraform is provider-agnostic. In this plan, one run includes an AWS resource and a vSphere resource, so the same Terraform configuration estate is managing both cloud and on-premises infrastructure. That is a classic hybrid workflow.

Terraform does not limit a workspace or root module to a single provider. If the required providers are available and configured, one plan can include resources from different platforms and services, and Terraform can track them together in state. Teams may still choose separate states or workspaces for organizational or lifecycle reasons, but different platforms alone do not require that split.

The key signal is that both resource types appear in the same plan output.

• One-provider limit is incorrect because a single Terraform run can include resources from multiple providers.
• Data source confusion is incorrect because the exhibit shows a managed resource, not a read-only data source.
• Mandatory split is incorrect because separate state files are a design choice, not a requirement just because the estate is hybrid.

Question 4

Topic: Infrastructure as Code (IaC) with Terraform

A team has been creating the same infrastructure in dev, staging, and prod by using the cloud console and one-off commands. They want reusable definitions, peer-reviewed changes, and consistent deployments across environments. Which approach is the best fit for Infrastructure as Code with Terraform?

Options:

• A. Document the manual console steps in a shared runbook for each environment.

• B. Create HCP Terraform workspaces while continuing to change resources in the cloud console.

• C. Provision resources manually first, then use terraform import for anything important.

• D. Define Terraform files and modules in version control, then review plans before apply.

Best answer: D

Explanation: Infrastructure as Code is the practice of defining infrastructure in versioned configuration files instead of relying on manual click-ops or ad hoc commands. Using Terraform files and modules in version control supports reuse, review, and consistent deployment across environments.

The core IaC idea is that infrastructure should be described as code, stored in version control, and changed through a repeatable workflow. In Terraform, that means writing configuration files that declare the desired state, reusing modules where appropriate, and reviewing proposed changes with terraform plan before apply. This gives teams a shared source of truth, better collaboration, and more consistent results across dev, staging, and prod.

By contrast, documenting manual steps or continuing console changes still depends on people repeating actions correctly. Using terraform import is useful for bringing existing resources under Terraform management, but it is not the normal day-to-day method for managing infrastructure changes. The key takeaway is that versioned Terraform configuration—not manual operations—is the foundation of IaC.

• Runbook only still leaves infrastructure management as a manual process rather than versioned configuration.
• Import after manual changes can onboard existing resources, but it does not make manual provisioning the preferred IaC workflow.
• Workspaces without Terraform-managed changes organize runs, but console edits still bypass the code-based source of truth.

Question 5

Topic: Infrastructure as Code (IaC) with Terraform

A cloud engineer stores this Terraform configuration in version control and runs terraform plan:

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

Plan: 1 to add, 0 to change, 0 to destroy.

What is the best interpretation of what Terraform is doing?

Options:

• A. It reads an existing instance only and does not manage it.

• B. It records a manual build checklist rather than provisioning infrastructure.

• C. It creates the instance now because terraform plan makes immediate changes.

• D. It defines desired infrastructure in code and previews creation before terraform apply.

Best answer: D

Explanation: This shows Terraform being used as Infrastructure as Code. The HCL resource block describes the desired infrastructure, and terraform plan previews what Terraform would create before any change is actually applied.

Terraform is a declarative Infrastructure as Code tool: you describe the desired end state in configuration, then use workflow commands to compare that configuration to current state and generate an execution plan. In the exhibit, the resource block declares a managed infrastructure object, and Plan: 1 to add, 0 to change, 0 to destroy means Terraform has determined it would create one new resource if the operator runs terraform apply.

This is the basic Terraform workflow:

• Write infrastructure configuration in HCL
• Run terraform plan to preview changes
• Run terraform apply to provision or update infrastructure

The key distinction is that plan previews changes, while apply performs them.

• plan is preview only The option claiming the instance is created immediately is wrong because terraform plan does not change infrastructure.
• resource means managed The option about only reading an existing instance fails because the exhibit shows a resource block, not a data source.
• Not manual documentation The option about a build checklist is incorrect because Terraform uses executable configuration to provision and update infrastructure.

Question 6

Topic: Infrastructure as Code (IaC) with Terraform

Which statement best defines Infrastructure as Code when using Terraform?

Options:

• A. Recording existing resource bindings in a state file for later operations.

• B. Defining infrastructure in versioned configuration files and applying changes through Terraform workflows.

• C. Grouping reusable resource definitions into modules for shared use.

• D. Using provider plugins so Terraform can communicate with cloud APIs.

Best answer: B

Explanation: Infrastructure as Code in Terraform means describing infrastructure in configuration files that can be versioned, reviewed, and applied consistently. The key idea is treating infrastructure definitions like code instead of relying on manual console work or ad hoc commands.

Infrastructure as Code is the practice of defining the desired infrastructure in configuration files and managing those files through a repeatable workflow. In Terraform, that usually means writing HCL files, storing them in version control, reviewing changes, and using commands such as plan and apply to create or update resources. This approach improves consistency, repeatability, and auditability compared with manual click-ops.

• Configuration files describe the desired state.
• Version control tracks and reviews changes.
• Terraform workflows apply those changes predictably.

State, providers, and modules are important Terraform features, but they support IaC rather than define it.

• State tracking describes Terraform state, which stores resource mappings and metadata, not the core definition of IaC.
• Provider integration describes how Terraform talks to external APIs after reading the configuration.
• Module reuse describes one way to organize and reuse IaC, but a module is not IaC itself.

Question 7

Topic: Infrastructure as Code (IaC) with Terraform

A platform team wants to stop building dev and prod environments by hand. They need reusable, version-controlled infrastructure definitions and a safe review step before any changes are created or updated. What is the best next action with Terraform?

Options:

• A. Run terraform apply directly in each environment and review the results afterward.

• B. Create resources manually in the cloud console, then run terraform validate to confirm them.

• C. Use only Terraform data sources so the environments are generated from existing infrastructure.

• D. Write Terraform configuration, review changes with terraform plan, then provision or update with terraform apply.

Best answer: D

Explanation: Terraform is an Infrastructure as Code tool because you describe desired infrastructure in configuration files and manage it with workflow commands. terraform plan gives the safe review step, and terraform apply then creates or updates infrastructure from that reviewed configuration.

Terraform’s core IaC model is to declare infrastructure in configuration, store and review that configuration like code, and use commands to reconcile real infrastructure to the declared desired state. In this scenario, the team wants reusable definitions, consistency across environments, and a safe change review before making changes.

• Write the infrastructure in Terraform configuration
• Run terraform plan to preview proposed actions
• Run terraform apply to provision or update resources

That workflow is what makes Terraform an IaC tool for describing, provisioning, and updating infrastructure. By contrast, terraform validate checks whether configuration is syntactically valid, not whether manually created resources match the intended design. Data sources read existing infrastructure details, but they do not replace resource definitions for managed infrastructure. The key takeaway is that Terraform manages infrastructure from declarative configuration, not from manual console steps.

• Manual console changes fail the reusable, version-controlled IaC requirement, and terraform validate does not confirm hand-built infrastructure.
• Only data sources is a misuse because data sources read existing objects instead of defining managed resources to create or update.
• Apply first skips the requested safe review step, which is the purpose of terraform plan.

Question 8

Topic: Infrastructure as Code (IaC) with Terraform

Which Terraform concept allows the same core workflow commands to manage resources across many different platforms and services?

Options:

• A. Backends

• B. Provider plugins

• C. Workspaces

• D. Modules

Best answer: B

Explanation: Terraform is service-agnostic because its core engine uses a common workflow, and provider plugins supply the platform-specific API integrations. That is what lets the same Terraform process manage resources in different clouds and services.

The key concept is the provider plugin. Terraform itself provides a consistent workflow and language for defining infrastructure, but it does not directly know how to manage every cloud or service. Providers add that capability by translating Terraform resource and data source definitions into API calls for a specific platform, such as a cloud provider, DNS service, or SaaS tool.

This is why Terraform is considered service-agnostic: the operator still uses the same basic commands and workflow regardless of which providers are involved.

• terraform init installs required providers
• terraform plan shows proposed changes
• terraform apply makes the changes

Backends, modules, and workspaces are important, but they do not give Terraform multi-provider management capability.

• Backends handle where state is stored, not how Terraform talks to external platforms.
• Modules organize and reuse configuration, but they rely on providers to manage real resources.
• Workspaces separate state instances for a configuration; they do not add platform integrations.

Question 9

Topic: Infrastructure as Code (IaC) with Terraform

A team wants one Terraform configuration estate to manage public cloud networking and an on-prem DNS service. They need reusable dev/prod configuration, reviewed team changes before apply, and safer shared state than local files. What is the best next action?

Options:

• A. Use modules and separate HCP Terraform workspaces with VCS-driven runs.

• B. Convert on-prem resources to data sources and manage only cloud resources.

• C. Use one local backend and run applies from engineer laptops.

• D. Use scripts for on-prem services and keep Terraform for cloud resources.

Best answer: A

Explanation: Terraform supports hybrid workflows by using providers for different platforms in the same configuration estate. Reusable modules plus separate HCP Terraform workspaces per environment meet the stated needs for consistency, collaboration, review, and safer state handling.

Terraform is service-agnostic, so a single configuration estate can manage cloud resources alongside on-premises or third-party services by using the appropriate providers. In this scenario, modules solve the reuse requirement across dev and prod, while separate HCP Terraform workspaces give each environment its own isolated state. Using VCS-driven runs in HCP Terraform adds team review and a safer shared workflow than passing around local state files or relying on individual laptops for applies.

This keeps one consistent Terraform workflow for both cloud and on-prem resources instead of splitting tools or removing some systems from Terraform management. The key takeaway is that hybrid management in Terraform is normal; the best practice is to combine reusable configuration with shared, remotely managed execution and state.

• Local state risk misses the collaboration and state-safety requirements because local backends on laptops are not a safe shared workflow.
• Data sources only is incorrect because data sources read existing objects; they do not manage the on-prem service.
• Separate scripts breaks the single Terraform workflow and cross-environment consistency the team wants.

Question 10

Topic: Infrastructure as Code (IaC) with Terraform

A team stores its Terraform configuration in a Git repository and requires pull request approval before merging changes. Which governance benefit does this practice provide?

Options:

• A. Removal of the need to run terraform plan before terraform apply

• B. Automatic correction of infrastructure drift without running Terraform

• C. Automatic state locking and encryption for every Terraform run

• D. An auditable history of infrastructure changes with peer review before deployment

Best answer: D

Explanation: Storing Terraform code in version control improves governance by creating a change history and enabling peer review before infrastructure changes are merged and applied. That supports accountability, safer collaboration, and easier auditing.

When infrastructure is expressed as code, version control systems such as Git provide governance benefits that manual changes cannot. Each commit records what changed, who changed it, and when it changed. Requiring pull request approval adds peer review, so another team member can inspect the proposed Terraform configuration before it affects real infrastructure.

This improves governance by helping teams:

• track and audit infrastructure changes
• catch mistakes before deployment
• discuss and approve changes consistently
• revert to an earlier known version if needed

These benefits come from version control and review workflow, not from Terraform state or skipping core commands such as plan.

• State features describe backend capabilities, not the governance benefit of storing configuration in version control.
• Automatic drift correction is incorrect because Terraform does not fix drift unless you run the workflow to detect and apply changes.
• Skipping planning is unsafe; terraform plan remains an important review step even when code is peer reviewed.

Continue with full practice

Use the Terraform Associate (004) Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try Terraform Associate (004) on Web View Terraform Associate (004) Practice Test

Related focused pages

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

Free review resource

Read the Terraform Associate (004) Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.