Adding to map forces replacement

Terraform Providers Azure
1

I’m using a 3rd party module here https://github.com/Azure/terraform-azurerm-lz-vending/blob/main/modules/virtualnetwork/outputs.tf where the output virtual_network_resource_ids is a map of vnetname = vnetid.

It’s my understanding that maps have no order so I’m confused as to why adding an entry at any position, start middle or end to the input map var.virtual_networks (used to key the output values) would result in a force replacement of anything using the output. I.e. scaling the vnets breaks anything using the existing vnet ids.

The var.virtual_networks input var taken from the example in the readme

  virtual_networks = {
    one = {
      name                    = "my-vnet"
      address_space           = ["192.168.1.0/24"]
      hub_peering_enabled     = true
      hub_network_resource_id = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-hub-network-rg/providers/Microsoft.Network/virtualNetworks/my-hub-network"
      mesh_peering_enabled    = true
    }
    two = {
      name                    = "my-vnet2"
      location                = "northeurope"
      address_space           = ["192.168.2.0/24"]
      hub_peering_enabled     = true
      hub_network_resource_id = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-hub-network-rg/providers/Microsoft.Network/virtualNetworks/my-hub-network2"
      mesh_peering_enabled    = true
    }
  }

When adding a third either at the start, middle or end
anything using the outputs module.sub.virtual_network_resource_ids.one or module.sub.virtual_network_resource_ids.two results in force replacement when the virtual network id is now only “known after apply”.

  virtual_networks = {
    one = {
      name                    = "my-vnet"
      address_space           = ["192.168.1.0/24"]
      hub_peering_enabled     = true
      hub_network_resource_id = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-hub-network-rg/providers/Microsoft.Network/virtualNetworks/my-hub-network"
      mesh_peering_enabled    = true
    }
    two = {
      name                    = "my-vnet2"
      location                = "northeurope"
      address_space           = ["192.168.2.0/24"]
      hub_peering_enabled     = true
      hub_network_resource_id = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-hub-network-rg/providers/Microsoft.Network/virtualNetworks/my-hub-network2"
      mesh_peering_enabled    = true
    }
    athird = {
      name                    = "my-vnet3"
      location                = "northeurope"
      address_space           = ["192.168.3.0/24"]
      hub_peering_enabled     = true
      hub_network_resource_id = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-hub-network-rg/providers/Microsoft.Network/virtualNetworks/my-hub-network2"
      mesh_peering_enabled    = true
    }
  }

The first question is why is this happening but more importantly how do I stop it from happening. Example usage causing the issue is linking some dns zones to one of the above vnets.

resource azurerm_private_dns_zone_virtual_network_link "test" {
  for_each = local.private_zones
  name = each.key
  resource_group_name = data.azurerm_resource_group.zones.name
  private_dns_zone_name = each.value.zone
  virtual_network_id = module.sub.virtual_network_resource_ids.one
}
2