Azure RBAC Custom Role Best Practices or Common Build Patterns

The two-role pattern can work, but the important caveat is that Azure RBAC is additive. `NotActions` subtracts from that specific role assignment; it is not a deny. If the same user/group gets Contributor or Network Contributor at the same or parent scope through another assignment, your restricted custom role will not stop those permissions.

For this design I would usually do three things:

1. Prefer scope design first: put shared network resources such as VNets, route tables, firewall, DNS zones, and ExpressRoute in a protected platform/network resource group or subscription.

2. Give app teams normal Contributor only on app-owned resource groups.

3. For app-owned network objects such as private endpoints, NICs, or app gateways, use a narrow custom role with explicit `Microsoft.Network/.../read` plus only the exact write/delete actions required.

Also keep the custom role source-controlled and review it periodically, because new resource provider operations can appear over time.

Useful docs:

https://learn.microsoft.com/azure/role-based-access-control/custom-roles

https://learn.microsoft.com/azure/role-based-access-control/role-definitions

https://learn.microsoft.com/azure/role-based-access-control/deny-assignments