Why Sentinel policy as code in Terraform? - Purpose & Use Cases

The Big Idea

What if your cloud could police itself and stop mistakes before they happen?

The Scenario

Imagine you manage cloud resources for your company. Every time someone creates or changes resources, you have to check manually if they follow the rules. You open spreadsheets, emails, and chat messages to verify compliance. This takes hours and is easy to miss.

The Problem

Manual checks are slow and tiring. People can forget steps or make mistakes. If a rule is missed, it can cause security risks or extra costs. Fixing errors later wastes even more time and money.

The Solution

Sentinel policy as code lets you write rules in code that automatically check your cloud changes. It runs every time you update resources, stopping bad changes before they happen. This saves time, reduces errors, and keeps your cloud safe.

Before vs After

✗ Before

Check each resource manually in spreadsheets and emails.

✓ After

policy "check_tags" { rule = all resources have tags }

What It Enables

It makes cloud governance automatic, consistent, and fast, so your team can focus on building instead of policing.

Real Life Example

A company uses Sentinel policies to block any cloud server without proper security tags, preventing accidental exposure of sensitive data.

Key Takeaways

Manual cloud policy checks are slow and error-prone.

Sentinel policy as code automates and enforces rules consistently.

This leads to safer, faster, and more reliable cloud management.

Practice

1. What is the main purpose of a Sentinel policy in Terraform?

easy

A. To enforce rules that control changes to cloud infrastructure

B. To write Terraform configuration files

C. To deploy cloud resources automatically

D. To monitor cloud resource usage

Solution

1. Step 1: Understand Sentinel policy role

   Sentinel policies are designed to enforce rules and guardrails on infrastructure changes.

2. Step 2: Differentiate from other Terraform tasks

   Writing configs and deploying resources are Terraform tasks, not Sentinel's role.

3. Final Answer:

   To enforce rules that control changes to cloud infrastructure -> Option A

4. Quick Check:

   Sentinel policy = enforce rules [OK]

Hint: Sentinel = rules to control changes, not deployment [OK]

Common Mistakes:

• Confusing Sentinel with Terraform configuration writing
• Thinking Sentinel deploys resources
• Assuming Sentinel monitors usage

2. Which of the following is the correct way to start a Sentinel policy block?

easy

A. sentinel policy example {

B. policy "example" {

C. policy example {

D. policy "example" = {

Solution

1. Step 1: Recall Sentinel policy syntax

   Sentinel policies start with the keyword 'policy' followed by the policy name in quotes and curly braces.

2. Step 2: Compare options

   policy "example" { matches the correct syntax: policy "example" { ... }

3. Final Answer:

   policy "example" { -> Option B

4. Quick Check:

   Correct Sentinel block start = policy "name" { [OK]

Hint: Policy name must be in quotes after 'policy' keyword [OK]

Common Mistakes:

• Omitting quotes around policy name
• Using '=' instead of '{' to start block
• Adding extra keywords like 'sentinel'

3. Given this Sentinel policy snippet:

policy "check_tags" {
  main = rule {
    all tfplan.resource_changes as _, rc {
      rc.change.after.tags contains "environment"
    }
  }
}

What does this policy check?

medium

A. All resources must have a tag named "environment"

B. At least one resource must have a tag named "environment"

C. No resource should have a tag named "environment"

D. Resources can have any tags without restriction

Solution

1. Step 1: Analyze the 'all' keyword usage

   The policy uses 'all' to check every resource change in the plan.

2. Step 2: Understand the condition

   It requires each resource's tags to contain the key "environment".

3. Final Answer:

   All resources must have a tag named "environment" -> Option A

4. Quick Check:

   all resources have "environment" tag = All resources must have a tag named "environment" [OK]

Hint: 'all' means every resource must meet condition [OK]

Common Mistakes:

• Confusing 'all' with 'any' keyword
• Thinking it checks only one resource
• Ignoring the 'contains' check on tags

4. Identify the error in this Sentinel policy snippet:

policy "check_region" {
  main = rule {
    all tfplan.resource_changes as _, rc {
      rc.change.after.region is "us-east-1"
    }
  }
}

medium

A. The 'main' rule must be a function, not a rule

B. Missing 'all' or 'any' keyword before the loop

C. Policy name must not be in quotes

D. Incorrect use of 'is' instead of '==' for comparison

Solution

1. Step 1: Check comparison operator

   Sentinel uses '==' for equality, not 'is'. 'is' causes syntax error.

2. Step 2: Verify other parts

   The loop uses 'all' correctly. Policy name requires quotes. 'main = rule { }' is standard syntax.

3. Final Answer:

   Incorrect use of 'is' instead of '==' for comparison -> Option D

4. Quick Check:

   Use '==' for equality in Sentinel [OK]

Hint: Use '==' for equality, not 'is' in Sentinel [OK]

Common Mistakes:

• Using 'is' instead of '==' for comparisons
• Thinking policy name cannot be quoted
• Confusing rule and function syntax

5. You want to write a Sentinel policy that blocks any Terraform plan which tries to create an AWS EC2 instance without a tag named "owner". Which approach correctly enforces this?

hard

A. Use 'any' to check if any resource has 'owner' tag and allow plan if true

B. Check only the first resource's tags for 'owner' and ignore others

C. Use 'all' to check every resource of type 'aws_instance' has 'owner' tag in 'after' changes

D. Allow plan if no resources are of type 'aws_instance'

Solution

1. Step 1: Identify the requirement

   Policy must block plans creating EC2 instances missing 'owner' tag.

2. Step 2: Choose correct logic

   'all' ensures every EC2 instance resource has the 'owner' tag in the planned changes.

3. Step 3: Evaluate other options

   'any' would allow plans if just one has the tag, which is unsafe. Checking only first resource misses others. Allowing plans with no EC2 instances is unrelated to the requirement.

4. Final Answer:

   Use 'all' to check every resource of type 'aws_instance' has 'owner' tag in 'after' changes -> Option C

5. Quick Check:

   All EC2 instances must have 'owner' tag = Use 'all' to check every resource of type 'aws_instance' has 'owner' tag in 'after' changes [OK]

Hint: 'all' enforces every EC2 instance has the tag [OK]

Common Mistakes:

• Using 'any' instead of 'all' allowing missing tags
• Checking only one resource instead of all
• Ignoring resource type filtering