Struggling to deploy resources into an Azure Managed App resource group with Terraform? Learn why this seemingly simple task fails and discover three practical solutions, from quick fixes to permanent, production-ready patterns.

Wrestling with Terraform and Azure Managed Apps: A Guide to Deploying in That Locked-Down Resource Group

I remember it like it was yesterday. It was 10 PM, the final cutover for a new client’s production environment. We were deploying their core infrastructure via a slick Azure Marketplace Managed Application. The app deployed perfectly. Green checkmarks everywhere. High-fives on Slack. Then came phase two: my Terraform pipeline kicked off to deploy a new Key Vault and a Private Endpoint into the resource group the app had just created. And then… AuthorizationFailed. Over and over. The pipeline was bleeding red. My simple `terraform apply` was being told it didn’t have permission to do its job, even though our Service Principal was a Contributor on the subscription. That’s when the cold sweat starts, because this isn’t a simple typo; it’s a fundamental misunderstanding of how Azure is locking you out of your own resources.

The Root of the Problem: It’s Not You, It’s the Deny Assignment

Before we dive into the fixes, let’s get to the heart of the matter. When you deploy an Azure Managed Application, it creates a special Resource Group called a Managed Resource Group (MRG). You’ll recognize it because it’s usually named something like `mrg-YourAppName-20230510103045`. Azure, by design, places a Deny Assignment on this MRG. This is a security feature to prevent customers (you) from accidentally breaking the managed application by deleting or modifying its core components.

This Deny Assignment effectively overrides any `Contributor` or `Owner` roles your Terraform Service Principal (SPN) might have at the subscription level. So, when Terraform tries to create a new resource, Azure looks at the Deny Assignment first, says “Nope, access denied,” and the operation fails. It’s doing its job, but it’s a massive headache when you legitimately need to add resources to that group.

Three Ways to Break In (The Right Way)

So, how do we tell Azure that our Terraform automation is one of the “good guys”? We have a few options, ranging from a quick-and-dirty fix to the proper, architecturally-sound solution.

Solution 1: The “Get It Done Now” Fix (Direct Role Assignment)

This is the simplest approach and the one most people try first. You find the name of the Managed Resource Group and the Object ID of your Terraform Service Principal, and you manually grant it the `Owner` role directly on the MRG. This direct assignment is specific enough to bypass the inherited Deny Assignment.

You can do this in the portal, but to keep things slightly more automated, you’d use the Azure CLI:

# First, get the Object ID of your Terraform Service Principal
TF_SPN_OBJECT_ID=$(az ad sp show --id "http://your-tf-spn-name" --query "id" -o tsv)

# Now, assign the Owner role directly on the Managed Resource Group
az role assignment create \
  --assignee-object-id $TF_SPN_OBJECT_ID \
  --role "Owner" \
  --scope "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/mrg-YourAppName-20230510103045"

War Story Wisdom: This is a “break glass in case of emergency” fix. It’s manual, it’s outside your Terraform state, and it’s easy for the next engineer to miss. It works, but it creates configuration drift. Use it to get unblocked, but plan to replace it with a better solution.

Solution 2: The “By The Book” Permanent Fix (Using a Deployment Identity)

This is the official, Microsoft-endorsed way to handle this. You modify the Managed Application’s definition itself to include an `authorization` block. This block tells Azure, “When you deploy this app, also grant these specific principals these specific roles on the Managed Resource Group you’re about to create.”

In your `mainTemplate.json` for the Managed App, you’d add a block like this:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": { ... },
  "variables": {
    "terraformSpnObjectId": "[parameters('terraformServicePrincipalId')]"
  },
  "resources": [
    {
      "type": "Microsoft.Solutions/authorizations",
      "apiVersion": "2018-09-01-preview",
      "name": "[guid(variables('terraformSpnObjectId'))]",
      "properties": {
        "principalId": "[variables('terraformSpnObjectId')]",
        "roleDefinitionId": "[subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '8e3af657-a8ff-443c-a75c-2fe8c4bcb635')]"
      }
    }
    // ... your other managed app resources
  ]
}

In this example, `8e3af657…` is the well-known ID for the `Owner` role. You’d pass your Terraform SPN’s Object ID as a parameter during the app deployment. Now, the permissions are granted automatically as part of the app’s atomic deployment.

Pro Tip: This is the dream scenario. It’s idempotent, fully automated, and secure. The only downside is that you need control over the Managed Application’s source code. If you’re using a third-party app from the Marketplace, you probably can’t do this.

Solution 3: The ‘Pragmatic Engineer’ Fix (Terraform Data Source + Role Assignment)

This is my personal favorite for its balance of automation and practicality. It keeps everything within a single `terraform apply` workflow, even if you can’t edit the Managed App definition. The trick is to treat the problem in two steps within the same Terraform code: 1) Deploy the Managed App, and 2) Use a data source to find the MRG it created and assign the role.

Here’s what that looks like in HCL:

# First, define your current SPN or Managed Identity
data "azurerm_client_config" "current" {}

# Step 1: Deploy the Managed Application
resource "azurerm_managed_application" "prod_app" {
  name                = "our-production-app"
  location            = "East US"
  resource_group_name = "apps-rg"
  kind                = "Marketplace"
  
  # ... other required properties
  
  managed_resource_group_name = "mrg-prod-app-01"
  plan {
    name      = "plan_name_from_marketplace"
    publisher = "publisher_name"
    product   = "product_name"
  }
}

# Step 2: Assign the role to the MRG created by the app
# The 'depends_on' is crucial here!
resource "azurerm_role_assignment" "tf_spn_on_mrg" {
  scope                = azurerm_managed_application.prod_app.managed_resource_group_id
  role_definition_name = "Owner"
  principal_id         = data.azurerm_client_config.current.object_id

  depends_on = [
    azurerm_managed_application.prod_app
  ]
}

# Now you can define other resources that go inside the MRG
resource "azurerm_key_vault" "app_secrets" {
  name                = "kv-prod-app-secrets-01"
  location            = azurerm_managed_application.prod_app.location
  resource_group_name = azurerm_managed_application.prod_app.managed_resource_group_name
  # ... other properties

  # This resource implicitly depends on the role assignment being complete
  depends_on = [
    azurerm_role_assignment.tf_spn_on_mrg
  ]
}

This approach uses `azurerm_managed_application.prod_app.managed_resource_group_id` to dynamically get the ID of the MRG and then creates an `azurerm_role_assignment`. The explicit `depends_on` ensures Terraform creates the role assignment *before* it tries to create the Key Vault.

Decision Time: Which Path to Choose?

To make it simple, here’s how I decide which solution to use:

Ultimately, that late-night deployment was saved by Solution #1, followed by a proper implementation of Solution #3 the next morning. Understanding that the Deny Assignment is a feature, not a bug, is the key. Once you know what you’re fighting against, you have the tools to work with it, not against it, and you can get back to deploying infrastructure instead of fighting with permissions.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions