A platform team must deploy the same set of networking, cluster and application components to many regions. They want one shared definition, each region planned and approved separately, and changes rolled out region by region, managed as a unit in HCP Terraform. Which approach fits these goals?
Select an answer to reveal the explanation.
Short Explanation
Stacks are built for 'same recipe, many kitchens.' You write the components once, then add a deployment for each region, and HCP Terraform lets you plan and roll changes out kitchen by kitchen. It's the same idea as copying workspaces, without the copy-and-paste.
Full Explanation
Terraform Stacks organize infrastructure into components, built on Terraform modules, and deployments, which are separate instances of the same components with their own inputs such as region. HCP Terraform manages the Stack as a unit, while each deployment has its own lifecycle: configuration changes produce a plan per deployment, which can be reviewed and approved separately, so a change can be rolled out across deployments in a controlled order. That matches one shared definition deployed to many regions with region-by-region promotion. CLI workspaces in one directory share a backend and credentials and give no per-region approval workflow in HCP Terraform; selecting each in turn is manual and error-prone. Run tasks integrate external checks into a run; they do not copy configuration or deploy to other regions. A single root module with a module call per region puts every region into one plan and one state, so a change cannot be approved region by region, and depends_on only orders operations within that single apply. Exam caveat: Stacks complement workspaces rather than replacing them for every use case; simple single-environment configurations can stay in workspaces. Operational check: after adding a deployment, confirm HCP Terraform shows a separate plan for it awaiting approval.