One less pre-flight validation using Bicep's extension configuration

Every platform team that delivers Azure subscriptions to teams encounters the reported issue at least once in their lifetime:

Code: MissingSubscriptionRegistration
Message: The subscription is not registered to use namespace 'Microsoft.ContainerService'.

The template is fine by the teams that created it. But the subscription hasn't been told that it needs the resource provider. So somebody adds a fix in the pipeline by using az provider register or Register-AzResourceProvider, or they simply make a wiki page titled: "things to do before you deploy."

That above-mentioned error has changed with a new experimental feature and keeping everything in a single template. Your Bicep template. Let me show you in this blog post about the experimental feature azExtensionConfig with providers.

What will be shipped

Bicep hasn't officially released a version with this experimental feature in it. But as you'll see in the next section, you can already use it with the nightly builds.

The azExtensionConfig lets a template pass configuration to the built-in az extension using the extension ... with { ... } syntax you already use for third-party extensions:

extension az with {
  providers: [
    'Microsoft.Compute'
    'Microsoft.Storage'
  ]
}

The one property the configuration type declares today is providers. Here you declare a list of Azure resource provider namespaces to register at the beginning of your deployment. This differentiates the pre-step that most do as an extra step in their pipeline and instead, now sits within the template.

Testing it out

Bicep's team provides a nightly build of both the CLI and VS Code extension. To install the nightly CLI:

iex "& { $(irm https://aka.ms/bicep/nightly-cli.ps1) }"

For the VS Code extension, it would be:

iex "& { $(irm https://aka.ms/bicep/nightly-vsix.ps1) }"

You can now turn on the experimental feature in your bicepconfig.json:

{
  "experimentalFeaturesEnabled": {
    "azExtensionConfig": true
  }
}

That's the only flag that's required. You don't need the moduleExtensionConfigs for authoring or type checking. So, whilst the backend service is still pending, it's still possible to take a quick peek at what is happening already. Take, for example, the scenario from the top of the post, written as a template.

A subscription-scoped deployment creates a resource group and hands off to an AKS module. AKS needs Microsoft.ContainerService, its monitoring add-on needs Microsoft.OperationalInsights, and the node subnet needs Microsoft.Network:

targetScope = 'subscription'

extension az with {
  providers: [
    'Microsoft.ContainerService'
    'Microsoft.OperationalInsights'
    'Microsoft.Network'
  ]
}

param location string = 'westeurope'

resource rg 'Microsoft.Resources/resourceGroups@2025-04-01' = {
  name: 'rg-platform-aks'
  location: location
}

module aks 'modules/aks.bicep' = {
  scope: rg
  name: 'deploy-aks'
  params: {
    location: location
  }
}

In the first lines, you can exactly tell what this deployment is assuming, especially at the subscription level. That's worth something even before the backend catches up. When you compile the above template to ARM, you notice that the config rides along the class imports path:

"imports": {
    "az": {
      "provider": "AzureResourceManager",
      "version": "0.2.891",
      "config": {
        "providers": [
          "Microsoft.ContainerService",
          "Microsoft.OperationalInsights",
          "Microsoft.Network"
        ]
      }
    }
  },

IntelliSense in the editor

This is the part that I like and works right now when you go through the provider(s): IntelliSense.

Bicep has always been profound with IntelliSense. So, Inside the with {} block, property-key completion suggest providers pop up that you want to enable.

All of these members are sourced and shipped in the bicep-typez-az, so that's why when you type in Micro, you'll find all the providers from Microsoft. Those are roughly 280 namespaces, and you can pick from the list you need.

Array-item completions also got fixed for three cursor positions that previously stayed silent: an empty array (providers: []), an empty string literal (providers: [''], which is the shape VS Code auto-inserts the moment you type a quote), and an unterminated string. Small fix, but it removes the "why isn't IntelliSense firing" moment.

Wrapping up

It's great to see that azExtensionConfig moves a piece of the deployment prerequisite, and you're able to just configure it in a Bicep template. The headline only at this time: the deployment engine does not act on this configuration yet.

You can compile it, check it out, commit it behind the flag if you liked it, but keep your existing registration step until backend support ships. You have to keep an eye out for the official Bicep release.

For more information, the feature is documented under the experimental-features.md file in the repository.