While preparing for the AZ-104 (Microsoft Azure Administrator), many candidates struggle with Azure Policy’s role in network security governance. In the enterprise world, this decision often hinges on centralized compliance enforcement vs. manual configuration sprawl. Let’s drill into a simulated governance scenario.
The Scenario #
You work as an Azure Administrator for Fabrikam Manufacturing, a multi-regional enterprise with 10 virtual networks distributed across different resource groups in a single Azure subscription. These VNets host production workloads for various business units including supply chain management, warehouse automation, and customer portals.
Another administrator from the Security Operations team has been tasked with deploying multiple Network Security Groups (NSGs) to enforce micro-segmentation policies. The CISO has mandated that all future NSGs must automatically block TCP port 8080 traffic between virtual networks due to a recent security audit that identified unsecured application-to-application communication on this port.
Your Infrastructure Lead asks: “Can we use Azure Policy to enforce this requirement automatically whenever any administrator creates a new NSG?”
Key Requirements #
Ensure that when any Network Security Group is created in the subscription, it automatically blocks TCP port 8080 traffic between virtual networks, without requiring manual configuration by administrators.
The Proposed Solution #
Configure a custom Azure Policy definition, then assign that policy to the subscription.
The Options #
- A) Yes, this solution meets the goal
- B) No, this solution does not meet the goal
- C) -
- D) -
Correct Answer #
A) Yes.
The Architect’s Analysis #
Correct Answer #
Option A: Yes, this solution meets the goal.
Step-by-Step Winning Logic #
Azure Policy is the native governance service for enforcing organizational standards and compliance at scale. Here’s why this solution works:
-
Custom Policy Definitions: You can create a custom Azure Policy that evaluates NSG security rules during creation or modification.
-
Effect Types Available:
- Deny: Prevent creation of NSGs that don’t include the required deny rule for TCP 8080
- Append: Automatically add the deny rule to any NSG being created
- DeployIfNotExists: Remediate existing NSGs by deploying the required rule
-
Assignment Scope: Assigning the policy at the subscription level ensures all resource groups inherit the enforcement, regardless of where NSGs are created.
-
Alignment with Well-Architected Framework:
- Security: Enforces defense-in-depth by preventing insecure configurations
- Operational Excellence: Eliminates human error through automation
- Cost Optimization: Reduces security incident response costs
-
CAF Governance Discipline: This approach aligns with the Resource Consistency and Security Baseline disciplines in Microsoft’s Cloud Adoption Framework.
The Trap (Distractor Analysis) #
Why might candidates choose “No”?
-
Misconception about Policy Scope: Some believe Azure Policy only works for Azure resource types (like VM SKUs or storage accounts), not for configuration within NSGs. In reality, Policy can evaluate properties deep within resource configurations, including NSG security rules.
-
Confusion with Azure Firewall: Candidates might think you need Azure Firewall or Network Virtual Appliances to enforce inter-VNet traffic rules. While those are valid tools, they’re not required for this requirement—Policy can enforce the configuration at the NSG level.
-
Manual Remediation Assumption: Some believe Policy only provides compliance reporting, not enforcement. However, Deny and Append effects actively prevent or modify resource creation.
The Architect Blueprint #
Diagram Note: The Azure Policy Engine intercepts NSG creation requests and evaluates them against the custom policy definition before allowing deployment, ensuring automatic compliance.
The Decision Matrix #
| Option | Implementation Complexity | Est. Setup Time | Pros | Cons |
|---|---|---|---|---|
| A) Azure Policy (Custom Definition) | Medium (requires JSON authoring) | 1-2 hours | ✅ Centralized governance ✅ Automatic enforcement ✅ Audit trail ✅ Scales to 1000+ NSGs |
⚠️ Requires Policy authoring knowledge ⚠️ Testing needed before production |
| B) Azure Blueprints | High (over-engineered) | 4-6 hours | ✅ Bundles multiple policies ✅ Versioning support |
❌ Overkill for single requirement ❌ Deprecated in favor of Template Specs + Policy |
| C) Manual Configuration | Low (per-instance) | 5 min/NSG × quantity | ✅ Simple for 1-2 NSGs | ❌ No enforcement ❌ Human error risk ❌ Doesn’t scale |
| D) Azure Firewall with Forced Tunneling | Very High | 2-3 days | ✅ Centralized inspection | ❌ High cost (~$1,250/month) ❌ Requires hub-spoke topology refactor ❌ Over-engineered |
Cost Note: Azure Policy itself has no direct cost—you pay only for the Azure resources being governed. Azure Firewall Standard costs approximately $1.25/hour + data processing fees.
Real-World Practitioner Insight #
Exam Rule #
“For the AZ-104 exam, when you see requirements for automatic enforcement across multiple resources or preventing non-compliant configurations, always consider Azure Policy with Deny or Append effects. If the question mentions ‘automatically’ + ‘all future resources’, Policy is typically the correct answer.”
Real World #
“In production environments at enterprises like Fabrikam, we typically combine Azure Policy with Azure Security Center (Defender for Cloud) recommendations. While Policy enforces the configuration, Defender for Cloud provides:
- Threat detection on ports that are allowed
- Network topology visualization
- Just-In-Time VM access to further reduce attack surface
We also implement a grace period for existing NSGs using the DoNotEnforce mode initially, giving teams 30 days to remediate before switching to full enforcement. This prevents breaking production workloads that legitimately use port 8080 for internal communication (like certain Java application servers).
Additionally, we use Policy Initiatives (bundles of policies) to group this NSG rule with other network security requirements, such as:
- Enforcing NSG flow logs enabled
- Requiring NSGs on all subnets except GatewaySubnet
- Blocking RDP (3389) and SSH (22) from the internet”
Implementation Tip: Use the Azure Policy extension for VS Code to author and test custom definitions locally before deploying to production subscriptions.