Does ARM require provisioning a resource both within the parent resource as well as outside a parent resource?

Question

A good example is a subnet declaration within a vnet resource. I can add a subnet to a vnet via this ARM syntax

//vnet declaration with subnet declaration in subnets arrary
{
  "type": "Microsoft.Network/virtualNetworks",
    "apiVersion": "2020-11-01",
    "name": "vnetName",
    ...
    "properties": {
      "subnets": [
         "name": "subnetName",
         "properties": {
           ...
         }
      ],
    }            
}

I can also add it outside of the vnet declaration like this:

//vnet declaration w/out subnet
{
  "type": "Microsoft.Network/virtualNetworks",
    "apiVersion": "2020-11-01",
    "name": "vnetName",
    ...
    "properties": {
      ...
    }            
}


//separate subnet declaration as specific type outside of vnet declaration, but dependsOn vnet
{
  "type": "Microsoft.Network/virtualNetworks/subnets",
  "apiVersion": "2020-11-01",
  "name": "subnetName",
    "dependsOn": [
      "[resourceId('Microsoft.Network/virtualNetworks', 'vnetName')]"
    ],
    "properties": {
      ...
    }
}

A quick google on this landed me on this Microsoft documentation page which shows you how to do it by nesting a resources array within the parent resource, not utilizing the subnets array.

I'd like to know what's required b/c if the same subnet needs to be declared both within the vnet declaration as well as outside the vnet declaration as its own type, that adds a lot of verbosity to the ARM template.

Thanks!

Answer 1

TL;DR Both are not required the external declaration is there to help with avoiding circular dependencies and give control on deploy order.

In your example adding the subnet definitions within the VNet declaration will always be okay as you wouldn't create a circular dependency.

However let's say we have a Key Vault and a web app that references secrets in that vault.

Firstly we create the Key Vault with the needed secrets. However with this we also need the access policy setup to allow the app service to reference the secrets. If we were to try and do this internally then it would be trying to reference an app service that doesn't exist.

To fix this we use an external declaration for the access policy which is dependent on both the Key Vault and App service. This allows both to be created and then access to be granted; when all the Ids have been generated.

This article from Microsoft explains all of this in more detail.