Policies in an HCP Terraform organization are currently edited directly in the web UI. A faulty edit last month blocked deployments, and nobody could see who changed what or roll back quickly. What should the governance team move to?
Select an answer to reveal the explanation.
Short Explanation
You should treat policy like code because it is code. Put the policy set in a Git repo, and every change gets a pull request, a reviewer, a history and an easy revert. Editing in the UI is fine for experiments, not for guardrails people depend on.
Full Explanation
HCP Terraform supports three ways to publish policies: individually managed policies edited in the UI, policy sets connected to a version control repository, and automated publishing through the Policy Sets API or the tfe provider. With a VCS-connected policy set, the repository holds the configuration file, sentinel.hcl for Sentinel or policies.hcl for OPA, together with the policy files, and HCP Terraform automatically picks up changes pushed to the configured branch. Every change can then go through a pull request with review and automated tests, Git history shows who changed what and when, and a bad change is undone by reverting the commit. HashiCorp describes UI-managed policies as ideal for initial experimentation and not recommended for organizations with many policies, so a naming convention does not add review, history or rollback. Dropping everything to advisory removes enforcement entirely, trading one outage for having no guardrails. Run tasks integrate external services into runs; moving policy logic to an external service does not by itself add review or history to the policy rules, and it abandons the native policy framework. Exam caveat: connecting a policy set to version control requires the Standard or Premium edition. Operational check: change a policy through a pull request, merge it, and confirm the policy set shows the new version on the next run.