Custom role definitions in Azure - Step-by-Step Execution

Process Flow - Custom role definitions

Start: Define role properties

↓

Specify permissions (actions, notActions)

↓

Set assignable scopes

↓

Create role definition JSON

↓

Deploy role via Azure CLI or Portal

↓

Role available for assignment

↓

End

The flow shows defining permissions and scopes, creating the JSON role definition, deploying it, then using the role.

Execution Sample

Azure

{
  "Name": "Custom Reader",
  "IsCustom": true,
  "Description": "Can read resources",
  "Actions": ["Microsoft.Resources/subscriptions/resourceGroups/read"],
  "NotActions": [],
  "AssignableScopes": ["/subscriptions/12345678-1234-1234-1234-123456789abc"]
}

This JSON defines a custom role that allows reading resource groups in a specific subscription.

Process Table

Step	Action	Input/Value	Result/State
1	Define role name and description	Name: Custom Reader, Description: Can read resources	Role properties set
2	Specify permissions	Actions: read resource groups, NotActions: none	Permissions configured
3	Set assignable scopes	Scope: subscription /subscriptions/12345678-1234-1234-1234-123456789abc	Scope assigned
4	Create JSON role definition	Combine all properties into JSON	Role definition JSON ready
5	Deploy role	Use Azure CLI or Portal to create role	Role created and available
6	Assign role to user/group	Assign Custom Reader role	User/group can read resource groups
7	Exit	All steps complete	Custom role ready for use

💡 Role is created and ready for assignment after deployment.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
Name	undefined	Custom Reader	Custom Reader	Custom Reader	Custom Reader	Custom Reader
Description	undefined	Can read resources	Can read resources	Can read resources	Can read resources	Can read resources
Actions	undefined	undefined	["Microsoft.Resources/subscriptions/resourceGroups/read"]	["Microsoft.Resources/subscriptions/resourceGroups/read"]	["Microsoft.Resources/subscriptions/resourceGroups/read"]	["Microsoft.Resources/subscriptions/resourceGroups/read"]
NotActions	undefined	undefined	[]	[]	[]	[]
AssignableScopes	undefined	undefined	undefined	["/subscriptions/12345678-1234-1234-1234-123456789abc"]	["/subscriptions/12345678-1234-1234-1234-123456789abc"]	["/subscriptions/12345678-1234-1234-1234-123456789abc"]
RoleDefinitionJSON	undefined	undefined	undefined	undefined	JSON object with all properties	JSON object with all properties

Key Moments - 3 Insights

Why do we need to specify both Actions and NotActions in a custom role?

Actions define what is allowed, NotActions exclude specific permissions from those allowed. This lets you fine-tune permissions. See step 2 in execution_table where Actions and NotActions are set.

What happens if AssignableScopes is not set correctly?

The role cannot be assigned outside the specified scopes. Step 3 shows setting AssignableScopes; if missing or wrong, role assignment fails.

Is the custom role immediately usable after JSON creation?

No, after creating the JSON (step 4), you must deploy it (step 5) before it can be assigned and used.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the role definition JSON created?

A Step 5

B Step 2

C Step 4

D Step 3

💡 Hint

Check the 'Action' column in execution_table for when JSON is created.

According to variable_tracker, what is the value of Actions after Step 2?

A ["Microsoft.Resources/subscriptions/resourceGroups/read"]

B undefined

C []

D null

💡 Hint

Look at the Actions row under After Step 2 in variable_tracker.

If AssignableScopes was set to an empty list, what would happen according to the flow?

A Role can be assigned anywhere

B Role cannot be assigned anywhere

C Role automatically assigned to all users

D Role permissions are ignored

💡 Hint

Refer to step 3 in execution_table and key_moments about AssignableScopes.

Concept Snapshot

Custom role definitions in Azure:
- Define role name, description
- Specify allowed Actions and NotActions
- Set AssignableScopes (where role applies)
- Create JSON with these properties
- Deploy role via Azure CLI or Portal
- Assign role to users/groups for custom permissions

Full Transcript

Custom role definitions in Azure start by defining the role's name and description. Then, you specify the permissions allowed (Actions) and any exceptions (NotActions). Next, you set the assignable scopes to limit where the role can be used. All these properties are combined into a JSON role definition. This JSON is deployed using Azure CLI or the Azure Portal. After deployment, the role becomes available for assignment to users or groups, granting them the specified permissions within the defined scopes.

Practice

1. What is the main purpose of creating a custom role definition in Azure?

easy

A. To tailor permissions exactly to specific needs

B. To delete all existing roles in Azure

C. To automatically assign roles to all users

D. To create virtual machines quickly

Solution

1. Step 1: Understand role customization

   Custom roles allow you to specify exactly which permissions are granted or denied, unlike built-in roles which are fixed.

2. Step 2: Identify the purpose of custom roles

   They help tailor permissions to fit specific needs, improving security and control.

3. Final Answer:

   To tailor permissions exactly to specific needs -> Option A

