Create an Azure role assignment

What the action permits

• Documented Microsoft lists roleAssignments/write as an Action for creating an assignment at a specified scope. It is a control-plane permission. [11] [14]
• Documented Actions permit matching operations; NotActions removes matches within that role. Permission strings are case-insensitive. A matching expression establishes declared capability only. [14] [8]
• Documented DataActions is a separate permission set. Even Owner's control-plane wildcard does not itself grant every data-plane operation. [14]

Objects and scope

• Documented The actor calls the assignment API; properties.principalId identifies the intended recipient. These roles may refer to the same principal, but caller identity alone does not identify the recipient. [6]
• Documented A role definition describes permissions. A role assignment associates a principal with that definition at a scope and can carry a condition. Its assignment ID differs from the role-definition ID. [13]
• Documented Role permissions inherit from management group to subscription, resource group and resource scopes. The assignment's scope identifies where its access applies. [15]
• Documented A role assignment is an extension resource. Its full resource ID includes the roleAssignments suffix; the grant's scope is the resource being extended. Keep both separate from the caller's authorizing assignment scope. [15] [6]
• Documented AssignableScopes makes a role definition available for assignment at eligible scopes; it does not assign that role to a principal. [14]

Authorization prerequisites and limits

• Documented Calling Role Assignments Create requires access to Microsoft.Authorization/roleAssignments/write at the requested scope, including any applicable inherited authorization. [6] [15]
• Documented The documented REST request supplies the target principal object ID and role-definition resource ID, with assignment scope and assignment name in the URI. [6]
• Documented A condition on the actor's role assignment can limit which roles, principal types or specific principals the actor may assign. An action match does not evaluate that condition. [9]

• Documented NotActions subtracts permissions from one role; another role can still allow that action. An applicable deny assignment can block access despite an allow, subject to its own scope, inheritance and excluded principals. [14] [10]
• Documented These three built-in roles are reviewed examples. Other built-in and custom roles can have relevant permissions; this page provides no exhaustive grant-path inventory. [12] [8]
• Unavailable No tenant assignments, group membership, PIM activation, conditions or deny state have been evaluated here. Neither the role examples nor the historical log establish the actor's or target's effective access. [3] [9] [10]
• Inferred Azure-Microsoft.Authorization event 8520038 is the project's generated catalog join for this operation. That event number is not an Azure-native event ID or independent evidence of emission. [2]

Reviewed declared-capability examples

These are non-exhaustive role-definition examples. They do not prove an actor assignment or effective permission.

• Owner 8e3af657-a8ff-443c-a75c-2fe8c4bcb635

  The published wildcard includes the pilot action. This role definition does not establish any actor assignment or effective access. [12] [14]

  Actions

  *

• User Access Administrator 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9

  The published Microsoft.Authorization wildcard includes the pilot action. An actual assignment's scope and applicable constraints must still be checked. [12] [9]

  Actions

  */read, Microsoft.Authorization/*, Microsoft.Support/*

• Role Based Access Control Administrator f58310d9-a9f6-439a-9e8d-f62e7b41a168

  The published definition names the pilot action explicitly. This is an example of declared capability, not a tenant grant. [12] [9]

  Actions

  Microsoft.Authorization/roleAssignments/write, Microsoft.Authorization/roleAssignments/delete, */read, Microsoft.Support/*

  Condition

  Microsoft's delegation example adds an assignment condition restricting roles and recipients; no such condition record is available for this historical caller.

Authority thread stages

These are research waypoints, not a calculated effective-access result or a guaranteed event sequence.

1. Declared actor capability Documented

   A reviewed role's action expression includes roleAssignments/write after that role's exclusions. [12] [14]

   Role definition only; assignment and authorization remain separate.

2. Actor assignment Unavailable

   An applicable assignment connects the actor to a role at a scope, potentially with a condition. [13] [3]

   No independently verified actor-assignment resource is available; historical authorization evidence is insufficient.

3. Effective authorization Unavailable

   Applicable scope, permissions, conditions and deny assignments can affect whether the write is authorized. [15] [9] [10]

   This page explains factors and does not calculate an authorization result.

4. Operation attempt Historical context

   The retained context names roleAssignments/write with Success and Created result strings. [4] [3]

   These strings are historical context, not admitted occurrence or value-presence evidence.

5. Target assignment state Unavailable

   Assignment resource evidence would identify the target principal, role, scope and condition. [6] [4] [1]

   No target request body or resource response is retained; the intended Reader grant is unverified.

6. Target capability Documented

   An assignment can give its recipient the role's permissions within the assignment scope, subject to applicable constraints. [13] [9] [10]

   This is the documented model; this target's assignment and effective access are unknown.

7. Downstream operation Unavailable

   A later operation by the recipient would need separate evidence. [3] [4]

   No target-use event or causal grant-to-use relationship has been established.

Azure Activity Log context

Documented Microsoft documents ARM writes and subscription RBAC changes in Activity Log's Administrative category, with start and success/failure records. Log Analytics uses the AzureActivity schema after configured routing; OperationNameValue identifies the operation. Documentation does not prove this historical operation occurred or guarantee nested fields. [5] [7] [3]

Documented Status describes the operation result; substatus commonly describes its HTTP result. Preserve collection-specific values and distinguish a start from completion. A successful write alone does not establish continued assignment state, target effective access or subsequent use. [5] [7] [13]

Canonical event identity: Azure-Microsoft.Authorization event 8520038.

Occurrence evidence

Unavailable

Value-presence evidence

Unavailable

Request body

Absent from this historical context

Target grant state

Unavailable

Detection evidence

Analysis state: Partial. Existing represented Azure Activity rule predicates only. Complete direct selectors and partial candidates are counted separately; consumer selections establish neither occurrence nor effective access.

Research questions and evidence gaps

• Unavailable The retained record has no request body or target role-assignment response. The recipient, granted role, grant scope and condition remain unverified; intended Reader is historical context only. [4] [1] [3]
• Inferred The reviewed Monitor references describe a general authorization object but do not define its nested evidence fields. The Owner-versus-intended-Reader comparison supports only a caller-side interpretation of this historical context. [5] [7] [4] [1]
• Historical context The AzureActivity reference calls Caller a GUID; the REST/portal schema allows email, UPN or SPN, and the retained Caller is email-shaped. The historical value cannot resolve a general format contract. [7] [5] [4]
• Unavailable The v1 source registry admits no occurrence or value-presence claims for these historical samples. The embedded first-party label does not repair the missing capture provenance. [3] [4]
• Unavailable No provenance-bearing target operation or grant-to-use chain is available. Assignment creation, continued assignment existence and later use are separate questions. [3] [4] [13]

Investigation guidance

• Inferred Obtain independently sourced assignment request and resource evidence to identify the target principal, role-definition ID, scope and condition at the relevant time. [6] [13]
• Inferred Separately inspect the actor's applicable assignments and their conditions, plus relevant deny assignments. Do not substitute the target role definition for the role that authorized the write. [9] [10]
• Inferred Preserve operation identifiers, correlation, timestamps and result across the collected records. Establish any later target activity with separate evidence and a reviewed identity/time relationship. [5] [7]