A Deny-public-IP Azure Policy assignment at the management group must stay in force, but one lock-lab sandbox resource group needs temporary relief. What should the security engineer create?

When a Deny-public-IP Azure Policy assignment must remain at the management group for the canal estate, temporary relief for one lock-lab sandbox resource group is granted with a policy exemption at that narrower scope. Exemptions are typically categorized (for example waiver or mitigated), can be time-boxed, and leave the parent assignment evaluating everywhere else. That pattern preserves the Deny effect for production waterway resources while the sandbox project proceeds under documented, reviewable relief.

Deleting the management-group assignment until the sandbox finishes fails by concept because it removes Deny-public-IP enforcement for every subscription under the group, not just the lab. Creating an Azure RBAC deny assignment on the sandbox that “blocks the Policy engine” fails because RBAC deny assignments restrict principals’ Azure RBAC actions; they are not the supported mechanism to carve exceptions out of Azure Policy. Assigning Owner on the sandbox so operators can ignore non-compliant deployments fails because Owner does not neutralize a Deny policy effect—non-compliant creates still fail, and broad Owner violates least privilege.

Exam caveat: AZ-500 expects exemptions (or temporary assignment redesign) rather than deleting a hierarchical Deny for one lab. Operational check: create the exemption on the sandbox resource group with category and expiry, verify Policy still shows the management-group assignment active, deploy a public IP in the sandbox under the exemption window, and confirm a sibling production resource group still denies the same template.