A team runs Terraform in Jenkins with an S3 backend, outside HCP Terraform, and must enforce the same policy-as-code rules on proposed changes before any apply. Which pipeline design does this?
Select an answer to reveal the explanation.
Short Explanation
Your policy needs to judge what's about to happen, and that's the plan. Save it, turn it into JSON with terraform show -json, let the policy engine rule on it, and apply that exact saved plan if it passes.
Full Explanation
Policy engines such as OPA, or Sentinel run from its CLI, evaluate structured data. Outside HCP Terraform, the standard pattern is to save the plan with terraform plan -out, render it as machine-readable JSON with terraform show -json against the saved plan file, pass that JSON to the policy engine, and fail the pipeline on a violation. If the policies pass, terraform apply runs the same saved plan file, so what was evaluated is exactly what gets applied. The JSON plan includes resource changes with their before and after values, which is the information guardrails need. terraform validate checks configuration syntax and internal consistency; it does not evaluate any policy language and knows nothing about policy rules. terraform state pull returns the current state, which describes what exists now rather than what the plan will change, so it misses proposed additions and modifications. Searching source files with text rules misses values computed from variables, modules, functions and data sources, and it cannot see the plan's actions such as replace or destroy. Exam caveat: a saved plan file and its JSON can contain sensitive values, so store them as protected, short-lived pipeline artifacts. Operational check: introduce a known violation, confirm the policy step fails before apply, then fix it and confirm the pipeline applies the saved plan without replanning.