Resource dependencies in Bicep

When deploying resources, you may need to make sure some resources are deployed before other resources. For example, you need a logical SQL server before deploying a database. You establish this relationship by marking one resource as dependent on the other resource. The order of resource deployment is determined in two ways: implicit dependency and explicit dependency

Azure Resource Manager evaluates the dependencies between resources, and deploys them in their dependent order. When resources aren't dependent on each other, Resource Manager deploys them in parallel. You only need to define dependencies for resources that are deployed in the same Bicep file.

Implicit dependency

An implicit dependency is created when one resource declaration references another resource in the same deployment. In the following example, otherResource gets a property from exampleDnsZone. The resource named otherResource is implicitly dependent on exampleDnsZone.

resource exampleDnsZone 'Microsoft.Network/dnszones@2018-05-01' = {
  name: 'myZone'
  location: 'global'
}

resource otherResource 'Microsoft.Example/examples@2020-06-01' = {
  name: 'exampleResource'
  properties: {
    // get read-only DNS zone property
    nameServers: exampleDnsZone.properties.nameServers
  }
}

A nested resource also has an implicit dependency on its containing resource.

resource myParent 'My.Rp/parentType@2020-01-01' = {
  name: 'myParent'
  location: 'West US'

  // implicit dependency on 'myParent'
  resource myChild 'childType' = {
    name: 'myChild'
  }
}

A resource that includes the parent property has an implicit dependency on the parent resource. It depends on the parent resource, not any of its other child resources.

The following example shows a storage account and file service. The file service has an implicit dependency on the storage account.

resource storage 'Microsoft.Storage/storageAccounts@2021-02-01' = {
  name: 'examplestorage'
  location: resourceGroup().location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
}

resource service 'Microsoft.Storage/storageAccounts/fileServices@2021-02-01' = {
  name: 'default'
  parent: storage
}

When an implicit dependency exists, don't add an explicit dependency.

For more information about nested resources, see Set name and type for child resources in Bicep.

Explicit dependency

An explicit dependency is declared with the dependsOn property. The property accepts an array of resource identifiers, so you can specify more than one dependency.

The following example shows a DNS zone named otherZone that depends on a DNS zone named dnsZone:

resource dnsZone 'Microsoft.Network/dnszones@2018-05-01' = {
  name: 'demoeZone1'
  location: 'global'
}

resource otherZone 'Microsoft.Network/dnszones@2018-05-01' = {
  name: 'demoZone2'
  location: 'global'
  dependsOn: [
    dnsZone
  ]
}

While you may be inclined to use dependsOn to map relationships between your resources, it's important to understand why you're doing it. For example, to document how resources are interconnected, dependsOn isn't the right approach. After deployment, the resource doesn't retain deployment dependencies in its properties, so there are no commands or operations that let you see dependencies. Setting unnecessary dependencies slows deployment time because Resource Manager can't deploy those resources in parallel.

Even though explicit dependencies are sometimes required, the need for them is rare. In most cases, you can use a symbolic name to imply the dependency between resources. If you find yourself setting explicit dependencies, you should consider if there's a way to remove it.

Visualize dependencies

Visual Studio Code provides a tool for visualizing the dependencies. Open a Bicep file in Visual Studio Code, and select the visualizer button on the upper left corner. The following screenshot shows the dependencies of a virtual machine.

Screenshot of Visual Studio Code Bicep resource visualizer

Next steps

For the syntax to deploy a resource, see Resource declaration in Bicep.