How do you implement Sentinel policies in Terraform Enterprise to enforce compliance in a regulated bank?

Think of Sentinel as a building code inspector who reviews blueprints before construction begins. The architect (engineer) designs the building (infrastructure), submits the blueprints (Terraform plan) to the inspector (Sentinel), and construction (apply) only proceeds if the blueprints comply with all building codes (policies). Unlike a human inspector who might miss details or be inconsistent, Sentinel checks every single blueprint against every single code — automatically, consistently, and without exception.

Sentinel policies in Terraform Enterprise evaluate the Terraform plan, state, and configuration before an apply is permitted. Each policy is a code file written in the Sentinel language that imports Terraform plan data and applies boolean logic to determine pass or fail. Policies are organized into policy sets, and each set is attached to specific workspaces. For a bank, you might have a 'pci-dss-mandatory' policy set attached to all production workspaces, a 'cost-governance' set attached to all workspaces, and a 'network-segmentation' set attached to networking workspaces. Policy sets reference a Git repository, so policies are version-controlled, peer-reviewed, and have their own CI/CD lifecycle.

PCI-DSS compliance policies are the cornerstone for banking. These include: all storage resources (S3, EBS, RDS, EFS) must have encryption at rest enabled using customer-managed KMS keys (not AWS-managed keys), no security group rules can allow ingress from 0.0.0.0/0 on any port, all RDS instances must have automated backups with a minimum 7-day retention, all CloudTrail logs must be enabled and sent to a centralized logging account, all EC2 instances must be deployed in private subnets (no public IP assignment), and all load balancers must have access logging enabled. Each of these requirements becomes a Sentinel policy that evaluates the Terraform plan and blocks the apply if any resource violates the rule.

Sentinel enforcement levels create a tiered governance model. Hard-mandatory policies cannot be overridden by anyone — they represent non-negotiable regulatory requirements like encryption at rest. Soft-mandatory policies can be overridden by workspace administrators with a documented reason — useful for temporary exceptions during migrations or emergency fixes. Advisory policies log warnings but do not block applies — useful for best practices that are not yet mandatory, like tagging standards for new cost centers. In banking, most PCI-DSS policies are hard-mandatory, cost governance policies are soft-mandatory (to allow approved exceptions for high-performance workloads), and new policy rollouts start as advisory for a sprint to identify false positives before becoming mandatory.

Writing effective Sentinel policies requires understanding the Terraform plan structure. The tfplan/v2 import provides access to all resource changes (creates, updates, deletes), their before and after values, and the provider configuration. Policies filter resources by type (aws_s3_bucket, aws_db_instance), then assert conditions on their attributes. For complex policies, you can use Sentinel modules — reusable functions shared across policies. For example, a 'require_tags' module that checks for mandatory tags (cost-center, owner, data-classification, compliance-scope) can be imported by multiple policies. Testing Sentinel policies uses the sentinel test command with mock Terraform plan data, ensuring policies behave correctly before deployment.

The biggest gotcha is policy sprawl and maintenance burden. As the organization adds more policies, engineers face longer feedback cycles — waiting for 50 policies to evaluate on every plan. Keep policies focused and fast by using resource-type filters early in the policy to skip irrelevant resources. Another gotcha is false positives — a policy that blocks legitimate infrastructure changes erodes trust in the governance system and leads to engineers finding workarounds. Invest in thorough policy testing with both passing and failing plan fixtures. Test edge cases like resource updates (not just creates), data sources, and resources managed by different providers. Finally, communicate policy changes clearly — when a new hard-mandatory policy is introduced, give teams a sprint to remediate existing infrastructure before enforcement begins.