Sentinel policy as code in Terraform - Time & Space Complexity

Time Complexity: Sentinel policy as code

O(n)

Understanding Time Complexity

We want to understand how the time to check policies grows as we add more rules or resources.

How does the number of policy checks change when the input grows?

Scenario Under Consideration

Analyze the time complexity of this Sentinel policy check in Terraform.

policy "example" {
  rule "check_tags" {
    all resources as r {
      r.tags contains "environment"
    }
  }
}
    

This policy checks that every resource has an "environment" tag.

Identify Repeating Operations

Look at what repeats when the policy runs.

• Primary operation: Checking each resource's tags for the "environment" key.
• How many times: Once for every resource in the plan.

How Execution Grows With Input

As the number of resources grows, the number of checks grows too.

Input Size (n)	Approx. API Calls/Operations
10	10 checks
100	100 checks
1000	1000 checks

Pattern observation: The checks grow directly with the number of resources.

Final Time Complexity

Time Complexity: O(n)

This means the time to run the policy grows in a straight line as you add more resources.

Common Mistake

[X] Wrong: "The policy runs in the same time no matter how many resources there are."

[OK] Correct: Each resource needs to be checked, so more resources mean more work.

Interview Connect

Understanding how policy checks scale helps you design efficient rules and predict performance as infrastructure grows.

Self-Check

"What if the policy checked every tag on every resource instead of just one tag? How would the time complexity change?"

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