The Azure Storage Account resource has a nested block called network_rules. Often times when resources in the azurerm are first authored, there is one monolithic resource that has everything on one big resource type with a plethora of nested blocks.

As the provider matures over time these monolithic resource types start getting split up into sub-resource types that can be provisioned as stand-alone resources. Another good example of this is the azurerm_virtual_network resource which allows you to provision subnets using one or more subnet nested blocks - or stand-alone azurerm_subnet resource blocks.

One of the tricky parts about these dual modalities is that if both are used together Terraform would have a hard time figuring out which one takes priority. Therefore, when this situation manifests, the Terraform provider authors require you to make a choice. Either you use nested blocks on that monolithic root resource type or you exclusively use stand-alone resource blocks.

I stumbled across a (new to me) resource type called azurerm_storage_account_network_rules and was excited to try it out. I dutifully removed the nested block in my azurerm_storage_account and split it off into its own stand-alone resource block. 

Error: A resource with the ID "/subscriptions/a8dc551f-cbe8-47e9-87c1-d9570ac6d69d/resourceGroups/rg-terraform-state/providers/Microsoft.Storage/storageAccounts/stjmavzhot" already exists - to be managed via Terraform this resource needs to be imported into the State. Please see the resource documentation for "azurerm_storage_account_network_rule" for more information.
│
│   with azurerm_storage_account_network_rules.main,
│   on storage.tf line 17, in resource "azurerm_storage_account_network_rules" "main":
│   17: resource "azurerm_storage_account_network_rules" "main" {
│

However, what happened was Terraform actually detected this as a resource that already exists and needs to be imported. Which was a bummer but completely understandable. If you think about it, I already provisioned the configuration that this resource manages using the nested block. Therefore, that configuration already exists and Terraform knows it. It also knows that this configuration is not currently under management by the new stand-alone resource block. Hence I have to do an import.

The import instructions for the azurerm_storage_account_network_rule looks like this:

terraform import \
  azurerm_storage_account_network_rules.storageAcc1 \
  /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myresourcegroup/providers/Microsoft.Storage/storageAccounts/myaccount

Now let’s update this to what I need:

terraform import \
  azurerm_storage_account_network_rules.main \
  /subscriptions/a8dc551f-cbe8-47e9-87c1-d9570ac6d69d/resourceGroups/rg-terraform-state/providers/Microsoft.Storage/storageAccounts/stjmavzhot

I can convert this to an import block like this:

import {
    to = azurerm_storage_account_network_rules.main
    id = "/subscriptions/a8dc551f-cbe8-47e9-87c1-d9570ac6d69d/resourceGroups/rg-terraform-state/providers/Microsoft.Storage/storageAccounts/stjmavzhot"
}

Then running Terraform Apply I have no problem:

# azurerm_storage_account_network_rules.main will be created
  + resource "azurerm_storage_account_network_rules" "main" {
      + bypass             = [
          + "None",
        ]
      + default_action     = "Deny"
      + id                 = (known after apply)
      + storage_account_id = "/subscriptions/a8dc551f-cbe8-47e9-87c1-d9570ac6d69d/resourceGroups/rg-terraform-state/providers/Microsoft.Storage/storageAccounts/stjmavzhot"
    }

Done!

Until Next Time - Happy Azure Terraforming!