Terraform 1.7: What's New, Release History & Support Lifecycle

What Is New in Terraform 1.7

Terraform 1.7 introduces config-driven import, a powerful new testing framework, and several enhancements to the language and provider ecosystem. This release focuses on improving the day-to-day workflow for infrastructure management.

How does config-driven import change infrastructure management?

Config-driven import is the headline feature, allowing you to declare import operations directly in your configuration. You write an import block specifying the ID of existing infrastructure and the Terraform resource address to adopt it.

Running terraform plan will show a proposed import operation. This is a game-changer for bringing existing resources under Terraform management because it formalizes the process and makes it repeatable. You can version control your import intentions alongside the resource definitions themselves.

import {
  to = aws_instance.example
  id = "i-abcd1234"
}

What can I do with the new testing framework?

Terraform 1.7 introduces a native testing framework, letting you write unit and integration tests in HCL. You create .tftest.hcl files that contain run blocks to execute and validate plans and applies.

This is a significant step up from previous workarounds. You can now assert conditions on plan output, state values, and command exit statuses. In practice, this means you can build a test suite to verify module behavior without external tooling, making your configurations more robust.

run "test_instance" {
  command = plan

  assert {
    condition = aws_instance.example.ami == "ami-12345678"
    error_message = "Incorrect AMI ID"
  }
}

Are there new ways to structure data with optional object attributes?

Yes, object types now support optional attributes. When you define an object type, you can mark certain attributes as optional using the optional modifier. This provides more flexibility for module input variables.

This matters because it lets you create complex object structures where certain fields can be omitted. The try() function can then be used to safely access these potentially absent values without causing plan errors, simplifying conditional logic in your configurations.

variable "settings" {
  type = object({
    name    = string
    enabled = optional(bool, true)
    tags    = optional(map(string))
  })
}

How do provider-defined functions work?

Provider-defined functions allow providers to expose custom functionality directly to Terraform configurations. Providers can now implement their own functions that you can call alongside built-in functions like length() or lookup().

This opens up new possibilities for data manipulation and resource configuration that was previously impossible or required complex workarounds. For example, a cloud provider might offer a function to generate a pre-signed URL or to perform specialized encryption.

What improvements were made to the terraform_data resource?

The terraform_data resource, introduced as a replacement for null_resource, now triggers replacement on any change to its input value. This behavior makes it more predictable for orchestrating provisioners and other side-effects.

In practice, this means if you change the input to a terraform_data resource, it will be destroyed and recreated, along with any resources that depend on it. This gives you explicit control over when provisioners should re-run based on changing data.