HCP Terraform

In HCP Terraform, what is the primary role of a project in relation to workspaces?

• AA project is a single unit of infrastructure that always maps to exactly one state file shared by every workspace.
• BA project is a container that groups related workspaces so access permissions and organisation can be managed together.check_circle Correct
• CA project is a version-controlled directory of Terraform configuration that HCP Terraform executes on each run.
• DA project is a saved set of input variables that workspaces import at plan time to avoid duplication.

Why A is wrong: This confuses a project with a workspace; state files belong to individual workspaces, and a project can contain many workspaces each with its own state, so it is wrong.

Why B is correct: Projects in HCP Terraform group workspaces to organise them and to scope team access at the project level, which is exactly their purpose.

Why C is wrong: Configuration lives in a connected VCS repository or uploaded files, not in a project, so describing a project as a config directory misstates the concept.

Why D is wrong: Shared variable reuse is handled by variable sets, not projects, so this plausibly-worded option describes the wrong feature.

An engineer has just added a cloud block for HCP Terraform to a configuration that provisions AWS resources. Runs will execute remotely in the workspace. The AWS provider expects credentials from environment variables. Where should the engineer place those credentials so the remote plan and apply can authenticate to AWS?

• AAs environment variables in the workspace's variable set in HCP Terraform, marked sensitive so the remote runner injects them at run time.check_circle Correct
• BAs environment variables exported in the engineer's local shell, since HCP Terraform reads the workstation environment when it starts a remote run.
• CHardcoded inside the cloud block as an extra credentials argument that HCP Terraform forwards to the AWS provider.
• DIn a terraform.tfvars file committed alongside the configuration so the remote runner loads them as input variables.

Why A is correct: Remote runs read workspace environment variables, so storing the credentials there as sensitive environment variables lets the runner authenticate to AWS.

Why B is wrong: Remote runs execute on HCP Terraform's runners, not the workstation, so local shell variables are not visible to the remote plan and apply.

Why C is wrong: The cloud block has no credentials argument for providers, and hardcoding secrets in configuration would also commit them to version control.

Why D is wrong: Provider credentials read from environment variables are not input variables, and committing secrets in tfvars exposes them in the repository.

A shared networking workspace publishes VPC IDs that several application workspaces consume through remote state. The team wants each application workspace to automatically queue a run whenever the networking workspace finishes a successful apply. Which HCP Terraform feature should they configure to achieve this chaining?

• AAdd a notification to the networking workspace that emails the application teams so they can manually start each downstream run.
• BEnable the VCS integration on the networking workspace so that its apply opens a pull request in each application repository.
• CConfigure a run trigger on each application workspace that references the networking workspace as its source.check_circle Correct
• DSet a run trigger on the networking workspace that lists each application workspace as its source workspace.

Why A is wrong: Notifications do announce a completed apply, which feels close, but they only inform people and rely on a manual start, so they do not automatically queue the downstream runs the team wants.

Why B is wrong: The VCS integration links a workspace to a repository for plan-on-pull-request behaviour, so it sounds relevant, but it reacts to repository events, not to another workspace's apply, and it does not chain workspaces.

Why C is correct: A run trigger set on a downstream workspace names an upstream source workspace and queues a run in the downstream whenever the source completes a successful apply, which is exactly the chaining described.

Why D is wrong: This inverts the direction: a run trigger is configured on the workspace that should be triggered and points at the upstream source, so placing it on the networking workspace pointing downstream would not queue the application runs.

During a plan in HCP Terraform, a team lead wants reviewers to see the projected monthly cost impact of a change before anyone approves the apply, so budget-heavy changes can be caught early. Which capability surfaces this information as part of the run?

• ASentinel policy evaluation, which prints the total monthly bill for the workspace at the end of each successful apply.
• BCost estimation, which produces a projected monthly cost delta for supported resources during the run for reviewers to inspect.check_circle Correct
• CThe private provider registry, which reports the licensing cost of each provider the configuration downloads.
• DRemote state sharing, which aggregates the billing tags exported from every workspace that reads the state.

Why A is wrong: Sentinel is a governance engine and can even read cost estimates in a policy, which makes it plausible, but it does not itself generate or display the projected cost figures to reviewers.

Why B is correct: Cost estimation runs after the plan for supported providers and shows the projected monthly cost and the delta versus current spend, exactly the pre-apply visibility the lead wants.

Why C is wrong: The private registry distributes providers and modules and has nothing to do with cloud spend, though pairing cost with providers sounds superficially reasonable.

Why D is wrong: Remote state sharing lets one workspace consume another's outputs, which touches collaboration, but it does not compute or present any cost estimate for a plan.

With a workspace using the default HCP Terraform run mode, how does a remote apply differ from running terraform apply entirely on a local backend?

• AThe remote apply refuses to read any local .tf files and instead pulls the configuration exclusively from the public registry.
• BThe remote apply runs the plan on the local machine but uploads the finished state file to HCP Terraform only after resources are created.
• CThe remote apply executes the plan and apply on HCP Terraform's managed workers, streaming the output back to the practitioner's terminal.check_circle Correct
• DThe remote apply always requires a variables file to be committed to version control before it will start execution.

Why A is wrong: This overstates the split; the configuration still comes from the working directory or connected VCS, not from the registry, so the description is wrong.

Why B is wrong: This is tempting because state does end up in the managed backend, but in the default mode the plan and apply themselves run remotely, not locally.

Why C is correct: In the default remote run mode the operation runs on HCP Terraform infrastructure while the CLI streams the log, which is the defining difference from a purely local apply.

Why D is wrong: Variables can be supplied as workspace variables in HCP Terraform, so a committed variables file is not a precondition, making this incorrect.