🚨 Common Azure Errors

Common Azure Errors: Azure errors have a pattern that mirrors Java's checked exception model: the error names are descriptive, but they describe what the API rejected — not why y

Azure errors have a pattern that mirrors Java's checked exception model: the error names are descriptive, but they describe what the API rejected — not why your intent failed. `AuthorizationFailed` is Azure's `AccessControlException`: the RBAC role system said your identity does not have the right, which is almost never about the identity itself but about which role was assigned to which scope. `StorageAccountAlreadyTaken` is Azure's `IllegalArgumentException`: the constraint (globally unique name) exists at the platform level and cannot be negotiated away. But here is the question that deepens understanding: why does Azure use RBAC roles on resource group scopes rather than simple per-user permissions? Because the same Service Principal that runs your QA pipeline in the morning should not be able to delete production databases in the afternoon — RBAC scope boundaries enforce that separation at the platform level, not at the application level. Java analogy: RBAC scopes are like Java module system boundaries (`module-info.java`) — you cannot access what is not explicitly exported, even if you own the JVM. The QA incident that stems from misreading these errors is consistently the same: a pipeline fails with `AuthorizationFailed` at 11 PM before a release, the on-call engineer adds `Contributor` role at the subscription level to "just make it work," and the next morning the QA pipeline has write access to the production environment it was never supposed to touch.

The Azure identity (user or service principal) does not have the required RBAC role. Azure uses Role-Based Access Control — even Owners of one resource group cannot access another.

Azure storage account names must be globally unique (3-24 lowercase alphanumeric characters). Someone in any Azure tenant worldwide already owns "mytestreports".

Azure DevOps changed its policy for new private projects: free Microsoft-hosted agent parallelism requires a one-time manual grant request. This affects newly created organizations running private repos.

The chosen VM size has no available capacity in the selected region. Azure has varying capacity per region and size. This is common for GPU instances and specific VM sizes in busy regions.

The Azure AD tenant has Conditional Access policies requiring MFA. "az login" interactive mode triggers MFA, but unattended scripts cannot complete MFA interactively.

The Azure Container Instance ran out of memory. Chrome/Selenium browsers are memory-intensive. A container with 1GB RAM is insufficient for more than 2-3 parallel browser sessions.

The pipeline uses AzureCLI@2 task but the script uses syntax from a newer version. Or the self-hosted agent does not have Azure CLI installed. Microsoft-hosted agents update CLI versions periodically.

The Shared Access Signature (SAS) token or access key is expired, has insufficient permissions, or the request IP is not in the allowed IP range. This also happens when the storage account firewall blocks access.

The AKS cluster does not have enough CPU or memory to schedule the test pod. All existing nodes are fully utilized by running test containers.

🎬 AuthorizationFailed: Panic at 11 PM, Disaster by Morning

Pre-Release Pipeline

On-Call Engineer (11pm)

Contributor @ Subscription (too broad)