Check blocks for assertions in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Terraform check blocks with assertions

Which of the following Terraform check blocks correctly asserts that an AWS S3 bucket has versioning enabled?

Terraform

check {
  assertions = [
    {
      assert = aws_s3_bucket.example.versioning[0].enabled == true
      error_message = "S3 bucket versioning must be enabled"
    }
  ]
}

A

check {
  assertions = [
    {
      assert = aws_s3_bucket.example.versioning.enabled == true
      error_message = "S3 bucket versioning must be enabled"
    }
  ]
}

B

check {
  assertions = [
    {
      assert = aws_s3_bucket.example.versioning[0].enabled == true
      error_message = "S3 bucket versioning must be enabled"
    }
  ]
}

C

check {
  assertions = [
    {
      assert = aws_s3_bucket.example.versioning[0].status == "Enabled"
      error_message = "S3 bucket versioning must be enabled"
    }
  ]
}

D

check {
  assertions = [
    {
      assert = aws_s3_bucket.example.versioning[0].enabled != false
      error_message = "S3 bucket versioning must be enabled"
    }
  ]
}

💡 Hint

Remember that versioning is a list with an 'enabled' boolean attribute inside the first element.

Terraform AWS S3 bucket versioning is represented as a list of objects. The 'enabled' attribute is a boolean inside the first element. Option B correctly accesses it and asserts it is true.

❓ Configuration

intermediate

Detecting open security groups with check blocks

Which check block correctly asserts that no AWS security group allows ingress from 0.0.0.0/0 on port 22?

A

check {
  assertions = [
    {
      assert = alltrue([for rule in aws_security_group.example.ingress : rule.cidr_blocks[0] != "0.0.0.0/0" || rule.from_port != 22])
      error_message = "No ingress from 0.0.0.0/0 on port 22 allowed"
    }
  ]
}

B

check {
  assertions = [
    {
      assert = nonetrue([for rule in aws_security_group.example.ingress : rule.cidr_blocks[0] == "0.0.0.0/0" || rule.from_port == 22])
      error_message = "No ingress from 0.0.0.0/0 on port 22 allowed"
    }
  ]
}

C

check {
  assertions = [
    {
      assert = nonetrue([for rule in aws_security_group.example.ingress : rule.cidr_blocks[0] == "0.0.0.0/0" && rule.from_port == 22])
      error_message = "No ingress from 0.0.0.0/0 on port 22 allowed"
    }
  ]
}

D

check {
  assertions = [
    {
      assert = alltrue([for rule in aws_security_group.example.ingress : rule.cidr_blocks[0] != "0.0.0.0/0" && rule.from_port != 22])
      error_message = "No ingress from 0.0.0.0/0 on port 22 allowed"
    }
  ]
}

💡 Hint

Use nonetrue to ensure no ingress rule matches both conditions simultaneously.

Option C correctly asserts that there is no ingress rule with cidr_blocks containing 0.0.0.0/0 AND from_port equal to 22. This ensures port 22 is not open to the world.

❓ Architecture

advanced

Check block to enforce multi-AZ deployment in AWS RDS

Given an AWS RDS instance resource, which check block correctly asserts that multi-AZ deployment is enabled?

A

check {
  assertions = [
    {
      assert = aws_db_instance.example.multi_az == 1
      error_message = "RDS instance must be multi-AZ"
    }
  ]
}

B

check {
  assertions = [
    {
      assert = aws_db_instance.example.multi_az != false
      error_message = "RDS instance must be multi-AZ"
    }
  ]
}

C

check {
  assertions = [
    {
      assert = aws_db_instance.example.multi_az == "true"
      error_message = "RDS instance must be multi-AZ"
    }
  ]
}

D

check {
  assertions = [
    {
      assert = aws_db_instance.example.multi_az == true
      error_message = "RDS instance must be multi-AZ"
    }
  ]
}

💡 Hint

The multi_az attribute is a boolean, not a string or number.

Option D correctly asserts that multi_az is true (boolean). Option D compares to string "true" which is incorrect. Option D compares to number 1 which is invalid. Option D is less strict but valid; however, only A explicitly checks for true.

