A canal-survey team may restart VMs and read metrics but must not create disks or change NICs, and every nearby built-in compute role still includes extra write actions. What should the security engineer do?

Custom Azure roles are appropriate when built-in roles are overly broad for least privilege. For the canal-survey team that may restart VMs and read metrics but must not create disks or change NICs, the security engineer should clone the closest built-in compute-oriented role and trim Actions into a custom Azure role definition that keeps restart and monitoring reads while removing disk and NIC write operations. That produces an Azure RBAC role (not an Entra directory role) scoped to the needed assignable scopes.

Assigning Owner and using resource locks fails by concept: locks can block deletes or changes but Owner remains maximally privileged, locks are coarse, and operators may still perform many undesired writes that locks do not cover. Creating a Microsoft Entra custom role for Microsoft.Compute restart actions fails because Entra roles govern directory objects and tenant-wide identity tasks—they do not replace Azure RBAC for resource-manager compute actions on VMs. Switching to Azure Blueprints fails because Blueprints (or template specs/deployment stacks in modern practice) package deployments and policy; they do not eliminate the need to define least-privilege Azure roles when built-ins are too wide.

Exam caveat: custom Azure roles use Actions/NotActions and DataActions/NotDataActions; Entra custom roles are a different permission system. Operational check: create the custom role with trimmed Actions, assign it to the survey team at the correct scope, verify restart and metrics work, and confirm disk create and NIC update are denied.