Deviations from optional default value not always detected

Terraform Providers Azure
1

Hi, I just experimented w.r.t. what Terraform does if the TF file, state file, and actual infrastructure differ, I discovered a weird behavior.

Let’s say I want to create a azurerm_storage_account. My assumption was that state file always contains all attributes, and the values in the state either reflect the real infrastructure (if I just ran terraform import), or whatever was set by Terraform during the most recent run of terraform apply. Then, I would also expect that if a resource has an optional attribute which I omit in the TF file, if I then run terraform plan/apply, then this attribute’s default should be present in the state, with the default value (as documented on the provider’s Terraform module website), and be set in the real infrastructure. Most of the time, this seems to be the case, e.g. for the attributes static_website or cross_tenant_replication_enabled of the storage account. But for access_tier and network_rules (there might be more) this is not the case.

So, for instance, I can omit access_tier in my TF file, the real value is “Cold”, and terraform apply does not do anything, even though the default value of access_tier is “Hot” (so omitting it should mean that Terraform sets it to Hot).

What am I missing?

This behavior leads to non-reproducible infrastructure, so it’s rather spicy.

2

Seems that the AzureRM docs are wrong and do not properly explain when attributes are Computed. As you can see in the code the access_tier attribute (and various others) are Computed and do not set a default value.

This means that Terraform has a major footgun: for any attribute one must read the Go code of the Terraform resource, to figure out whether this attribute’s default value is really managed by Terraform (or, alternatively, always set all attributes to their default value explicitly in the TF file). Otherwise you risk the chance of having broken drift detection.