Terraform Optionals On Complex Input Variables

Terraform v1.3 shipped what I think is one of the most useful features since v1.0: the optional object type attribute. To see why it matters, let's start with a variable for creating a storage account on Azure.

The variables are in their rawest form, with no validation or description.

variable "storage_account" {
type = object({
  name                = string
  resource_group_name = string
  location            = string
  kind                = string
  tier                = string
  replication_type    = string
  })
}

This example has all the properties we need to create a storage account on Azure. But the kind property is actually optional, and since optional on an attribute doesn't exist yet, we have to work around that. I've seen two common ways to do it:

storage_account = {
  name                = "sablt"
  resource_group_name = "rg-blt"
  location            = "australieast"
  kind                = "" //NOTE: We don't want to set this
  tier                = "Premium"
  replication_type    = "LRS"
}

This is what we'd set in either a .tfvars file or a module call. We're passing an empty string for kind, and our code would deal with the empty string for us, but we still have to type those four pesky characters. So let's look at the next scenario, which actually requires more typing!

variable "storage_account" {
  type = object({
    name                = string
    resource_group_name = string
    location            = string
    tier                = string
    replication_type    = string
  })
}
 
variable "storage_account_kind" {
  type    = string
  default = ""
}

Now we have two variables. It could be worse: that entire storage_account variable could be split out into its individual components. And yes, I've seen that happen. We've also set a default for the variable so that we don't ever have to pass anything in if we don't want/need to.

On the surface this doesn't feel so bad, especially for something as simple as this. But extrapolate it to more complex situations, or to cases where many (potentially most) properties are optional, and you're going to end up with a mess of variables. I personally always opt for complex objects as I feel it is far easier to see and understand what's going on and what the requirements of the code are!

Now let's see how the new feature handles the same case.

variable "storage_account" {
  type = object({
    name                = string
    resource_group_name = string
    location            = string
    kind                = optional(string)
    tier                = string
    replication_type    = string
  })
}

Now kind is of type optional(string), which means that if we do set a value, it has to be a string. It can go a step further, though. What if we want a default value just for this property? Now you can have one!

variable "storage_account" {
  type = object({
    name                = string
    resource_group_name = string
    location            = string
    kind                = optional(string, "StorageV2")
    tier                = string
    replication_type    = string
  })
}

We probably wouldn't set a default for this particular property, since we mostly want it to be optional. For tier, though, we might want a default that's common for the business and only deviate from it as needed.

optional gives us a much better way to set up complex object variables. We can mark some properties as optional and give others a sensible default. We no longer have to build out separate variables for properties we want to be optional.

You can follow Brendan @BrendanLiamT on Twitter.