Sentinel is a policy-as-code framework that allows organisations to define, enforce, and automate compliance rules for infrastructure changes in Terraform Cloud and Terraform Enterprise. For the TF-003 exam, you need to understand that Sentinel is the gatekeeper that checks every infrastructure proposal against your organisation's rules before any cloud resources are created, changed, or destroyed.
Jump to a section
A simple way to picture Sentinel Policies and Governance in Terraform Enterprise
A block of flats has a shared mailroom where the postman delivers all packages and letters. The mailroom is the Terraform deployment system. Without rules, any resident could walk in, take any package, or put things in the wrong pigeonhole. This would lead to chaos, lost parcels, and angry neighbours.
To prevent this, the building manager establishes a set of written policies. These policies are Sentinel policies. One policy says, "Only residents whose names are on the lease may collect a package." Another says, "Packages heavier than 10 kg must be left in the secure storage room, not the regular pigeonhole." A third says, "All parcels must be logged in the register before they can be taken."
Every time a resident arrives to collect a package, a security guard reads the relevant policy and checks the situation against it. If the resident tries to collect a package addressed to someone else, the guard blocks the handover and sends a notification to the building manager. This is exactly what Sentinel does: it sits between the request to create or change infrastructure and the actual change. It checks the proposed infrastructure against the rules defined by the security team, compliance officer, or cloud architect. If the infrastructure violates a rule — for example, it tries to create a storage bucket in an unapproved region — Sentinel refuses the operation and logs the violation. The change is never made. The mailroom stays orderly because policies are enforced before anyone can act.
Sentinel is a policy-as-code framework built into HashiCorp’s commercial offerings: Terraform Cloud (the managed SaaS version) and Terraform Enterprise (the self-hosted version for large organisations). The term 'policy-as-code' means you write rules and conditions using a purpose-built programming language — the Sentinel language — rather than using a graphical interface or writing plain English policies that humans must interpret. Writing policies as code allows them to be version-controlled, tested, reviewed, and automatically enforced just like application code.
At its core, Sentinel solves a specific problem: how does a company ensure that every infrastructure change complies with its internal standards, industry regulations, and security best practices? Before Sentinel, organisations relied on manual reviews, peer approvals, or post-deployment audits. These approaches were slow, error-prone, and often missed violations until after a costly mistake had already occurred. Sentinel automates the checking process, blocking or warning about violations at the precise moment the change is proposed — before any resource is created.
Here is how it works in practice. A developer writes a Terraform configuration that defines, say, an Amazon EC2 instance. The developer runs 'terraform plan' to see what the configuration would create, then runs 'terraform apply' to execute the plan. In a Terraform Cloud or Enterprise organisation with Sentinel enabled, the apply does not proceed immediately. Instead, Terraform Cloud sends the proposed changes — the entire plan — to the Sentinel engine. The engine evaluates the plan against every policy that has been configured for the workspace. Each policy is a set of rules written in the Sentinel language. The engine returns one of three outcomes:
Pass: The change is compliant with all policies. The apply proceeds normally.
Soft fail (advisory): The policy is violated, but the organisation has configured the rule as advisory only. The apply proceeds, but a notification is sent to administrators. This is useful for policies that are recommended but not mandatory.
Hard fail (mandatory): The policy is violated and the rule is configured as mandatory. The apply is blocked immediately. The developer receives a clear error message stating which policy was violated and why. The change is never executed.
To understand the power of this, consider a real example. An organisation might write a Sentinel policy that says: "All storage buckets must have encryption enabled." A developer could, through oversight or inexperience, write a Terraform configuration that creates a bucket without encryption. Without Sentinel, that bucket would be created unencrypted, exposing sensitive data to anyone with access to the cloud account. With Sentinel, the apply would be blocked, and the developer would be forced to fix the configuration before the bucket could be created.
Sentinel policies can inspect any attribute of any resource in the Terraform plan. This includes:
Resource types (e.g., only allow certain approved types of virtual machines)
Resource names and tags (e.g., every resource must be tagged with a cost centre)
Network configurations (e.g., security groups must not allow inbound traffic from 0.0.0.0/0)
Geographical regions (e.g., resources may only be provisioned in approved cloud regions)
Instance sizes (e.g., only small or medium instances are allowed in development environments)
Any custom attribute exposed by the provider
Policies are organised into policy sets. A policy set is a collection of policies that target specific workspaces. For example, an organisation might have a policy set called 'PCI-Compliance' that applies to all workspaces handling payment card data, and a different policy set called 'Cost-Control' that applies to all development workspaces. This allows fine-grained control: different rules for different environments, teams, or workloads.
The Sentinel language itself is deliberately simple and focused. It is a functional language with a focus on filtering collections and making assertions. A typical policy might look something like this (simplified):
# Require all S3 buckets to have versioning enabled
import "tfplan/v2" as tfplan
all_buckets = tfplan.resource_changes["aws_s3_bucket"]
# For each bucket being created or modified
main = rule {
all_buckets all satisfies bucket_has_versioning
}
bucket_has_versioning = rule {
resource.change.after.versioning.status == "Enabled"
}This policy imports the Terraform plan data, finds every resource change involving an 'aws_s3_bucket', and then checks that each bucket has versioning set to 'Enabled'. If any bucket does not satisfy the rule, the policy fails.
It is important to distinguish between Sentinel policies and the 'terraform plan' itself. The plan is a dry-run of what Terraform intends to create, change, or destroy. Sentinel is a separate enforcement layer that runs on top of the plan, inspecting the planned state before the apply occurs. The plan is the blueprint; Sentinel is the building inspector who checks the blueprint against the building code before construction begins.
Sentinel also supports mock generation. During policy development, you can generate mock data — simulated plan data — to test your policies without actually running Terraform against a real cloud provider. This allows policy authors to iterate quickly and ensure correctness before deploying policies to production.
Finally, all policy checks produce logs. Every time a policy is evaluated, whether it passes or fails, the result is recorded in the organisation's audit trail. This provides a tamper-proof historical record of who tried to do what, and whether it was allowed or blocked. For compliance with regulations like SOC 2 or PCI DSS, this audit capability is critical.
Define Organisational Policies
The compliance team or cloud architect identifies the rules that all infrastructure must follow — for example, 'All storage buckets must be encrypted' or 'No resources may be created outside approved regions'. These rules are documented and become the source of truth for Sentinel policy writing.
Write Sentinel Policies as Code
A policy author writes each rule using the Sentinel language in a '.sentinel' file. For example, a policy to enforce encryption on S3 buckets would import the Terraform plan data and check the 'server_side_encryption_configuration' attribute of every 'aws_s3_bucket' resource. Multiple policies can be stored in a single directory.
Test Policies with Mock Data
The author generates a mock file — simulated plan data — using the 'sentinel test' command or the Terraform Enterprise mock generator. They run the policy against the mock to verify it catches violations and allows compliant configurations. This step catches logic errors before the policy is deployed to production.
Create a Policy Set in Terraform Cloud/Enterprise
The author uploads the policy directory to Terraform Cloud/Enterprise via the UI, API, or version control integration. They create a new policy set, give it a name (e.g., 'Prod-Security-Policies'), and specify which workspaces it should apply to using workspace tags or direct selection.
Link Policy Set to Workspaces
The policy set is associated with the target workspaces. For example, a policy set might be linked to all workspaces tagged with 'environment:production'. Future runs in those workspaces will automatically include Sentinel policy evaluation.
Run Terraform Plan and Apply with Policy Check
When a user runs 'terraform apply' in a linked workspace, Terraform Cloud generates a plan. Before the plan is applied, the Sentinel engine retrieves all policies in the associated policy sets, evaluates the plan against them, and returns pass, advisory, or mandatory results. If any mandatory policy fails, the plan is blocked.
Review Logs and Audit Trail
After the run completes (whether allowed or blocked), Terraform Cloud records the policy evaluation results in the run log. Administrators can review these logs for compliance reporting, incident investigation, or external audits. The logs show which policies were checked, the outcome, and the specific resources that triggered violations.
Imagine you are a cloud platform engineer at a multi-national bank called 'NexBank'. NexBank uses Terraform Enterprise to manage its cloud infrastructure across AWS and Microsoft Azure. The bank must comply with the Payment Card Industry Data Security Standard (PCI DSS), the General Data Protection Regulation (GDPR), and its own internal security policies.
Your first task is to design and deploy a Sentinel policy set for all production workspaces. You start by gathering requirements from the compliance team. They tell you that, according to PCI DSS, all data at rest must be encrypted. You also learn that, under GDPR, personal data must not leave the European Union. Your infrastructure team adds their own rule: no production virtual machine may have a public IP address.
You translate these requirements into Sentinel policies. You write a policy that inspects every 'aws_s3_bucket' resource and checks that 'server_side_encryption_configuration' is set. You write a second policy that checks that all resources are being created in the 'eu-west-1' or 'eu-central-1' regions, and blocks any resource destined for a non-EU region. You write a third policy that looks at every 'aws_instance' and 'azurerm_virtual_machine' resource and checks that the network interface has no association with a public IP.
You test these policies using the Sentinel mock generator. You create a mock file that simulates a plan containing a publicly accessible virtual machine in the United States. You run Sentinel against it. The policy correctly fails with a clear message indicating the region violation and the public IP violation. You fix the mock configuration, re-run, and the policy passes.
Now you need to apply the policy set to workspaces. In Terraform Enterprise, you navigate to the 'Policy Sets' page and create a new set called 'NexBank-Production-Compliance'. You upload the directory containing your policy files. You then link this policy set to every workspace that has 'production' in its name, using a workspace tag filter. All production workspaces now automatically enforce these rules.
The next day, a junior developer creates a new workspace for a production application. Unaware of the policies, they write a configuration that creates an EC2 instance in 'us-east-1' without encryption on the attached EBS volume. They run 'terraform plan' successfully. They see no warnings. Then they run 'terraform apply'. The Terraform Enterprise run gets to the 'policy check' phase and is blocked. The developer receives an error message in the Terraform Enterprise UI: "Policy 'encryption_required' failed. Reason: EBS volume 'prod-app-data' must have encryption enabled." A separate warning also appears: "Policy 'region_restriction' failed. Resource 'aws_instance.prod_app' is being created in 'us-east-1', not an approved region." The developer must change their configuration to set encryption to true and switch to an EU region before the apply can succeed.
As the platform engineer, you receive an automated notification about the failed run. You review the logs to confirm that the policy worked correctly. You also add a 'soft fail' policy that tags all resources with an owner email, because the business wants to encourage good tagging but does not want to block deployments over it.
Several months later, an external auditor requests proof that NexBank has enforced encryption on all storage resources for the past year. You generate a compliance report from Terraform Enterprise showing every run that was evaluated against the 'encryption_required' policy, along with the outcome of each evaluation. The auditor accepts this as evidence of ongoing compliance.
This scenario shows that Sentinel is not just a theoretical feature: it is a practical tool that directly translates business, legal, and security rules into automated gates. It saves organisations from costly mistakes, helps pass audits, and reduces the burden of manual review.
The TF-003 exam includes several questions that test your understanding of Sentinel policies. The exam does not ask you to write Sentinel code, but it does ask you to explain what Sentinel is, how it integrates with Terraform Cloud/Enterprise, and what the three enforcement levels are.
Here are the specific concepts you must know cold:
The three policy enforcement levels: 'mandatory' (hard fail — blocks the run), 'advisory' (soft fail — allows the run but logs a warning), and 'soft-mandatory' (also a hard fail, but with a different UI treatment — memorise this distinction if the exam mentions 'hard-mandatory' vs 'soft-mandatory'). The exam expects you to know that 'advisory' policies do not block the run but still generate logs.
The difference between policy sets and individual policies. A policy set is a collection of policies that are applied together to a set of workspaces. You can attach policy sets to workspaces using tags, direct association, or organisation-level enforcement. The exam may ask you to identify the correct method.
The fact that Sentinel evaluates policies against the plan, not the state. The plan is the proposed changes. Sentinel runs after the plan is generated but before the apply. This is a key distinction.
The concept of 'policy-as-code' — writing policies is a programming activity, not a documentation activity. Policies are stored in version control, tested with mocks, and deployed via CI/CD pipelines.
The difference between Sentinel and 'terraform validate' or 'terraform plan'. Terraform validate checks syntax. Terraform plan shows what will happen. Sentinel enforces organisational rules. Each serves a different purpose.
The exam loves to present confusing statements like: "Sentinel policies can be used to modify the Terraform configuration before apply." That is a trap. Sentinel cannot modify anything; it only inspects and either allows or blocks. Another trap: "Sentinel policies are evaluated against the current state of the infrastructure." Wrong — they are evaluated against the planned new state. Another common trap: "Sentinel is available in the open-source version of Terraform." Incorrect — Sentinel is a paid feature of Terraform Cloud and Terraform Enterprise.
You should also be able to identify a Sentinel policy from a description. For example, if a question describes a rule that checks every storage bucket for encryption, and states that it is written in a language called 'Sentinel', you must know that this is a Sentinel policy. The exam may ask you to select the correct service or tool that provides this capability.
Finally, memorise this sequence: Write Terraform configuration -> Run 'terraform plan' -> Terraform generates plan -> Sentinel engine evaluates plan against policies -> If all mandatory policies pass, apply proceeds -> If any mandatory policy fails, apply is blocked and error returned.
Sentinel is a policy-as-code framework that enforces rules on Terraform plans before the apply executes, acting as a pre-deployment gatekeeper.
The three enforcement levels are mandatory (hard fail, blocks the run), advisory (soft fail, logs a warning but allows the run), and soft-mandatory (hard fail with different UI treatment).
Sentinel evaluates policies against the planned state (the output of 'terraform plan'), not the current state or the final state after apply.
Policies are organised into policy sets, which can be assigned to workspaces using tags, direct association, or at the organisation level.
Sentinel is only available in Terraform Cloud and Terraform Enterprise; it is not included in the open-source Terraform CLI.
Sentinel cannot modify infrastructure configurations; it only inspects and either allows or blocks the proposed changes.
All Sentinel policy evaluations are logged, providing an audit trail for compliance with regulations such as PCI DSS and SOC 2.
These come up on the exam all the time. Here's how to tell them apart.
Sentinel
Enforces organisational compliance rules (e.g., encryption must be on).
Evaluates the plan (proposed changes) against custom policies.
Only available in Terraform Cloud/Enterprise (paid).
Terraform Validate
Checks Terraform configuration syntax is valid.
Does not examine planned resource attributes like encryption settings.
Available in the open-source Terraform CLI (free).
Mandatory Policy (Hard Fail)
Blocks the run if violated; the resource is never created.
Generates an error that stops the apply process.
Used for security or compliance rules that must never be broken.
Advisory Policy (Soft Fail)
Allows the run to proceed even if violated; only a warning is logged.
Generates a warning in the run log but does not stop the apply.
Used for recommendations or best practices that are not enforced.
Policy Set
A collection of Sentinel policies grouped together.
Can be assigned to multiple workspaces via tags or direct selection.
Defines the rules that must be followed during infrastructure changes.
Workspace Tag
A label applied to workspaces for categorisation (e.g., 'env:prod').
Used to determine which policy sets apply to a workspace.
Does not contain policies; it is a metadata key for filtering.
Plan (terraform plan)
A representation of the proposed changes to infrastructure.
Generated before the apply step.
Is what Sentinel evaluates against.
State (terraform state)
A representation of the current, actual infrastructure.
Updated after a successful apply.
Is not directly evaluated by Sentinel (though Sentinel can inspect it via import).
Mistake
Sentinel policies are written in HCL (HashiCorp Configuration Language), the same language used to write Terraform configurations.
Correct
Sentinel policies are written in the Sentinel language, which is a separate, purpose-built policy-as-code language. HCL is for defining infrastructure; Sentinel is for defining rules about that infrastructure.
Both tools come from HashiCorp and are used together in Terraform Cloud/Enterprise, so beginners naturally assume they share the same language. The exam tests this distinction directly.
Mistake
Sentinel policies can only be used to block changes (hard fail).
Correct
Sentinel supports three enforcement levels: mandatory (hard fail), advisory (soft fail — logs a warning but does not block), and soft-mandatory (also a hard fail but with different UI handling). Advisory policies are common for non-critical recommendations.
Many tutorials focus on the blocking capability because it is dramatic, but the exam asks about all three levels. Test-takers often forget about advisory mode.
Mistake
Sentinel policies are evaluated after the Terraform apply has completed, as a post-deployment audit check.
Correct
Sentinel policies are evaluated against the plan before the apply occurs. They are a pre-deployment gate, not a post-deployment audit. The audit happens after via logs, but the policy check itself is before.
People familiar with traditional compliance checks (which happen after the fact) assume Sentinel follows the same pattern. The opposite is true: Sentinel is a preventative control, not a detective one.
Mistake
Sentinel policies can only be applied at the organisation level and cannot target specific workspaces.
Correct
Sentinel policies are organised into policy sets, which can be assigned to specific workspaces via tags, direct association, or as organisation-wide policies. This provides fine-grained control.
Early documentation emphasised organisation-wide policies, and beginners do not realise that workspace-level targeting is the more common and flexible approach.
Mistake
Sentinel can modify the Terraform configuration to make it compliant.
Correct
Sentinel can only inspect and either allow or block. It cannot change the configuration. The developer must manually fix the configuration to meet policy requirements.
People hear 'automated compliance' and imagine automatic fixes, but Sentinel is a gate, not a fixer. This misconception is often tested in exam scenarios where a question implies Sentinel can auto-correct violations.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. Sentinel is a paid feature available only in Terraform Cloud (the SaaS version) and Terraform Enterprise (the self-hosted version). The open-source Terraform CLI does not support Sentinel.
Yes. If a policy is set to 'mandatory' (hard fail) and the plan violates it, the apply is blocked completely. The error message tells you which policy failed and why.
Advisory (soft fail) means the policy is checked and a warning is recorded, but the apply still proceeds. Mandatory (hard fail) means the policy blocks the apply entirely if violated.
No. The exam tests your conceptual understanding of Sentinel — what it is, how it enforces compliance, the three enforcement levels, and how it integrates with Terraform Cloud/Enterprise. You will not be asked to read or write Sentinel code.
No. Sentinel can only inspect and either allow or block a change. It cannot modify the Terraform configuration. The developer must manually correct the configuration to comply with the policy.
You can use the Sentinel command-line tool to run tests against mock data files, which simulate what a real Terraform plan would look like. This lets you verify that your policy correctly identifies violations before you put it into production.
The run is blocked (if mandatory) or proceeds with a warning (if advisory). The run log shows the exact policy name, the failure reason, and the specific resources that failed. The user can then fix the configuration and re-run.
You've finished Sentinel Policies and Governance in Terraform Enterprise. Continue through the TF-003 study guide to build a complete picture of the exam.
Done with this chapter?