Custom role definitions in Azure - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding the purpose of custom role definitions

What is the main reason to create a custom role definition in Azure?

A To automatically assign roles to all users in a subscription

B To grant permissions that are not available in built-in roles

C To restrict access to Azure portal settings only

D To create a backup of existing built-in roles

💡 Hint

Think about why built-in roles might not always fit every need.

Custom roles allow you to specify permissions that are not covered by built-in roles, enabling precise access control.

❓ Configuration

intermediate

Identifying valid JSON structure for a custom role

Which JSON snippet correctly defines a custom role with permission to read storage accounts?

A { "Name": "Storage Reader", "IsCustom": true, "Permissions": [{ "Actions": ["Microsoft.Storage/storageAccounts/read"] }], "AssignableScopes": ["/subscriptions/12345678-1234-1234-1234-123456789abc"] }

B { "Name": "Storage Reader", "IsCustom": true, "Actions": ["Microsoft.Storage/storageAccounts/read"], "NotActions": [], "AssignableScopes": ["/subscriptions/12345678-1234-1234-1234-123456789abc"] }

C } ]"cba987654321-4321-4321-4321-87654321/snoitpircsbus/"[ :"sepocSelbangissA" ,]} ]"daer/stnuoccAegarots/egarotS.tfosorciM"[ :"snoitcA" {[ :"snoissimreP" ,eurt :"motsuCsI" ,"redaeR egarotS" :"emaN" {

D { "Name": "Storage Reader", "IsCustom": true, "Actions": ["Microsoft.Storage/storageAccounts/read"], "AssignableScopes": ["/subscriptions/12345678-1234-1234-1234-123456789abc"] }

💡 Hint

Check the exact property names and structure required by Azure for custom roles.

Azure custom role definitions use PascalCase property names like 'Name', 'IsCustom', 'Permissions', and 'AssignableScopes'. The 'Permissions' property is an array of objects containing 'Actions' and 'NotActions'. Option A matches the standard structure used in Azure documentation.

❓ Architecture

advanced

Scope assignment impact on custom roles

You assign a custom role at the resource group level. What is the effect on access permissions?

A The role permissions apply only to the resource group and its parent subscription

B The role permissions apply to all subscriptions under the tenant

C The role permissions apply to all resource groups in the subscription

D The role permissions apply only to resources within that resource group

💡 Hint

Consider how Azure RBAC scopes permissions hierarchically.

Assigning a role at the resource group level limits permissions to that group and its resources only.

❓ security

advanced

Least privilege principle with custom roles

Which practice best follows the least privilege principle when creating custom roles?

A Grant all read permissions to simplify access

B Grant contributor role permissions to avoid missing access

C Grant only the specific actions needed for the user's tasks

D Grant permissions at the subscription level by default

💡 Hint

Least privilege means giving only what is necessary, nothing more.

Limiting permissions to only what is needed reduces security risks and follows best practices.

❓ service_behavior

expert

Effect of missing 'AssignableScopes' in custom role definition

What happens if you create a custom role definition in Azure without specifying the 'AssignableScopes' property?

A The role cannot be assigned to any scope and will cause an error

B The role is automatically assignable to all subscriptions in the tenant

C The role is assignable only to the subscription where it was created

D The role is assignable only to resource groups within the subscription

💡 Hint

Think about the role assignment process and required properties.

'AssignableScopes' is mandatory; without it, Azure rejects the role definition as it cannot be assigned anywhere.

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