Why Custom role definitions in Azure? - Purpose & Use Cases

The Big Idea

What if you could stop worrying about who can do what in your cloud with just one simple setup?

The Scenario

Imagine you are managing access for a team in your cloud environment. You try to give each person exactly the permissions they need by clicking through many settings manually for every user.

The Problem

This manual approach is slow and confusing. You might give too many permissions by mistake or forget some, causing security risks or blocking work. Fixing these errors takes even more time.

The Solution

Custom role definitions let you create a precise set of permissions once. Then you assign this role to anyone who needs it. This saves time, reduces mistakes, and keeps your cloud secure.

Before vs After

✗ Before

Assign built-in roles one by one to each user.

✓ After

Create a custom role with exact permissions and assign it to users.

What It Enables

You can control who does what in your cloud with clear, reusable permission sets tailored to your team's needs.

Real Life Example

A company creates a custom role that allows developers to deploy apps but not delete resources, ensuring safety while enabling productivity.

Key Takeaways

Manual permission setup is slow and error-prone.

Custom roles let you define exact permissions once.

This improves security and saves time managing access.

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