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.
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.