❓ security

advanced

Check block to ensure encryption is enabled on AWS EBS volumes

Which check block correctly asserts that all AWS EBS volumes have encryption enabled?

A

check {
  assertions = [
    {
      assert = alltrue([for vol in aws_ebs_volume.example : vol.encrypted == true])
      error_message = "All EBS volumes must be encrypted"
    }
  ]
}

B

check {
  assertions = [
    {
      assert = anytrue([for vol in aws_ebs_volume.example : vol.encrypted == true])
      error_message = "All EBS volumes must be encrypted"
    }
  ]
}

C

check {
  assertions = [
    {
      assert = alltrue([for vol in aws_ebs_volume.example : vol.encrypted != false])
      error_message = "All EBS volumes must be encrypted"
    }
  ]
}

D

check {
  assertions = [
    {
      assert = nonetrue([for vol in aws_ebs_volume.example : vol.encrypted == false])
      error_message = "All EBS volumes must be encrypted"
    }
  ]
}

💡 Hint

Use alltrue to ensure every volume is encrypted.

Option A asserts all volumes have encrypted == true. Option A only requires any volume encrypted which is insufficient. Option A is logically equivalent to D but less explicit. Option A also works logically but option A is the clearest and most direct assertion.

❓ service_behavior

expert

Check block behavior when resource attribute is missing

What error or behavior occurs when a Terraform check block asserts on a resource attribute that does not exist, for example, aws_instance.example.nonexistent_attribute == true?

Terraform

check {
  assertions = [
    {
      assert = aws_instance.example.nonexistent_attribute == true
      error_message = "Attribute must be true"
    }
  ]
}

A Terraform plan fails with an error: "Reference to undeclared resource or attribute"

B Terraform plan succeeds but check block assertion always fails at apply time

C Terraform plan succeeds and check block assertion is ignored silently

D Terraform plan succeeds and assertion evaluates to false without error

💡 Hint

Terraform validates references during plan phase and errors if attribute is missing.

Terraform raises an error during plan if a referenced attribute does not exist. It does not silently ignore or defer errors to apply time.

Practice

1. What is the main purpose of a check block in Terraform?

easy

A. To define variables for resource configuration

B. To verify conditions before resource creation and prevent errors

C. To output resource attributes after deployment

D. To create loops for multiple resource instances

Solution

1. Step 1: Understand the role of check blocks

   Check blocks are used to verify conditions before Terraform creates resources to avoid invalid configurations.

2. Step 2: Differentiate from other blocks

   Variables define inputs, outputs show results, and loops create multiple resources; none verify conditions before creation.

3. Final Answer:

   To verify conditions before resource creation and prevent errors -> Option B

4. Quick Check:

   Check blocks = pre-creation validation [OK]

Hint: Check blocks catch errors before deployment [OK]

Common Mistakes:

• Confusing check blocks with variable declarations
• Thinking check blocks output values
• Assuming check blocks create resources

2. Which of the following is the correct syntax for a check block in Terraform?

easy

A. check "valid_region" { condition var.region == "us-east-1" error_message "Region must be us-east-1" }

B. check "valid_region" { assert = var.region == "us-east-1" message = "Region must be us-east-1" }

C. check "valid_region" { condition = var.region = "us-east-1" error = "Region must be us-east-1" }

D. check "valid_region" { condition = var.region == "us-east-1" error_message = "Region must be us-east-1" }

Solution

1. Step 1: Identify correct attribute names

   The correct syntax uses condition for the boolean check and error_message for the error text.

2. Step 2: Check syntax correctness

   check "valid_region" { condition = var.region == "us-east-1" error_message = "Region must be us-east-1" } correctly uses condition = and error_message = with proper equality ==. Others use wrong attribute names or syntax errors.

3. Final Answer:

   check "valid_region" { condition = var.region == "us-east-1" error_message = "Region must be us-east-1" } -> Option D

4. Quick Check:

   Use condition and error_message with equals signs [OK]

Hint: Use 'condition =' and 'error_message =' inside check blocks [OK]

