HashiCorp Terraform Associate (004) Question 3
Single answer1 Infrastructure as Code (IaC) with TerraformA platform team has been manually creating cloud networking components for each application environment, which has led to configuration drift and inconsistent naming. They want to adopt Infrastructure as Code using Terraform so that developers can provision identical environments from version-controlled definitions and review proposed changes before anything is created. Which approach best meets this goal?
- A
Define the infrastructure in Terraform configuration files, store them in version control, and use terraform plan before terraform apply to review the proposed changes
- B
Use Terraform only to document the existing manually created infrastructure, but continue making production changes directly in the cloud console for speed
- C
Write shell scripts that call cloud provider CLIs to create resources, because scripts provide the same dependency graph and execution planning as Terraform
- D
Create the initial infrastructure with Terraform once, then stop using Terraform and make future updates manually to avoid state management complexity
Show answer and explanation
Correct answer: A
Explanation
Terraform is designed to implement Infrastructure as Code by defining infrastructure in declarative configuration files that can be versioned, reviewed, and reused. A standard workflow is to store .tf files in version control, run terraform plan to preview proposed actions, and then run terraform apply to make approved changes. This approach improves consistency across environments, reduces manual error, and enables collaboration through code review. In Terraform best practices and HashiCorp documentation, the plan-and-apply workflow is central to safely managing infrastructure changes, while keeping Terraform as the authoritative source of infrastructure helps prevent drift.
- A. Correct.
Correct. This is the core Infrastructure as Code workflow with Terraform. Terraform configurations declaratively describe the desired infrastructure, version control provides change history and collaboration, and terraform plan shows the execution plan before changes are applied. This supports repeatability, peer review, and reduced drift across environments.
- B. Incorrect.
Incorrect. Terraform is intended to manage infrastructure lifecycle, not just document it. Continuing to make changes manually in the cloud console reintroduces configuration drift and undermines the benefits of IaC, such as consistency, reproducibility, and auditable change control.
- C. Incorrect.
Incorrect. While shell scripts and provider CLIs can automate tasks, they do not provide Terraform's declarative model, built-in dependency graph, state tracking, and detailed execution plan in the same way. This option reflects a common misconception that any automation is equivalent to Infrastructure as Code with Terraform.
- D. Incorrect.
Incorrect. Creating infrastructure once with Terraform but then switching back to manual updates defeats the purpose of IaC. Terraform is most valuable when it remains the system of record for ongoing infrastructure changes. Avoiding Terraform because of state management complexity increases the likelihood of unmanaged drift and inconsistent environments.