When working with Terraform in a single-subscription context, you typically don’t think much about how Azure Resource Providers are registered. Terraform generally handles this quietly in the background. For example, when you run terraform init for the first time, Terraform usually initializes the necessary providers—at least the common ones—without any explicit configuration. However, things get a little trickier when working in a multi-subscription setup using Terraform Stacks.

The Problem: Missing Resource Provider Registration

I recently ran into a subtle but frustrating issue while experimenting with a multi-subscription deployment using Terraform Stacks. In this setup, one of the subscriptions I had never previously deployed to produced the following error during provisioning:

Error: creating Managed Environment (Subscription: “00000000–0000–0000–0000–000000000000” Resource Group Name: “rg-ro-contract-engine-frontend-prod-westus3” Managed Environment Name: “cae-ro-contract-engine-frontend-prod-westus3”): performing CreateOrUpdate: unexpected status 409 (409 Conflict) with error: MissingSubscriptionRegistration: The subscription is not registered to use namespace ‘Microsoft.App’. See https://aka.ms/rps-not-found for how to register subscriptions.

In essence, Terraform was trying to provision resources under the Microsoft.App namespace, but that namespace wasn’t registered for the target subscription. This resulted in a 409 Conflict error with a clear message: the namespace must be registered first.

This kind of error doesn’t usually show up in familiar single-subscription workflows because the resource providers are often already registered — either manually or implicitly through other tooling. But when provisioning to a new subscription, especially one that’s never been touched, you’re starting with a clean slate. And that means you’ll have to deal with any unregistered namespaces explicitly.

A Simple Fix: Explicit Provider Registration

Thankfully, the solution is straightforward. The azurerm provider now includes a resource_providers_to_register argument that lets you proactively specify which namespaces should be registered before Terraform tries to use them. In my case, adding “Microsoft.App” to this list resolved the problem instantly.

Here’s the updated provider configuration:

provider "azurerm" "this" {
  config {
    features {}

    use_cli = false

    use_oidc        = true
    oidc_token      = var.identity_token
    client_id       = var.client_id
    subscription_id = var.subscription_id
    tenant_id       = var.tenant_id

    resource_providers_to_register = [
      "Microsoft.App"
    ]
  }
}

By explicitly registering the necessary resource provider, Terraform is able to proceed without hitting the MissingSubscriptionRegistration error—even for a brand-new subscription.

Conclusion

This may seem like a minor configuration tweak, but it highlights an important nuance when scaling Terraform deployments across multiple Azure subscriptions. If you’re using Terraform Stacks and provisioning into subscriptions that haven’t been initialized before, it’s worth checking whether the required resource providers are registered. Adding them preemptively can save you from runtime surprises and failed deployments.

Its a new adaptation of my age old rule of “Always Be Explicit”.

Alt