HashiCorp Terraform Associate (004) Question 1
Single answer1 Infrastructure as Code (IaC) with TerraformA company has been creating cloud infrastructure manually through a provider console for several years. Different teams name resources inconsistently, and no reliable record exists of what was changed or when. The company wants to adopt Terraform as its Infrastructure as Code (IaC) tool so that future changes are repeatable, reviewable, and less error-prone across development, staging, and production environments. Which approach best addresses this goal?
- A
Use Terraform configuration files to declare the desired infrastructure, store the code in version control, and apply changes through a reviewed workflow.
- B
Continue making infrastructure changes in the provider console, then run terraform refresh to convert those manual changes into reusable Terraform code.
- C
Generate a Terraform execution plan once, save the output, and use that saved plan as the long-term source of truth for infrastructure documentation.
- D
Use Terraform only to provision new environments, but allow ongoing changes in the provider console because Terraform can automatically reconcile all manual edits later.
Show answer and explanation
Correct answer: A
Explanation
Terraform's value as an Infrastructure as Code tool comes from declaring infrastructure in configuration files and managing changes through a controlled workflow. In practice, teams store Terraform code in version control, review proposed changes, and use terraform plan and terraform apply to make infrastructure changes predictably. This creates consistency across environments, supports collaboration, and provides an auditable history of infrastructure changes. By contrast, manual console changes create drift and reduce reliability. HashiCorp documentation emphasizes Terraform's declarative workflow, execution planning, and use of configuration as the desired-state definition, while state tracks resource bindings rather than replacing configuration as the source of truth.
- A. Correct.
Correct. This is the core IaC practice Terraform is designed to support. Terraform configurations declaratively define the desired end state of infrastructure in code, which can be versioned, peer-reviewed, and reused across environments. Storing configuration in version control provides change history and supports collaborative workflows such as pull requests and approvals. This directly addresses repeatability, auditability, and reduced configuration drift.
- B. Incorrect.
Incorrect. terraform refresh updates Terraform state with information from real infrastructure, but it does not generate or reconstruct complete reusable Terraform configuration from manual changes. Relying on manual console changes defeats the purpose of IaC and increases drift between code, state, and actual infrastructure.
- C. Incorrect.
Incorrect. A Terraform plan is a point-in-time preview of proposed actions, not the authoritative long-term definition of infrastructure. The source of truth in Terraform-based IaC is the configuration files, along with state for resource mapping. A saved plan file is not intended to replace version-controlled configuration or serve as ongoing infrastructure documentation.
- D. Incorrect.
Incorrect. Allowing continued manual console changes undermines Terraform's IaC model and introduces configuration drift. Terraform can detect differences between configuration and existing infrastructure during planning, but it is not a justification for unmanaged manual updates. Best practice is to make changes through Terraform so the code remains the authoritative definition.