Bicep Resource Dependencies

Some Azure resources need another resource to exist first. A web app needs its hosting plan, and a network card needs its subnet. Bicep tracks these relationships through dependencies and builds resources in the correct order.

Think of building a house. Workers pour the foundation before raising walls, and walls come before the roof. Painting the interior and planting the garden can happen at the same time because neither waits for the other. Bicep follows the same logic.

Dependency Order Diagram

  Time flows downward

  ┌────────────────┐     ┌────────────────┐
  │ App Service    │     │ Storage        │   ← no links, start together
  │ Plan           │     │ Account        │
  └───────┬────────┘     └────────────────┘
          │ web app needs the plan
          ▼
  ┌────────────────┐
  │ Web App        │
  └────────────────┘

Implicit Dependencies

An implicit dependency appears when one resource uses a property of another through its symbolic name. Bicep notices the reference and orders the deployment on its own.

resource plan 'Microsoft.Web/serverfarms@2023-01-01' = {
  name: 'asp-shop'
  location: 'eastus'
  sku: {
    name: 'B1'
  }
}

resource webApp 'Microsoft.Web/sites@2023-01-01' = {
  name: 'app-shop-001'
  location: 'eastus'
  properties: {
    serverFarmId: plan.id   // reference creates the dependency
  }
}

The expression plan.id tells Bicep that the web app waits for the plan. Most templates need nothing more.

Explicit Dependencies with dependsOn

Sometimes a relationship exists without any property reference. A web app may need a storage account ready before it starts, even though no property links them. The dependsOn property states the order directly.

resource storage 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'stshopdata001'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

resource webApp 'Microsoft.Web/sites@2023-01-01' = {
  name: 'app-shop-002'
  location: 'eastus'
  properties: {
    serverFarmId: plan.id
  }
  dependsOn: [
    storage
  ]
}

When to Use dependsOn

Use it sparingly. Unneeded explicit links slow deployments because they remove chances for parallel work.

The parent Property

Child resources, such as a subnet inside a virtual network, use the parent property. The property creates a dependency and builds the correct resource name.

resource vnet 'Microsoft.Network/virtualNetworks@2023-09-01' = {
  name: 'vnet-shop'
  location: 'eastus'
  properties: {
    addressSpace: {
      addressPrefixes: ['10.0.0.0/16']
    }
  }
}

resource subnet 'Microsoft.Network/virtualNetworks/subnets@2023-09-01' = {
  parent: vnet
  name: 'frontend'
  properties: {
    addressPrefix: '10.0.1.0/24'
  }
}

Parallel Deployment

Resources without links deploy at the same time. Azure finishes large templates quickly because independent items never wait in line. Modules follow the same rule, and a module that uses another module's output waits for it.

Circular Dependencies

A circular dependency occurs when resource A waits for B and B waits for A. Neither can start, and Bicep reports an error. Break the cycle by moving one shared setting into a third resource or by removing the unneeded reference.

  A ───► B
  ▲      │
  └──────┘     Neither can start first → error

Viewing the Order

The Bicep extension for Visual Studio Code offers a visualizer that draws the resource graph. A quick look shows the planned order and exposes surprises before deployment.

Summary

Bicep orders deployments through dependencies. References by symbolic name create implicit dependencies, and parent links children to their owners. The dependsOn property covers rare cases with no reference. Unlinked resources deploy in parallel, and circular links produce errors that need redesign.