In cloud automation, subtle missteps in identity management can lead to serious deployment challenges. One of the most common traps occurs when automation systems rely on unstable references to the current identity context. This issue cuts across tools like Ansible, Terraform, and Bicep, and often manifests when identity is treated as a transient state — sometimes a developer running code locally, other times a CI/CD pipeline executing with a managed identity.

When automation systems require access to the resources they provision — especially in the data plane — depending on dynamic or ephemeral identities can quickly spiral into complexity. This often results in a fragile chain of deployment steps where each layer becomes a dependency on the next, not because of actual architectural requirements but due to artificial constraints like access control boundaries or network visibility. These artificial separations create unnecessary toil and complexity, demanding elaborate scripting and orchestration to simply bridge gaps that shouldn’t exist in the first place.

The key to avoiding this complexity is to establish a stable and predictable identity model for your automation — one that works consistently whether you’re deploying through pipelines or performing — break glass — manual interventions.

The Temptation of azurerm_client_config

Terraform’s azurerm_client_config data source is an attractive option because it provides a simple way to access the identity currently running Terraform. It’s implicit, it’s convenient, and it requires no setup—just drop it in and go. Here’s a basic example:

resource "azurerm_role_assignment" "terraform_user" {
  scope                = azurerm_storage_account.rawdata.id
  role_definition_name = "Storage Account Contributor"
  principal_id         = data.azurerm_client_config.current.object_id
}

This works fine until your automation context shifts. Perhaps a developer runs Terraform locally one day, and the next day it’s executed in an Azure DevOps pipeline. Since azurerm_client_config reflects the current context, any shift in that context can cause your deployments to fail unpredictably.

This instability is particularly painful in environments that need both automation and manual control paths. If you don’t account for these variations explicitly, you risk building a brittle deployment pipeline — a Rube Goldberg machine that collapses under the weight of its own intricacy.

That being said, its hella useful in labs, prototypes and demos so feel free to go forth and use it for convenience sake but just remember about the man who built his house on top of sand!!!

Building a Stable Identity Model

To resolve this, treat identity as a stable, declarative resource just like you would any other cloud component. Assign specific identities to both your automated and manual workflows, and explicitly reference them in your infrastructure code.

For automated pipelines, create a user-assigned managed identity. Reference it like this:

# Obtain a reference to the Managed Identity
data "azurerm_user_assigned_identity" "hosted_pool" {
  resource_group_name = var.hosted_pool_identity.resource_group
  name                = var.hosted_pool_identity.name
}

# Create a Role Assignment for the Managed Identity that runs your pipelines
resource "azurerm_role_assignment" "hosted_pool" {
  scope                = azurerm_storage_account.data.id
  role_definition_name = "Storage Account Contributor"
  principal_id         = data.azurerm_user_assigned_identity.hosted_pool.principal_id
}

This approach removes any ambiguity about which identity is being used and ensures that your pipeline has the correct permissions, regardless of the context in which it runs. For human operators who need the ability to run Terraform locally — especially during break-glass or emergency scenarios — use an Entra ID group. Grant that group the necessary permissions explicitly:

# Create a Role Assignment for the Entra ID Group used for system admins
resource "azurerm_role_assignment" "admin_group" {

  scope                = azurerm_storage_account.data.id
  role_definition_name = "Storage Blob Data Owner"
  principal_id         = var.admin_group_object_id

}

If you have appropriate permissions, consider using the azuread provider to manage the group lifecycle as well.

Conclusion

Automation should be reliable, repeatable, and resilient across environments. By avoiding dynamic identity references like azurerm_client_config and instead provisioning explicit identities for both automated and manual workflows, you can prevent cascading deployment failures and simplify your infrastructure. Stable identity references turn a fragile house of cards into a well-structured and maintainable system. It’s a small shift in thinking, but one that pays off in long-term operability and reduced cognitive load.