A platform team's engineers already write Rego policies for Kubernetes admission control. They want HCP Terraform to evaluate Terraform plans against policies written in the same language and enforce them on runs in selected projects. What should they use?
Select an answer to reveal the explanation.
Short Explanation
If your team already speaks Rego, you don't need to learn a new language: HCP Terraform runs Open Policy Agent policy sets natively. Attach the set to the projects you care about and pick advisory or mandatory. Sentinel can't import Rego, and check blocks are HCL, not a policy engine.
Full Explanation
HCP Terraform supports several policy frameworks natively, including Sentinel and Open Policy Agent. An OPA policy set contains Rego policies, typically sourced from a VCS repository, that evaluate the run's plan data; the set can be applied globally or to specific projects and workspaces, and each policy uses either the advisory or the mandatory enforcement level. OPA policy sets run as policy evaluations, after the plan and before apply. A Sentinel policy set runs Sentinel policies; Sentinel modules contain Sentinel code, and there is no mechanism to import Rego into Sentinel. Run tasks can call external services, but the premise that HCP Terraform supports only Sentinel natively is wrong, and an external OPA server adds infrastructure and loses native enforcement-level and override handling. Check blocks are part of the Terraform language: they contain HCL assertions that report warnings and never block an apply, so they are neither Rego nor an enforcement mechanism. Exam caveat: OPA mandatory failures can be overridden by users with the policy override permission, so OPA is not a drop-in for an override-proof rule. Operational check: attach the policy set to one project, queue a plan that violates a rule, and confirm the policy evaluation result appears on the run.