Sentinel policy as code in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Sentinel Policy Enforcement

What happens when a Sentinel policy denies a Terraform plan?

A Terraform ignores the policy and proceeds with the apply operation.

B Terraform applies the changes but logs a warning about the policy denial.

C Terraform blocks the apply operation and does not make any infrastructure changes.

D Terraform automatically modifies the plan to comply with the policy and applies it.

💡 Hint

Think about what 'policy enforcement' means in terms of control.

When a Sentinel policy denies a plan, Terraform blocks the apply operation to prevent non-compliant changes.

❓ Configuration

intermediate

Sentinel Policy to Restrict AWS Instance Types

Which Sentinel policy code correctly denies any AWS EC2 instance with type 't2.micro'?

Terraform

import "tfplan/v2"

main = rule {
  all tfplan.resources.aws_instance as _, instances {
    all instances as _, instance {
      instance.applied.instance_type != "t2.micro"
    }
  }
}

A

import "tfplan/v2"

main = rule {
  all tfplan.resources.aws_instance as _, instances {
    any instances as _, instance {
      instance.applied.instance_type == "t2.micro"
    }
  }
}

B

import "tfplan/v2"

main = rule {
  all tfplan.resources.aws_instance as _, instances {
    all instances as _, instance {
      instance.applied.instance_type != "t2.micro"
    }
  }
}

C

}
}  
}    
"orcim.2t" =! epyt_ecnatsni.deilppa.ecnatsni      
{ ecnatsni ,_ sa secnatsni lla    
{ secnatsni ,_ sa ecnatsni_swa.secruoser.nalpft lla  
{ elur = niam

"2v/nalpft" tropmi

D

import "tfplan/v2"

main = rule {
  any tfplan.resources.aws_instance as _, instances {
    any instances as _, instance {
      instance.applied.instance_type != "t2.micro"
    }
  }
}

💡 Hint

Look for the correct operator to check inequality and the correct quantifiers to deny 't2.micro'.

The policy uses 'all' to ensure no instance is 't2.micro' and '!=' operator for inequality in Sentinel.

❓ Architecture

advanced

Sentinel Policy Integration in Terraform Cloud Workflow

In a Terraform Cloud workspace with Sentinel policies enabled, what is the correct order of events when a user runs terraform apply?

A 1,2,4,3

B 1,3,2,4

C 2,1,3,4

D 1,2,3,4

💡 Hint

Think about the natural flow from user action to policy evaluation to final apply.

The user triggers apply, Terraform Cloud creates a plan, sends it to Sentinel, then applies or blocks based on policy.

❓ security

advanced

Sentinel Policy to Enforce Tagging on Resources

Which Sentinel policy snippet correctly enforces that all resources have a non-empty 'Environment' tag?

A

import "tfplan/v2"

main = rule {
  all tfplan.resources as _, instances {
    all instances as _, instance {
      instance.applied.tags.Environment is string and instance.applied.tags.Environment != ""
    }
  }
}

B

import "tfplan/v2"

main = rule {
  all tfplan.resources as _, instances {
    any instances as _, instance {
      instance.applied.tags.Environment is string and instance.applied.tags.Environment != ""
    }
  }
}

C

import "tfplan/v2"

main = rule {
  any tfplan.resources as _, instances {
    all instances as _, instance {
      instance.applied.tags.Environment is string and instance.applied.tags.Environment != ""
    }
  }
}

D

import "tfplan/v2"

main = rule {
  all tfplan.resources as _, instances {
    all instances as _, instance {
      instance.applied.tags.Environment != null
    }
  }
}

💡 Hint

Check for correct use of 'all' quantifiers and string checks.

Option A ensures every resource and instance has a non-empty string 'Environment' tag, enforcing tagging strictly.

❓ service_behavior

expert

Behavior of Sentinel Policy with Multiple Rules

Given a Sentinel policy with multiple rules where main is defined as main = rule1 and rule2, what is the behavior if rule1 passes but rule2 fails?

A The policy fails because all rules combined with 'and' must pass.

B The policy passes because at least one rule passed.

C The policy result is undefined and depends on Terraform Cloud settings.

D The policy passes but logs a warning about the failed rule.

💡 Hint

Consider how logical AND works in boolean expressions.

When rules are combined with 'and', all must pass for the policy to pass. If any fail, the policy fails.

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