Resolving Windows Activation Failure Behind Azure Firewall

AZ-700 By islever Editorial Last updated

Design and implement Azure Firewall and Azure Firewall Manager

Short answer

B On FW1, create an outbound service tag rule for Azure Cloud to allow Windows Server VMs in Subnet1 to reach the Azure Key Management Service for activation.

Question

You have an Azure subscription that contains the following resources:
• A virtual network named Vnet1
• Two subnets named subnet1 and AzureFirewallSubnet
• A public Azure Firewall named FW1
• A route table named RT1 that is associated to Subnet1
• A rule routing of 0.0.0.0/0 to FW1 in RT1
After deploying 10 servers that run Windows Server to Subnet1, you discover that none of the virtual machines were activated.
You need to ensure that the virtual machines can be activated.
What should you do?
  1. Add an internet route to RT1 for the Azure Key Management Service (KMS).
  2. On FW1, create an outbound service tag rule for Azure Cloud. Correct Answer
  3. Deploy a NAT gateway.
  4. On FW1, configure a DNAT rule for TCP port 1688.

Key Takeaways

The main trap is confusing routing (RT1) with security policies (Firewall); even with a default route to the firewall, explicit allow rules are required for traffic to pass.

Learn how to fix Windows Server activation issues in Azure by configuring Azure Firewall outbound rules for the AzureCloud service tag.

Common mistake: Choosing Option A (adding an internet route) is a common mistake. This fails because the route table only dictates where traffic goes (to the firewall), but doesn't override the firewall's deny-by-default policy blocking the KMS traffic.

Expert Analysis

The scenario involves Windows Server VMs in Subnet1 failing to activate. Azure VMs use the Azure Key Management Service (KMS) for activation, which requires outbound connectivity to Microsoft's KMS infrastructure over TCP port 1688. The critical constraint is that a route table (RT1) with a default route (0.0.0.0/0) pointing to an Azure Firewall (FW1) forces all egress traffic through the firewall.

Azure Firewall operates on a deny-by-default policy for both application and network rules. Even though the route table directs traffic to FW1, the firewall itself must have an explicit rule allowing the traffic to pass. Without such a rule, the KMS activation requests are dropped at the firewall, causing activation failure.

Option B is correct because creating an outbound service tag rule for 'AzureCloud' on FW1 allows the necessary KMS traffic to exit the firewall. The AzureCloud service tag encompasses the IP ranges used by Azure infrastructure services, including KMS. While some might argue for a more specific KMS tag, AzureCloud is the standard broad allowance for general Azure service communication when specific tags aren't listed or available in older contexts, and it effectively resolves the blockage described.

Option A is incorrect because adding an internet route to RT1 does not solve the problem if the firewall blocks the traffic; the route just sends it to the firewall again. Furthermore, KMS traffic from Azure VMs often relies on Azure-specific routing behaviors that bypass public internet gateways unless specifically configured otherwise, but the primary blocker here is the firewall policy, not the next-hop IP resolution in the route table alone. Options C and D are irrelevant to the core issue of outbound access to Azure services.

Official Reference

https://learn.microsoft.com/en-us/azure/firewall/firewall-faq#why-cant-my-vms-reach-the-internet-or-azure-services

This link opens the official vendor documentation in a new tab.

Exam Strategy

Always distinguish between routing and security filtering. In Azure, a route table determines the next hop (e.g., to a Virtual Appliance), but the appliance itself enforces its own policies. If traffic is blocked after reaching an NVA like Azure Firewall, check the NVA's rules first, not just the route table configuration.

Frequently Asked Questions

Why can't Windows VMs activate when routed through Azure Firewall?

Windows VMs use Azure KMS for activation. Azure Firewall has a deny-by-default policy. If no outbound rule explicitly allows traffic to the AzureCloud service tag (which includes KMS endpoints), the activation packets are dropped.

Is the AzureCloud service tag too broad for KMS activation?

While broader than necessary, the AzureCloud service tag is the standard way to allow general Azure infrastructure communication in this exam context. It ensures KMS traffic passes without needing specific IP addresses.

More AZ-700 FAQ →

Community Votes

B
54%
A
46%

54% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 16 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 16

  1. nap61 👍 4 Answered B
    In this scenario, the virtual machines running Windows Server need to communicate with the Azure Key Management Service (KMS) for activation. The KMS is accessed over the internet, so ensuring that your virtual machines can reach KMS is crucial. To allow this, the most appropriate action is to create an outbound service tag rule for Azure Cloud on FW1. This will enable your virtual machines to connect to the necessary Azure services, including KMS, for activation. So, the correct answer is B. On FW1, create an outbound service tag rule for Azure Cloud.
  2. NK203 👍 4 Answered A
    Related question:topic 3 ,question 31.
  3. sismer 👍 3 Answered A
    The answer is KMS
  4. Silverpro29 👍 2 Answered B
    B. On FW1, create an outbound service tag rule for Azure Cloud. Why: • Azure VMs use KMS for activation, which is part of the Azure infrastructure. • Since all outbound traffic from Subnet1 is routed through Azure Firewall (FW1) (due to the 0.0.0.0/0 route in RT1), the firewall must explicitly allow traffic to Azure services. • The AzureCloud service tag includes the IP ranges used by Azure infrastructure services, including KMS.
  5. Patel777 👍 2 Answered B
    The Windows Server VMs are not activating. That means they're unable to reach Microsoft's KMS (Key Management Service), which is needed for activation. You’ve routed all outbound traffic from Subnet1 to Azure Firewall (FW1) via a route table (RT1), but Azure Firewall needs an outbound rule that allows traffic to AzureCloud.
Show 11 more comments
  1. ShanYuen 👍 2 Answered A
    There is no service tag that clearly state about Azure KMS, please correct me. So I prefer A
  2. Zorro2003 👍 1 Answered B
    Answer: B (On FW1, create an outbound service-tag rule for AzureCloud). All egress from Subnet1 goes to Azure Firewall (0.0.0.0/0 → FW1). Windows VMs must reach Microsoft’s KMS (kms.core.windows.net, TCP 1688) to activate. The issue is the firewall blocking that outbound traffic. Allowing outbound to the AzureCloud service tag (or specifically to KMS if using the AzureKMS FQDN tag) lets the VMs reach KMS and activate. A: UDR change isn’t needed—the route already sends traffic to the firewall. C: NAT Gateway isn’t required (Azure Firewall already does SNAT). D: DNAT is for inbound; activation needs outbound.
  3. StewieFTW22 👍 1 Answered A
    Changed to A. The Azure Windows VMs need to connect to the Azure KMS server for Windows activation. The activation requires that the activation request come from an Azure public IP address. https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/custom-routes-enable-kms-activation This means an RT next hop of "internet" for the correct source IP. The firewall public azure IP is different from the next hop internet public IP.
  4. GohanF2 👍 1 Answered A
    The answer is A. For Azure VMs with forced tunneling through Azure Firewall, Windows activation can fail because Azure VMs use the Azure-provided KMS service at 1688/tcp and the forced default route (0.0.0.0/0) sends that traffic to the firewall instead of to the Azure KMS endpoint. Microsoft specifically documents that the fix is to create a custom route exception for Azure KMS so that activation traffic bypasses the forced-tunnel path.
  5. StewieFTW22 👍 1 Answered B
    "After deploying 10 servers that run Windows Server to Subnet1, you discover that none of the virtual machines were activated." 1. Theres already an internet route that includes all destinations including KMS. 2. Therefore it must be related to security policy. 3. Even though the Azure cloud service tag is overly broad, it will indeed fix the activation issue.
  6. kewokil120 👍 1 Answered B
    we know nothing about the fw1 config. we have to assume that the next spot to check in troubleshooting. Missing default nat and or policy to allow kms. RT1 knows how to route to FW for KMS.
  7. DC095 👍 1
    Practically speaking, there is no reason to send KMS traffic through a firewall or NVA. That traffic should egress and be routed directly to KMS.
  8. xRiot007 👍 1
    You can also use an internet route, not just the cloud. So the correct answer can be either A or B.
  9. kewokil120 👍 1 Answered B
    RT1 knows how to route to FW for KMS.
  10. Sergovladi 👍 1
    looks like either A or B will work
  11. Bl4d3 👍 1 Answered A
    Redundant question. Ans. A

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Private Endpoint UDR Routing Prerequisite

S-grade

Minimum Azure Service Endpoints for Peered VNets

S-grade

Logging Application of Specific NSG Rules

S-grade

Azure DNS Private Resolver Minimum Deployment

S-grade

Practice All AZ-700 Questions

Access 100 questions with complete answers and detailed explanations.

View Full AZ-700 Practice Test →

← Back to AZ-700 Study Guide