A harbor-radar shop adds Microsoft.Compute/* to Actions and lists several delete operations under NotActions. A reviewer claims that creates a subscription-wide deny. What is the accurate statement about NotActions?

NotActions and NotDataActions exclude operations from the allowed set defined in the same role definition’s Actions or DataActions. They do not create a subscription-wide deny assignment. When the harbor-radar shop adds Microsoft.Compute/* to Actions and lists several delete operations under NotActions, those deletes are subtracted only from that role’s effective permissions. Other roles assigned to the same or different principals are unaffected; there is no courthouse-style injunction across the subscription.

Claiming NotActions creates an Azure deny assignment that overrides every other role fails by concept: deny assignments are a separate construct (often from blueprints/managed resources), not what NotActions emits. Treating NotActions as Azure Policy Deny fails because Policy Deny is evaluated in the policy engine against resource requests and properties, independent of a role definition’s NotActions list. Saying NotActions applies only at management-group scope fails: NotActions is part of the role definition regardless of whether assignable scopes are subscription, resource group, or management group, and it can trim a compute wildcard inside that definition.

Exam caveat: effective allowed operations are roughly Actions minus NotActions (and DataActions minus NotDataActions) within one role; multiple role assignments are additive unless a deny assignment applies. Operational check: assign only the trimmed custom role to a test principal, confirm permitted compute actions work, confirm listed deletes fail, then assign a second role that allows delete and observe that NotActions on the first role does not block the second role.