Common Mistakes:

• Using single equals (=) instead of double equals (==) for condition
• Using wrong attribute names like assert or error
• Missing equals signs between keys and values

3. Given this Terraform snippet:

variable "count" { type = number default = 3 }
check "positive_count" { condition = var.count > 0 error_message = "Count must be positive" }

What happens if you set count = 0 and run terraform apply?

medium

A. Terraform fails with error: Count must be positive

B. Terraform applies resources with count 0, creating none

C. Terraform ignores the check block and applies resources

D. Terraform applies resources but warns about count

Solution

1. Step 1: Understand the check block condition

   The check block requires var.count > 0. Setting count = 0 violates this condition.

2. Step 2: Predict Terraform behavior on violation

   Terraform stops and shows the error message from the check block instead of applying resources.

3. Final Answer:

   Terraform fails with error: Count must be positive -> Option A

4. Quick Check:

   Check blocks stop apply if condition false [OK]

Hint: Check blocks block apply if condition is false [OK]

Common Mistakes:

• Thinking Terraform ignores check blocks
• Assuming resources apply with warnings
• Confusing default variable values with overrides

4. This Terraform check block causes an error during plan:

check "valid_name" { condition = var.name != "" error_message = "Name cannot be empty" }

What is the likely cause if var.name is not set?

medium

A. Terraform errors because var.name is null and comparison fails

B. Terraform ignores the check block if variable is unset

C. Terraform treats unset variable as empty string and passes check

D. Terraform applies default empty string and shows warning only

Solution

1. Step 1: Analyze variable unset behavior

   If var.name is not set and has no default, it is null, not an empty string.

2. Step 2: Understand condition evaluation

   Comparing null to empty string with != causes an error because null is not a string.

3. Final Answer:

   Terraform errors because var.name is null and comparison fails -> Option A

4. Quick Check:

   Null variables cause check block errors if compared to strings [OK]

Hint: Unset variables are null, not empty strings [OK]

Common Mistakes:

• Assuming unset variables default to empty strings
• Expecting check blocks to ignore null values
• Thinking Terraform only warns on check failures

5. You want to enforce that a variable region is either "us-east-1" or "us-west-2" using a check block. Which is the correct check block to enforce this?

hard

A. check "valid_region" { condition = var.region == "us-east-1" || var.region == "us-west-2" error_message = "Region must be us-east-1 or us-west-2" }

B. check "valid_region" { condition = var.region == ["us-east-1", "us-west-2"] error_message = "Region must be us-east-1 or us-west-2" }

C. check "valid_region" { condition = contains(["us-east-1", "us-west-2"], var.region) error_message = "Region must be us-east-1 or us-west-2" }

D. check "valid_region" { condition = var.region in ("us-east-1", "us-west-2") error_message = "Region must be us-east-1 or us-west-2" }

Solution

1. Step 1: Understand how to check membership in a list

   Terraform uses the contains(list, value) function to check if a value is in a list.

2. Step 2: Evaluate each option

   check "valid_region" { condition = var.region == "us-east-1" || var.region == "us-west-2" error_message = "Region must be us-east-1 or us-west-2" } uses logical OR correctly but is verbose; check "valid_region" { condition = var.region == ["us-east-1", "us-west-2"] error_message = "Region must be us-east-1 or us-west-2" } compares a string to a list incorrectly; check "valid_region" { condition = contains(["us-east-1", "us-west-2"], var.region) error_message = "Region must be us-east-1 or us-west-2" } uses contains properly; check "valid_region" { condition = var.region in ("us-east-1", "us-west-2") error_message = "Region must be us-east-1 or us-west-2" } uses invalid syntax in.

3. Final Answer:

   check "valid_region" { condition = contains(["us-east-1", "us-west-2"], var.region) error_message = "Region must be us-east-1 or us-west-2" } -> Option C

4. Quick Check:

   Use contains(list, value) to check membership [OK]

Hint: Use contains() to check if value is in list [OK]

Common Mistakes:

• Using 'in' keyword which Terraform does not support
• Comparing string directly to list
• Using verbose OR instead of contains()