With cost estimation enabled, the platform team wants a guardrail that stops any run whose change would raise the estimated monthly cost by more than 500 dollars, while allowing an authorized approver to let an exception through. How should this be implemented?
Select an answer to reveal the explanation.
Short Explanation
The cost number already exists once estimation runs; you just need a bouncer who can read it. A Sentinel policy on tfrun.cost_estimate does that, and soft-mandatory lets an approved person override. The trap: the plan itself has no prices in it.
Full Explanation
The Sentinel tfrun import exposes a cost_estimate namespace with prior_monthly_cost, proposed_monthly_cost and delta_monthly_cost, present when a cost estimate is available. HashiCorp's example converts delta_monthly_cost with the decimal import and requires it to be no more than a threshold. Setting the policy to soft-mandatory makes a failure pause the run in the Policy Override state until a user with permission to manage policy overrides approves it, which is exactly the exception path requested. The cost data is available only to policy checks, the legacy policy execution mode; policy evaluations cannot access it, so the policy set must use that mode. An OPA policy runs as a policy evaluation, which cannot see cost estimation data, and the JSON plan contains resource attributes, not prices. A check block reports warnings and never blocks an apply, and a configuration has no access to cost estimates. A Sentinel policy built on tfplan/v2 sees attributes like instance types but no prices; maintaining a price table inside policy code would drift, and hard-mandatory removes the approved exception path. Exam caveat: cost estimation is skipped for runs that use resource targeting, so the cost_estimate namespace may be missing; write the policy to handle that case deliberately. Operational check: queue a plan that adds expensive resources in a test workspace and confirm the run pauses in Policy Override with the policy's message.