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.