Sentinel Policies in Terraform Platforms

Sentinel puts an approval decision next to the infrastructure plan

Sentinel is a policy-as-code framework that can evaluate Terraform runs in HashiCorp's managed Terraform platforms. Instead of relying only on reviewers to notice a public database or an unapproved instance family, an organization can define a policy and evaluate the planned infrastructure before apply. The policy reads Terraform run data through Sentinel imports and tests an invariant, such as requiring encryption or restricting deployment to approved regions. The plan result remains reviewable, and a failed mandatory policy can stop the run.

A policy set groups one or more policy files and associates them with workspaces or projects. Scope determines where a control applies. A baseline security policy may be assigned broadly, while a team-specific cost or naming rule can target selected workspaces. Use scopes that follow ownership and risk. A global policy set is easy to apply consistently but can produce confusing findings if it assumes every workspace uses the same resource conventions. A narrowly scoped set may miss a workspace if nobody maintains the assignment.

Policy evaluation happens as part of a managed run workflow, where Sentinel can inspect plan data and platform context. That integration is different from running a local HCL linter. The policy can reason about proposed changes and, depending on its imports and configured policy evaluation mode, additional data supported by the platform. Do not assume a policy can access arbitrary cloud APIs or hidden workspace values. Use only supported inputs, document the data contract, and test behavior against representative plans.

The policy body expresses the rule; enforcement level controls what happens when it fails. Sentinel defines three levels. Advisory reports failure but allows the run to continue. Soft-mandatory blocks unless a permitted user or process overrides it. Hard-mandatory blocks and cannot be overridden through the normal policy override flow; the policy must pass or be removed through an administrative change. The enforcement level is configured when a policy is attached to a platform, not encoded as a branch inside the policy logic. See Sentinel enforcement levels for the precise platform semantics.

Use advisory first for a new policy when the organization needs to discover false positives and missing context. Move to soft-mandatory when the control should block by default but an accountable exception is appropriate. Reserve hard-mandatory for controls where an override is not acceptable, such as a legal or safety requirement. If an organization-level policy set is configured to allow overrides, verify how that setting interacts with the configured enforcement level in the platform version and workflow. Do not promise that ?hard? is impossible to override in every configuration; understand the policy set's override settings and platform-specific behavior.

A useful policy message identifies the resource or workspace, the failed condition, and a remediation path. ?Instance type is not in the approved list? is actionable; ?rule returned false? is not. If the plan contains multiple violations, aggregate them so an author can fix several issues before rerunning. Avoid printing secret values or excessive plan data. The run UI should make it clear which policies passed, which failed, and whether an override was used.

A common example is an approved instance family. The policy can examine planned resource values, compare the instance type with an approved set, and deny disallowed configurations. Another example requires a set of tags. In both cases, decide how to handle unknown values: if the plan cannot establish compliance, fail with a clear message or route it to a deliberate review. Treating unknown as allowed may defeat the control.

In an interview, connect the three parts: a Sentinel policy expresses an invariant, a policy set scopes it to workspaces, and an enforcement level controls run behavior. Then explain how you roll it from advisory to mandatory and handle exceptions. This demonstrates how policy code becomes an operational gate.

Keep policy repositories under version control and review changes that weaken a rule. A policy bundle is production code: a syntax error can disrupt runs, and a logical error can allow a risky change. Use local tests or the Sentinel test framework with mock imports where possible, then run the policy against representative plans in a nonproduction workspace. Review the resulting policy output before enforcing it broadly.

Match enforcement strength to the consequence of a violation

Advisory policies are useful for discovery. They surface warnings without stopping a run, which gives teams time to identify false positives and improve modules. The downside is that repeated warnings can be ignored. Report the finding, owner, and expected remediation date, then review whether the rule is ready for stronger enforcement. Advisory is not a permanent substitute for a control that must block an unsafe deployment.

Soft-mandatory policies block a run by default but support an override by an authorized actor or through platform configuration. The override should record who accepted the risk and why. This is appropriate when a violation may be justified for a migration, incident response, or approved exception. Define who can override and what evidence they need. If every developer can override without explanation, the policy is effectively advisory. If no one can override, hard-mandatory may communicate the intent more honestly.

Hard-mandatory means the policy must pass under the normal enforcement model. It is appropriate when any violation is unacceptable and the organization does not allow a routine override. A hard rule can still require an administrative policy or policy-set change to proceed, so protect that administrative path with review and audit logging. If an emergency procedure exists, document it separately and make the exceptional action visible. Be precise about whether the HCP Terraform or Terraform Enterprise policy-set configuration permits overrides, because platform-level settings can affect enforcement behavior.

Policy scope should reflect the control. A policy requiring encryption might apply to every workspace that manages a supported storage type. A naming convention may apply only to one product or account. Avoid binding policies to workspace names as a substitute for stable ownership metadata. Use workspace tags, project boundaries, or policy-set assignments that are maintained as teams and environments change. Review policy-set membership during workspace creation and decommissioning.

