HashiCorp Terraform Associate (004) Question 218
Single answer8c Describe how to organize and use HCP Terraform workspaces and projectsA platform team is moving from local Terraform execution to HCP Terraform. They manage infrastructure for three business units: Retail, Finance, and Shared Services. Each business unit has separate application stacks, and each stack has dev, staging, and prod environments. The team wants to improve organization and visibility for administrators without changing the fact that each environment must keep its own Terraform state and run history. Which approach best uses HCP Terraform projects and workspaces to meet these requirements?
- A
Create one HCP Terraform workspace per business unit and use Terraform workspaces inside the CLI to separate dev, staging, and prod states.
- B
Create one HCP Terraform project for each business unit, then create separate HCP Terraform workspaces within each project for each application stack and environment combination.
- C
Create one HCP Terraform project for dev, one for staging, and one for prod, then place all business units in the same workspace and use variables to switch between stacks.
- D
Create a single HCP Terraform project for the entire organization and use tags instead of workspaces to isolate state for different environments.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use projects as organizational containers and workspaces as the operational unit of isolation. In HCP Terraform, a workspace stores Terraform state, variables, run history, and execution settings. Projects are used to group related workspaces for easier organization and management. For a structure with multiple business units, application stacks, and environments, a practical pattern is to create projects that reflect major organizational boundaries, such as business units, and then create separate workspaces for each stack/environment pair. This keeps dev, staging, and prod isolated while giving administrators a clean way to browse related infrastructure. This approach aligns with HashiCorp guidance that HCP Terraform workspaces are the main boundary for separate state and runs, while projects help organize those workspaces at scale.
- A. Incorrect.
Incorrect. In HCP Terraform, a workspace is the primary unit for state, runs, variables, and execution. Using one HCP Terraform workspace per business unit would combine multiple environments into the same workspace unless additional separation is introduced. Relying on Terraform CLI workspaces for environment separation is generally not the recommended organizational model in HCP Terraform for distinct long-lived environments such as dev, staging, and prod. A common best practice is one HCP Terraform workspace per environment or deployable unit so each has isolated state and run history.
- B. Correct.
Correct. Projects in HCP Terraform are used to organize related workspaces and improve administrative visibility. Creating a project per business unit gives a clear top-level grouping for Retail, Finance, and Shared Services. Then creating separate HCP Terraform workspaces for each application stack and environment combination preserves isolated state, variables, and run history for dev, staging, and prod. This aligns with how HCP Terraform is intended to organize infrastructure work at scale.
- C. Incorrect.
Incorrect. Projects can help group related workspaces, but placing all business units in the same workspace and using variables to switch targets is a poor fit for HCP Terraform. A single workspace would share one state file and one run history, which violates the requirement that each environment keep its own state and execution record. This is a common misconception from smaller Terraform setups where variables are overused instead of proper workspace separation.
- D. Incorrect.
Incorrect. Tags can help categorize and filter workspaces, but they do not provide state isolation. In HCP Terraform, only separate workspaces provide separate state, variables, and run histories. A single project for the whole organization may be possible for some teams, but it does not by itself solve the requirement for per-environment isolation, and tags are not a substitute for creating distinct workspaces.