TF-Associate-004 - HCP Terraform (11% of the exam) - Section 8b

Describe HCP Terraform collaboration and governance features.

Remote state sharing, policy as code with Sentinel or OPA, cost estimation, and private module and provider registries support team collaboration and guardrails. Candidates should match a governance need to the HCP Terraform feature that meets it.

policy as codeSentinel and OPAcost estimationprivate registry

Practice question for this objective

Free sampleHCP Terraformmedium

A platform team wants every run in an HCP Terraform workspace to be blocked from applying if a proposed AWS security group opens port 22 to the whole internet. They want this enforced automatically as part of the run, before the apply stage. Which HCP Terraform feature should they use?

# proposed change flagged during plan
resource "aws_security_group_rule" "ssh" {
  type        = "ingress"
  from_port   = 22
  to_port     = 22
  protocol    = "tcp"
  cidr_blocks = ["0.0.0.0/0"]
}
  • AA policy as code check using Sentinel or OPA, attached to the workspace so it evaluates the plan between the plan and apply stages. Correct
  • BThe cost estimation feature, which inspects the plan and refuses to apply resources that create a security risk.
  • CA private module registry constraint that rejects any module publishing a rule with an open CIDR block.
  • DA workspace run trigger that fires a downstream workspace to revert the offending rule after the apply completes.
Policy as code with Sentinel or OPA in HCP Terraform enforces governance rules against a plan and can block an apply. HCP Terraform evaluates attached Sentinel or OPA policy sets against the plan output during the run, and a hard-mandatory policy that fails prevents the apply stage from proceeding, which is precisely the automated gate the team needs.

Why A is correct: Sentinel and OPA are HCP Terraform's policy as code engines; a policy set attached to the workspace runs against the plan and can produce a hard-mandatory failure that blocks the apply.

Why B is wrong: Cost estimation is a genuine HCP Terraform feature and runs at a similar point in the run, which makes it tempting, but it only reports projected spend and never blocks a run for a security condition.

Why C is wrong: The private registry hosts and versions shared modules and providers, so it sounds governance related, but it does not evaluate the contents of a plan or enforce rules at run time.

Why D is wrong: Run triggers do chain workspaces together, which feels like automation, but they act after a run finishes and cannot prevent the risky apply from happening in the first place.

See more TF-Associate-004 practice questions, answers explained.

Exam traps in HCP Terraform

Answers that look right on this material and are not. Each one is a distractor from a different question in the TF-Associate-004 bank for this domain.

  • Sentinel and Chef InSpec compliance profiles

    Why it is wrong: Sentinel is genuinely supported, which makes this tempting, but InSpec is a separate compliance tool and is not one of HCP Terraform's built-in policy engines.

  • Remote state sharing, so each workspace reads the networking outputs directly from the source workspace's state.

    Why it is wrong: State sharing distributes outputs between workspaces and supports collaboration, but it offers no versioned module releases or documentation and is not how reusable modules are consumed.

  • It reads the monthly invoices from connected cloud accounts and reconciles them against tagged resources

    Why it is wrong: This sounds like billing reconciliation, but cost estimation works from the plan, not from provider invoices or account billing data.

More in this domain

Back to all HCP Terraform objectives, or the TF-Associate-004 cert hub.

Examworthy is not affiliated with or endorsed by HashiCorp. Original, blueprint-aligned practice material only.