Subscription-wide RBAC for work that lives in one resource group

Why it happens

Subscription scope is the convenient default. It's simpler to assign a role once at the top than to reason about which resource groups a team or pipeline will touch, and it pre-empts the "I can't deploy to the new resource group" ticket that a tightly scoped grant would eventually cause.

Azure evaluates whether a principal is authorized at a scope, but never whether the scope is wider than the principal's behavior. A Contributor confined to rg-app-prod looks exactly like one that manages the whole subscription. Because the broad grant keeps working and rescoping carries a small risk of breaking a future deployment, the assignment stays subscription-wide long after the work settled into one resource group.

What it costs / blast radius

This is a blast-radius problem rather than a bill. A subscription-scoped write role means a compromise of that identity, or an automation bug running under it, can reach every resource group in the subscription, not just the one the principal legitimately uses. (Azure behavior; authored assessment.) The exposed surface is the difference between one resource group and the entire subscription, and the assignment gives you nothing in return for that gap.

See it

// Assigned at the subscription. Inherits into every resource group,
// though this principal only ever operates in rg-app-prod.
targetScope = 'subscription'

resource wideAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(subscription().id, principalId, contributorRoleId)
  properties: {
    roleDefinitionId: subscriptionResourceId(
      'Microsoft.Authorization/roleDefinitions',
      'b24988ac-6180-42a0-ab88-20f7382dd24c') // Contributor
    principalId: principalId
    principalType: 'ServicePrincipal'
  }
}

// Scoped to the one resource group in use. Same role, far smaller surface.
targetScope = 'resourceGroup'

resource scopedAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(resourceGroup().id, principalId, contributorRoleId)
  properties: {
    roleDefinitionId: subscriptionResourceId(
      'Microsoft.Authorization/roleDefinitions',
      'b24988ac-6180-42a0-ab88-20f7382dd24c') // Contributor
    principalId: principalId
    principalType: 'ServicePrincipal'
  }
}