4. Quick Check:

   Custom roles = tailored permissions [OK]

Hint: Custom roles = tailor permissions to your needs [OK]

Common Mistakes:

• Thinking custom roles delete existing roles
• Assuming custom roles auto-assign to all users
• Confusing custom roles with VM creation

2. Which JSON property is required to specify the permissions allowed in a custom role definition?

easy

A. "NotActions"

B. "Actions"

C. "allowedActions"

D. "permissions"

Solution

1. Step 1: Review custom role JSON structure

   The property "Actions" lists the allowed operations in the role definition.

2. Step 2: Differentiate from other properties

   "NotActions" lists denied permissions, "permissions" is a container but not the direct property, and "allowedActions" is not a valid property.

3. Final Answer:

   "Actions" -> Option B

4. Quick Check:

   Allowed permissions = "Actions" [OK]

Hint: Allowed permissions are under "Actions" in JSON [OK]

Common Mistakes:

• Using "allowedActions" which is invalid
• Confusing "NotActions" with allowed permissions
• Mistaking "permissions" as direct actions list

3. Given this snippet of a custom role JSON:

{
  "Name": "Storage Reader",
  "Actions": ["Microsoft.Storage/storageAccounts/read"],
  "NotActions": []
}

What permission does this role grant?

medium

A. No permissions at all

B. Full control over storage accounts

C. Write access to storage accounts

D. Read access to storage accounts

Solution

1. Step 1: Analyze the "Actions" property

   The action "Microsoft.Storage/storageAccounts/read" grants read-only access to storage accounts.

2. Step 2: Check "NotActions" property

   It is empty, so no permissions are excluded.

3. Final Answer:

   Read access to storage accounts -> Option D

4. Quick Check:

   Action includes "read" = read access [OK]

Hint: Look for "read" in actions for read-only permission [OK]

Common Mistakes:

• Assuming full control from read action
• Confusing read with write permissions
• Ignoring empty NotActions meaning no exclusions

4. You created a custom role but users report they cannot perform allowed actions. Which is the most likely error in the role definition?

medium

A. Role description is missing

B. "Actions" property is missing or empty

C. "NotActions" includes the same actions as "Actions"

D. Role name is too long

Solution

1. Step 1: Understand "NotActions" effect

   "NotActions" excludes permissions even if listed in "Actions".

2. Step 2: Identify conflict in permissions

   If "NotActions" includes the same actions as "Actions", those permissions are denied, causing users to lack access.

3. Final Answer:

   "NotActions" includes the same actions as "Actions" -> Option C

4. Quick Check:

   Conflicting "NotActions" denies permissions [OK]

Hint: "NotActions" overrides "Actions" if overlapping [OK]

Common Mistakes:

• Ignoring "NotActions" effect
• Thinking role name or description affects permissions
• Assuming missing "Actions" is common

5. You want to create a custom role that allows users to start and stop virtual machines but denies deleting them. Which JSON snippet correctly defines this?

hard

A. { "Actions": ["Microsoft.Compute/virtualMachines/*"], "NotActions": ["Microsoft.Compute/virtualMachines/delete"] }

B. { "Actions": ["Microsoft.Compute/virtualMachines/start"], "NotActions": ["Microsoft.Compute/virtualMachines/delete"] }

C. { "Actions": ["Microsoft.Compute/virtualMachines/start", "Microsoft.Compute/virtualMachines/delete"], "NotActions": [] }

D. { "Actions": ["Microsoft.Compute/virtualMachines/delete"], "NotActions": ["Microsoft.Compute/virtualMachines/start"] }

Solution

1. Step 1: Identify required permissions

   Users need to start and stop VMs, so all VM actions except delete are allowed.

2. Step 2: Check each option

   { "Actions": ["Microsoft.Compute/virtualMachines/*"], "NotActions": ["Microsoft.Compute/virtualMachines/delete"] } allows all VM actions with "*" but denies delete explicitly, matching requirements perfectly.

3. Step 3: Eliminate incorrect options

   { "Actions": ["Microsoft.Compute/virtualMachines/start"], "NotActions": ["Microsoft.Compute/virtualMachines/delete"] } misses stop (deallocate) action; { "Actions": ["Microsoft.Compute/virtualMachines/start", "Microsoft.Compute/virtualMachines/delete"], "NotActions": [] } allows delete; { "Actions": ["Microsoft.Compute/virtualMachines/delete"], "NotActions": ["Microsoft.Compute/virtualMachines/start"] } denies start but allows delete.

4. Final Answer:

   { "Actions": ["Microsoft.Compute/virtualMachines/*"], "NotActions": ["Microsoft.Compute/virtualMachines/delete"] } -> Option A

5. Quick Check:

   Allow all except delete = Actions with * and NotActions delete [OK]

Hint: Use wildcard * in Actions and exclude delete in NotActions [OK]

Common Mistakes:

• Missing stop (deallocate) action
• Allowing delete action by mistake
• Denying start action instead of delete