AZ-500 Secure networking Practice Question

Exhibit

Refer to the exhibit.
```json
{
    "properties": {
        "policyRule": {
            "if": {
                "anyOf": [
                    {
                        "field": "type",
                        "equals": "Microsoft.Network/networkSecurityGroups/securityRules"
                    },
                    {
                        "field": "type",
                        "equals": "Microsoft.Network/virtualNetworks/subnets"
                    }
                ]
            },
            "then": {
                "effect": "deny"
            }
        },
        "parameters": {},
        "displayName": "Block NSG rules and subnet changes"
    }
}
```

You are a security engineer for Contoso. The company uses Azure Firewall for all inbound and outbound traffic. To prevent misconfiguration, you assign the Azure Policy shown in the exhibit at the management group scope. After assignment, a network administrator reports that they cannot create a new subnet in an existing virtual network. The subnet creation fails with a 'deny' policy error. You need to allow subnet creation while still blocking NSG rule changes. What should you do?

⚠ Common exam trap

A common mix-up: candidates think adding an exemption (Option C) is the easiest fix, but they overlook that exemptions apply to the entire scope and would also exempt NSG rule changes, defeating the primary security requirement.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Modify the policy rule to remove the subnet condition from the anyOf array.

The policy rule uses an `anyOf` array that includes conditions for both NSG rule changes and subnet creation. By removing the subnet condition from the `anyOf` array, the policy will no longer evaluate subnet creation against the deny effect, allowing subnets to be created while still blocking NSG rule modifications. This directly addresses the administrator's issue without weakening the security posture for NSG changes.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Change the effect to 'audit' instead of 'deny'.
Why it's wrong here
The `audit` effect in Azure Policy only logs a non-compliance event to the activity log after a resource is created or updated; it does not intercept the request, so an NSG rule change would still succeed. The scenario requires blocking NSG rule modifications, which means the `deny` effect must remain in place to prevent the operation in Resource Manager. An audit-only approach would fulfill reporting and alerting needs but fails the explicit security requirement.
✓
Modify the policy rule to remove the subnet condition from the anyOf array.
Why this is correct
The `anyOf` array in an Azure Policy definition is evaluated as an OR, so if a subnet-specific condition (e.g., `Microsoft.Network/virtualNetworks/subnets`) is included alongside NSG rule conditions, the deny effect will incorrectly apply to subnet creation. Removing the subnet condition from that array narrows the policy scope to only NSG rule changes, preserving the deny behavior exactly where required while no longer blocking subnets. This is the only option that directly corrects the over-broad policy logic without losing the intended NSG rule enforcement.
✗
Add an exemption for the virtual network resource group.
Why it's wrong here
Creating a policy exemption for the virtual network resource group would exclude all resources in that group from the policy assignment's evaluation, including both subnets and network security groups. This means NSG rule changes would no longer be blocked, which undermines the requirement that such changes be denied. Exemptions are meant for temporary or justifiable compliance exceptions, not for redesigning a policy's intended effect, and they would leave the security gap open.
✗
Remove the policy assignment and create a custom role to block subnet creation.
Why it's wrong here
Removing the policy assignment entirely eliminates the deny effect that blocks NSG rule changes, and a custom RBAC role that denies subnet writes only applies to principals assigned that role. It would not stop an Owner, service principal, or delegated administrator with broader permissions from creating subnets, and it leaves NSG rule changes completely unprotected without any compensating control. This approach is a fragmented, role-based workaround that introduces additional management complexity and fails to address the policy rule misconfiguration at its source.

Visual reference

Go deeper

AZ-500 Secure networking Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question