Policy Enforcement using Sentinel OPA Part 2

Understanding enforcement levels and how policies are organized is essential for managing policy checks in HCP Terraform. This article explains enforcement levels for Sentinel and OPA, how to organize policies into policy sets, what policies can and cannot do, and key exam-focused takeaways.

​

Enforcement levels

Sentinel provides three enforcement levels that control what happens when a policy fails:

• Advisory — failed policies emit a warning but the run continues. Use this to introduce policies without breaking workflows.
• Soft-mandatory — a failed policy blocks the run, but authorized users can override the failure. Overrides are audited.
• Hard-mandatory — a failed policy blocks the run with no override option. Use this for non-negotiable controls (e.g., regulatory or critical security controls).

OPA (Open Policy Agent) uses a simpler model:

• Advisory — warning only; the run continues.
• Mandatory — a failed policy stops the run. Note: in HCP Terraform, OPA’s mandatory level can be overridden by users who have the required override permission, so in practice it can behave like Sentinel’s soft-mandatory in environments where that permission is granted.

Comparison: Sentinel vs OPA enforcement levels In short: Sentinel exposes three distinct levels; OPA provides two, and HCP Terraform permissions determine whether OPA’s mandatory checks are truly non-overrideable.

​

Organizing policies in HCP Terraform

You normally author policies inside your HCP Terraform organization. It’s common to use both Sentinel and OPA policies together, but grouped appropriately. Example policy names you might author:

• Sentinel policies:
  • sent_require_mandatory_tags
  • sent_restrict_instance_types
  • sent_enforce_s3_encryption
• OPA policies:
  • opa_block_public_ingress
  • opa_limit_auto_apply

After authoring, policies are not attached directly to workspaces. Instead, group related policies into policy sets, and assign those policy sets to projects or workspaces.

• A policy set is a container for related policies (for example: security policies, cost policies).
• Policy sets can be scoped to a whole project or to specific workspaces.
• You can exclude particular workspaces from a global policy set to allow exceptions.
• Policy sets can be managed via the UI, VCS, or the API.

Example organization:

• Sentinel security policy set: contains Sentinel security policies.
• OPA security policy set: contains OPA policies.

Important: a policy set can contain policies from only one framework — you cannot mix Sentinel and OPA policies in the same set. However, you may attach both a Sentinel policy set and an OPA policy set to the same workspace so both frameworks run during the Terraform run.

​

What policies can — and cannot — enforce

Policies operate at plan/apply time. They are powerful for enforcing rules before resources are created, but they have limitations. What policies can do:

• Block public S3 buckets by inspecting the plan and detecting a public ACL or policy.
• Restrict instance types — e.g., allow only t3.medium and t3.large.
• Enforce tagging requirements — e.g., require team, environment, and cost_center tags on resources.
• Limit allowed regions — e.g., permit only us-east-1 and eu-west-1.
• Enforce cost controls — Sentinel policies can reference cost estimation data to implement spending guardrails.

What policies cannot do:

• Continuously monitor resources after deployment. Policies run during Terraform runs; they do not provide ongoing, continuous compliance monitoring.
• Remove or remediate already-deployed violating resources. Policies prevent new violations but do not delete existing noncompliant infrastructure.
• Guarantee that an external referenced attribute exists. For example, a policy can require a KMS key identifier be provided, but it cannot verify that the KMS key exists in the cloud provider without an external data lookup or runtime verification.
• Confirm provider-specific availability. A policy can assert the instance type must be t3.medium, but it will not query the provider to confirm t3.medium is available in the target region.
• Observe runtime application behavior. Policies validate provisioning-time properties; they do not analyze runtime application behavior after deployment.

You can summarize capabilities in a quick reference:

​

Summary and key exam notes

• Policies run after the plan phase and before apply, catching issues before infrastructure is created.
• HCP Terraform supports both Sentinel and OPA (Rego) frameworks.
• Sentinel supports advisory, soft-mandatory, and hard-mandatory enforcement levels. OPA supports advisory and mandatory; the latter can be overridden in HCP Terraform by users with the appropriate override permission.
• Policy sets are the unit assigned to projects or workspaces; each set must contain policies from a single framework.
• Overrides require a specific HCP Terraform permission and are audited.

In an exam context you will not be asked to write Sentinel or Rego code. Expect higher-level questions about how the frameworks operate, enforcement levels, policy sets, and the practical limits of policy enforcement.

​

Links and references

• Sentinel documentation — https://www.terraform.io/cloud-docs/sentinel
• Open Policy Agent (OPA) — https://www.openpolicyagent.org/
• HCP Terraform — https://www.terraform.io/cloud
• OPA Rego language — https://www.openpolicyagent.org/docs/latest/policy-language/