Summary
A deployment pipeline using azd pipeline config failed with a 403 AuthorizationFailed error even though the user was a Subscription Owner and could manually create role assignments. The root cause was not missing permissions but an ABAC (Attribute-Based Access Control) condition silently blocking role assignment operations performed through the Azure CLI and the azd pipeline generator.
Root Cause
The failure was triggered by an ABAC policy condition applied to the user’s identity. Even though the user was a Subscription Owner, the ABAC rule prevented the specific action:
Microsoft.Authorization/roleAssignments/write- The ABAC condition was not satisfied for the attempted role assignment
- The azd pipeline tool attempts to create role assignments at the subscription scope, which is where the ABAC restriction applied
- Manual role assignment succeeded only because it was done at the resource group scope, which did not violate the ABAC condition
Key takeaway: Ownership does not override ABAC. If an ABAC condition blocks an operation, the request fails—even for subscription owners.
Why This Happens in Real Systems
ABAC conditions often appear unintentionally due to:
- Inherited policies from management groups
- Conditional access rules applied to service principals or user accounts
- Custom RBAC roles with attribute filters
- Security baselines that restrict role assignment creation at higher scopes
- Misalignment between portal actions and CLI/API actions (portal may use different scopes or APIs)
These conditions are invisible unless you inspect the policy definitions or the error messages carefully.
Real-World Impact
This class of issue commonly causes:
- Pipeline bootstrap failures when tools attempt to create identities or role assignments
- Confusing permission mismatches where users can perform an action manually but automation cannot
- Blocked DevOps onboarding because identity creation is often the first step
- Inconsistent behavior between Azure Portal, Azure CLI, and IaC tools
Example or Code (if necessary and relevant)
Below is an example of a role assignment that succeeds at the resource group scope but fails at the subscription scope due to ABAC:
az role assignment create \
--assignee \
--role Contributor \
--scope /subscriptions//resourceGroups/The same command at subscription scope would fail:
az role assignment create \
--assignee \
--role Contributor \
--scope /subscriptions/How Senior Engineers Fix It
Experienced engineers resolve this by:
- Inspecting ABAC policies at the subscription and management group levels
- Checking for conditional role assignment restrictions in Azure Policy
- Temporarily elevating privileges using Privileged Identity Management (PIM) if required
- Creating the identity and role assignments at a scope allowed by ABAC
- Modifying the azd pipeline configuration to use:
- A pre-created identity
- A resource-group–scoped role assignment
- Coordinating with security teams to adjust or remove the ABAC condition if it is unintended
Senior insight: If a user can perform an action manually but automation cannot, the scope or policy boundary is almost always the culprit.
Why Juniors Miss It
Less experienced engineers often overlook this because:
- ABAC is not visible in the Azure Portal unless you know where to look
- They assume Subscription Owner = unlimited permissions, which is not true under ABAC
- They focus on RBAC roles but forget about policy-based restrictions
- The error message mentions ABAC but is easy to misinterpret
- They test manually at the resource group level, not the subscription level where the failure occurs
Bottom line: Juniors think it’s a permission issue; seniors know it’s a policy + scope issue.