Organization-wide policies need reusable data and careful tests. An approved list of regions or instance types can be a data file that changes through a reviewed process. Keep the data versioned and record its owner. Do not fetch mutable external data during every evaluation unless the policy system supports that safely; a transient network failure should not create unpredictable policy decisions. If the allowed set is time-sensitive, define how updates are tested and communicated.

Policy output is part of the developer experience. Return a concise violation per resource and avoid noisy duplicate failures. Include resource addresses and the relevant non-sensitive attribute. If one policy produces dozens of issues, aggregate by type or limit output while keeping the full report available to authorized users. A policy that blocks changes without explaining how to comply encourages bypasses and emergency override requests.

A safe rollout starts with test cases, then advisory evaluation in representative workspaces. Measure how often the rule fails and classify each failure as real risk, missing module support, or false positive. Fix common module patterns and documentation before making enforcement mandatory. Move to soft-mandatory for controls with legitimate exceptions and hard-mandatory for non-negotiable invariants. A change to enforcement level is itself a governance change and should be reviewed.

Policy testing should cover allowed and denied values, missing attributes, unknown plan values, deletes, replacements, and module-qualified resources. Mock the imports used by the policy and run tests before publishing the policy set. A policy can be syntactically valid but logically inverted, so include a known violating case that must fail. Test policy-set scope with a workspace that should be included and one that should not.

In an interview, explain why one enforcement level does not fit every rule. Discuss warnings during rollout, auditable overrides for legitimate exceptions, and hard requirements where exceptions are not acceptable. Mention that scope and override permissions are platform configuration, not simply code inside the policy. This is the judgment that keeps policy enforcement useful rather than punitive.

A policy check needs an owner and a recovery path

When a Sentinel policy blocks a run, the first response is to understand the planned change and policy result. Identify the resource address, condition, and relevant plan values. If the configuration violates the rule, change the HCL or request the documented override. If the rule is incorrect, fix the policy through its reviewed release process. Do not edit workspace values or remove the policy ad hoc to get an apply through; that creates an unreviewed governance gap.

Overrides should preserve accountability. Record the reason, affected workspace and resource, approver, and any compensating control. A time-bound exception should include an expiry or follow-up issue. Review overrides regularly to find a policy that is too strict or a module pattern that needs a safe abstraction. For hard-mandatory rules, the administrative path to change or remove the policy should be narrower than ordinary workspace permissions and should leave an audit trail.

Test platform behavior before relying on a policy enforcement level for a critical control. Sentinel policy semantics are defined by the Sentinel framework, while the managed platform adds policy set settings and user permissions. Verify whether an override can proceed under the organization's configuration and whether policy evaluations and policy checks behave differently in the selected workflow. A policy that passed a local test may still be assigned to the wrong workspace or run with unexpected platform inputs.

Run platform upgrades and Sentinel runtime changes in a controlled sequence. Pin or track supported runtime behavior according to the platform configuration. Test policies against representative workspaces and plan changes before enabling the new runtime or changing imports. Update fixtures when Terraform plan data or provider behavior changes. If a policy depends on an import that is unavailable or changes shape, make the failure visible and block safely rather than silently skipping the rule.

Keep credentials and data access separate. Sentinel evaluates policy in the platform run context; do not place provider secrets in policy source or emit them in error messages. Limit access to policy repositories and policy-set administration. Review who can edit policy code, assign a policy set, change its enforcement, and override failures. These are distinct powers and may deserve separate roles so one actor cannot weaken a rule and bypass the run gate without review.

Policies should not duplicate every resource check in other tools without a reason. Static scanners can give fast source feedback, while Sentinel evaluates managed runs and can block plan progression. Cloud configuration monitoring detects changes made outside Terraform. Cost controls evaluate pricing data when supported by the selected policy workflow. Assign each control to a stage and define which one is authoritative. Duplicate rules can be helpful for defense in depth but confusing if they use different severity or exception behavior.

When a policy blocks an incident fix, the organization still needs a safe route to restore service. Define emergency policy procedures before an incident, including which conditions can be overridden, who approves, and what retrospective review follows. A critical outage may justify an auditable soft-mandatory override, while a hard-mandatory legal constraint should remain enforced. This distinction should be intentional rather than decided under pressure.

An operational dashboard can track policy pass rates, override frequency, most common violations, and stale exceptions. These metrics help identify friction but should not reward teams for suppressing findings. Pair them with remediation time and control coverage. A high pass rate may mean the policy is effective or that it is scoped to very few workspaces; measure assignment coverage too.

In an interview, describe a blocked run from diagnosis through resolution: inspect the plan and violation, fix or request a governed override, then verify the new policy result before apply. Include how you test a new rule and audit changes to policy scope. This makes clear that a policy gate is part of deployment operations, not a static file left unattended.

Use OPA and Conftest Policy Gates for a self-managed plan JSON workflow, and Pull Request Workflow Gates for repository branch protection. Sentinel is valuable when its managed-run integration and policy administration model fit the organization; a local OPA check may be more appropriate for a pipeline that needs a portable policy engine outside the managed Terraform platform.