What is HashiCorp Sentinel and How Does It Enforce Policy?
Learn what HashiCorp Sentinel is, its advisory/soft/hard-mandatory levels, and how it enforces policy in Terraform pipelines.
Expected Interview Answer
HashiCorp Sentinel is a policy-as-code framework embedded across the HashiCorp toolchain — Terraform Cloud/Enterprise, Vault, Consul, and Nomad — that evaluates policies written in its own Sentinel language against a run’s context (such as a Terraform plan) and enforces one of three tiers: advisory, soft-mandatory, or hard-mandatory.
A Sentinel policy imports the tool-specific data it needs — for Terraform, the `tfplan/v2` import exposes planned resource changes — and writes rules that must evaluate to true for the policy to pass, such as ensuring every `aws_instance` has a `Name` tag or that no security group opens port 22 to the world. The three enforcement levels give organizations graduated control: advisory policies log a warning but never block a run, soft-mandatory policies block the run but can be overridden by an authorized user, and hard-mandatory policies block unconditionally with no override path, typically reserved for the most critical guardrails like preventing deletion of a production state resource. Because Sentinel is tightly integrated into Terraform Cloud/Enterprise’s run pipeline, policies execute automatically between the plan and apply stages without requiring extra pipeline wiring, unlike OPA which is a general-purpose engine that must be integrated manually into whatever system calls it. This tight coupling is Sentinel’s main tradeoff versus OPA: less flexible across non-HashiCorp tools, but effectively zero-configuration policy enforcement within the HashiCorp ecosystem itself.
- Three-tier enforcement (advisory, soft-mandatory, hard-mandatory) gives graduated control
- Native integration into Terraform Cloud/Enterprise run pipeline, no extra wiring
- Policies can inspect the full planned resource diff before apply
- Consistent policy language reused across Terraform, Vault, Consul, and Nomad
AI Mentor Explanation
Sentinel is like a cricket board’s built-in match-referee system that is wired directly into the official scoring software itself, rather than a separate app someone has to remember to open. A minor infraction, like a slow over-rate, triggers only a logged warning — advisory. A more serious one, like a suspect bowling action, halts play but the match referee can personally override it after review — soft-mandatory. The most serious, like a doping violation, ends the player’s involvement immediately with no override possible — hard-mandatory. Because it is built into the official scoring system, no ground has to separately install or configure it.
Step-by-Step Explanation
Step 1
Author the Sentinel policy
Import `tfplan/v2` (or Vault/Consul/Nomad equivalents) and write rules that must evaluate to true.
Step 2
Attach to a policy set
Group policies into a policy set and associate it with the relevant Terraform Cloud/Enterprise workspace.
Step 3
Choose an enforcement level
Set advisory (log only), soft-mandatory (blockable, overridable), or hard-mandatory (blocking, no override) per policy.
Step 4
Run automatically between plan and apply
Sentinel evaluates every run natively in the pipeline before apply is allowed to proceed.
What Interviewer Expects
- Knowledge of the three enforcement levels: advisory, soft-mandatory, hard-mandatory
- Understanding that Sentinel runs natively inside Terraform Cloud/Enterprise pipelines
- Awareness that Sentinel spans Terraform, Vault, Consul, and Nomad
- Ability to contrast Sentinel (embedded, HashiCorp-only) with OPA (general-purpose, must be integrated manually)
Common Mistakes
- Confusing Sentinel enforcement levels or omitting the override behavior of soft-mandatory
- Assuming Sentinel works outside the HashiCorp product ecosystem
- Not knowing Sentinel inspects the plan (`tfplan/v2`) rather than raw HCL source
- Treating Sentinel and OPA as functionally identical without noting the integration tradeoff
Best Answer (HR Friendly)
“Sentinel is HashiCorp’s built-in policy engine for Terraform Cloud and Enterprise — it automatically checks every infrastructure plan against our rules before it can be applied. We can set rules as just a warning, as blockable-but-overridable, or as a hard stop with no way around it, which lets us match the level of enforcement to how critical each rule actually is.”
Code Example
import “tfplan/v2” as tfplan
instances = filter tfplan.resource_changes as _, rc {
rc.type is “aws_instance” and
rc.mode is “managed” and
(rc.change.actions contains “create” or rc.change.actions contains “update”)
}
main = rule {
all instances as _, i {
i.change.after.tags.Name else "" is not ""
}
}Follow-up Questions
- When would you use soft-mandatory instead of hard-mandatory enforcement?
- How does Sentinel differ from OPA in terms of integration effort?
- How would you test a Sentinel policy before enforcing it in a real workspace?
- What tfplan/v2 data can a Sentinel policy inspect besides resource tags?
MCQ Practice
1. Which Sentinel enforcement level blocks a run but allows an authorized override?
Soft-mandatory policies block the run by default but permit an authorized user to override and proceed anyway.
2. Where does Sentinel primarily run in the Terraform workflow?
Sentinel is embedded in the Terraform Cloud/Enterprise run pipeline and automatically evaluates policies between plan and apply.
3. What is a key tradeoff of Sentinel compared to Open Policy Agent?
Sentinel offers zero-configuration enforcement within HashiCorp tools but is less flexible outside that ecosystem than the general-purpose OPA.
Flash Cards
What is HashiCorp Sentinel? — A policy-as-code framework embedded in Terraform Cloud/Enterprise, Vault, Consul, and Nomad.
Name Sentinel's three enforcement levels. — Advisory, soft-mandatory, hard-mandatory.
What import exposes Terraform plan data to Sentinel? — `tfplan/v2`.
How does Sentinel differ from OPA in integration? — Sentinel runs natively inside HashiCorp pipelines; OPA is general-purpose and must be manually integrated.