top of page

What is Continuous Validation? And How HashiCorp Enhances Terraform Drift Detection?

HashiCorp released a number of new features for Terraform including continuous validation and no-code provisioning. Both features are currently in beta for Terraform Cloud Business users. Additional releases include native Open Policy Agent (OPA) support and Azure provider automation.

The new continuous validation feature builds upon the previously released drift detection. With continuous validation, it is possible to define preconditions and postconditions that are checked approximately every 24 hours. Whereas drift detection determines whether the real-world infrastructure matches the Terraform state file, continuous validation validates that these custom conditions continue to pass after Terraform provisions the infrastructure.

For example, drift detection can be used to detect if a user has manually modified a resource configuration such that it differs from what is listed in the state file. Continuous validation can be used to assess whether an API gateway certificate is valid or cause a run to fail if a newer AMI version is available. The following example shows a postcondition that validates the EC2 instance has an encrypted root volume:

data "aws_ebs_volume" "example" {

  filter {
    name = "volume-id"
    values = [aws_instance.example.root_block_device.volume_id]

  lifecycle {
    postcondition {
      condition     = self.encrypted
      error_message = "The server's root volume is not encrypted."

Continuous validation can be enforced against all eligible workspaces within organization settings. However, enforcing at the organization-level will override workspace-level settings. Health assessments may run concurrently across multiple workspaces but do not affect the concurrency limit. As noted above, health assessments will run about every 24 hours. If a Terraform run is triggered during a health assessment, the assessment will be canceled and will be run again in 24 hours.

The new no-code provisioning workflow simplifies the process of consuming Terraform modules. The introduction of the private registry streamlined publishing validated and approved modules for consumption by others within the organization. However, consumers of these modules still need to add the module to their repository, create a workspace, and provision the resources.

The new workflow enables module publishers to instead create no-code ready modules that consumers can deploy directly into workspaces. A user needs to select the module, input the required variables, and then deploy the resources directly into their workspace. The new workflow removes the need for module consumers to understand or write HCL.

Terraform Cloud has added, in beta, native support for Open Policy Agent (OPA). OPA, based on the Rego policy language, is an open-source policy management and enforcement engine. The new OPA support works alongside Sentinel, HashiCorp's policy as code framework.

The Azure Provider Automation tool, known as Pandora, is a suite of tools which transform the Azure API Definitions into a Go SDK and Terraform resources. At the time of release only Resource Manager Services are supported, but the team has plans to add support for Microsoft Graph and possibly the Data Plane. This tool automatically generates recently-introduced Azure Resource Manager Services, shortening the time for them to be available within the Terraform Azure provider.

More information about these, and other releases from the recent HashiConf Global conference can be found at the HashiCorp blog.

12 views0 comments


Rated 0 out of 5 stars.
No ratings yet

Add a rating
Stationary photo

Be the first to know

Subscribe to our newsletter to receive news and updates.

Thanks for submitting!

Follow us
bottom of page