A Sentinel policy limits the number of instances a single run may create. The data project should allow 20, while every other project should allow 5. The governance team wants one copy of the policy code. How should this be implemented?
Select an answer to reveal the explanation.
Short Explanation
Write the rule once and give it a dial. A Sentinel param with a default is the dial, and each policy set can turn it to its own setting. Copies drift, and workspace names are something your users can change.
Full Explanation
Sentinel policies can declare parameters with the param keyword, optionally with a default value. In HCP Terraform, a policy set can define Sentinel parameters, key-value pairs sent to the Sentinel runtime when the set's policies are evaluated, and values that parse as JSON arrive as the matching type, such as an integer. Keeping one policy in the repository and attaching it to two policy sets, one scoped to the data project with the parameter set to 20 and another scoped to the remaining projects relying on the default of 5, gives different thresholds with a single copy of the logic. Copying the file with a hardcoded value duplicates the logic, so later fixes must be made twice and the copies drift apart. The tfrun import's variables value exposes each variable's name, category and sensitivity, not its value, so a policy cannot read a limit that way. Branching on the workspace name ties enforcement to a field that workspace administrators can edit, which HashiCorp's import documentation warns can bypass a policy; scoping policy sets is the recommended separation. Exam caveat: parameters are available only for Sentinel policies; OPA and Terraform policy have their own input mechanisms. Operational check: queue a plan creating 10 instances in a data workspace and in another project, and confirm only the second fails.