Skip to content

5 Free AZ-104 Networking Practice Questions

Practise Azure networking with five original questions from the Pass104 question bank. Work through forced tunneling over ExpressRoute, split-horizon private DNS, Application Gateway end-to-end TLS, layered NSGs with application security groups, and Network Watcher troubleshooting. Every answer includes a worked explanation and Microsoft Learn sources. No account required.

Start with question 1
Work through the set

Four choices per question. Think through your answer, then open the explanation to check it.

5 questions · networking · no timer

What these networking questions cover

The Microsoft AZ-104 study guide lists virtual networking as 15–20% of the exam. This set covers selected skills in the objectives effective 17 April 2026; it is not a complete domain assessment.

Read each scenario, choose an answer, then open the explanation. All five questions and answers are free on this page. In the app, the free plan gives you one 6-question exam a day across all domains; networking-only practice is a Pro feature.

Question 1 of 5Forced tunneling over ExpressRoute

Wide World Importers connects its on-premises network to VNet1 through an ExpressRoute circuit with private peering. The only gateway in VNet1 is a virtual network gateway of type ExpressRoute in GatewaySubnet, and it exchanges routes with the on-premises edge routers over BGP. A new policy requires all internet-bound traffic from Subnet1 to be forced through the on-premises network so that it passes the corporate security stack before reaching the internet. Traffic from Subnet1 to on-premises destinations must keep its current path. What should you do?

  1. Configure the on-premises edge routers to advertise a 0.0.0.0/0 default route to Azure over BGP
  2. Associate a route table with Subnet1 that contains 0.0.0.0/0 with next hop type Virtual network gateway
  3. Associate a route table with Subnet1 that contains 0.0.0.0/0 with next hop type Virtual appliance and the private IP address of the ExpressRoute gateway
  4. Disable gateway route propagation on the route table associated with Subnet1, and add 0.0.0.0/0 with next hop type None
Show answer and explanation

Correct answer: A · Configure the on-premises edge routers to advertise a 0.0.0.0/0 default route to Azure over BGP

A user-defined route with next hop type Virtual network gateway is supported only when the virtual network’s gateway is a VPN gateway, not an ExpressRoute gateway. With ExpressRoute, forced tunneling is done by advertising a default route into private peering. Azure learns 0.0.0.0/0 over BGP, and for the same prefix a BGP route beats the system Internet route, so internet-bound traffic goes on-premises. The more specific on-premises prefixes still win by longest prefix match, so that traffic is unchanged. The learned default route reaches every subnet with gateway route propagation enabled; any subnet that must keep direct internet access needs its own 0.0.0.0/0 route with next hop Internet.

Why the other choices do not fit

  • B. This is the standard forced-tunneling step for a site-to-site VPN, which is why it looks right. Microsoft documents that you can’t create user-defined routes that force traffic to an ExpressRoute gateway, so it does not work in VNet1.
  • C. The ExpressRoute gateway is not a network virtual appliance, and a Virtual appliance next hop that has to route through an ExpressRoute gateway makes the route invalid. It cannot be used to hand traffic to the gateway.
  • D. Next hop None drops internet-bound traffic instead of tunneling it. Disabling propagation also removes the on-premises routes learned over BGP from Subnet1, which breaks the traffic that must keep its current path.
Question 2 of 5Private DNS zones and split-horizon

Adatum Corporation hosts the public zone adatum.com in Azure DNS. Internet customers reach the apex, adatum.com, through an alias record that points to an Azure Front Door profile. Employees on virtual machines in VNet1, which uses Azure-provided DNS, must instead reach an internal application server at 10.10.1.20 when they browse to adatum.com. Resolution from the internet must not change, no traffic from VNet1 may go to the public Front Door endpoint, and administrative effort must be minimized. What should you do?

  1. Create an Azure private DNS zone named adatum.com, link it to VNet1, and add a CNAME record at the zone apex that points to the internal server’s host name
  2. Create an Azure private DNS zone named adatum.com, link it to VNet1, and add an A record at the zone apex for 10.10.1.20
  3. In the public adatum.com zone, add an A record at the apex for 10.10.1.20 alongside the existing alias record
  4. Deploy a DNS server virtual machine in VNet1, configure VNet1 to use it, and add a conditional forwarder that sends adatum.com queries to the Azure DNS name servers hosting the public zone
Show answer and explanation

Correct answer: B · Create an Azure private DNS zone named adatum.com, link it to VNet1, and add an A record at the zone apex for 10.10.1.20

Azure DNS supports split-horizon: a private zone and a public zone can share the same name. Only virtual networks linked to the private zone resolve from it, so VNet1 gets 10.10.1.20 while internet clients still receive the Front Door answer from the public zone. An A record at the apex of a private zone is valid. Once linked, VNet1 resolves every adatum.com name from the private zone, so add any other adatum.com names VNet1 still needs, such as www, to the private zone as well.

Why the other choices do not fit

  • A. The private zone and link are right, but DNS does not allow a CNAME at a zone apex, where the SOA and NS records already live. Azure DNS rejects the record.
  • C. The apex alias record set is the A record set for that name, so a separate A record set cannot sit beside it. Anything added to the public zone is also served to the internet, which changes external resolution and publishes a private address.
  • D. Forwarding to the servers that host the public zone returns the same Front Door answer, so VNet1 traffic still goes to the public endpoint. It also adds a virtual machine to run and patch.
Question 3 of 5Application Gateway end-to-end TLS

You plan to publish an application through a new Application Gateway v2 named CTS-GW1. Clients connect to https://app1.contoso.com on TCP port 443, and the gateway must present a certificate issued to app1.contoso.com. Requests for /api/* must reach back-end pool Pool2, and all other requests must reach Pool1. Traffic from CTS-GW1 to the back-end virtual machines must also be encrypted. The virtual machines already present server certificates for app1.contoso.com issued by Contoso’s internal certification authority, and no additional certificate may be installed on them. Which configuration should you use?

  1. An HTTPS listener on port 443 with the app1.contoso.com certificate; back-end settings set to HTTPS without adding any trusted root certificate; a path-based rule that maps /api/* to Pool2 and the default path to Pool1
  2. A listener configured for TLS passthrough on port 443; the app1.contoso.com certificate installed on each back-end virtual machine; a path-based rule that maps /api/* to Pool2 and the default path to Pool1
  3. An HTTPS listener on port 443 with the app1.contoso.com certificate; back-end settings set to HTTPS with the internal CA’s root certificate added as a trusted root certificate; a path-based rule that maps /api/* to Pool2 and the default path to Pool1
  4. An HTTPS listener on port 443 with the app1.contoso.com certificate; back-end settings set to HTTPS with the internal CA’s root certificate added as a trusted root certificate; a multi-site rule that maps the host name app1.contoso.com to Pool2
Show answer and explanation

Correct answer: C · An HTTPS listener on port 443 with the app1.contoso.com certificate; back-end settings set to HTTPS with the internal CA’s root certificate added as a trusted root certificate; a path-based rule that maps /api/* to Pool2 and the default path to Pool1

The HTTPS listener terminates client TLS with the app1.contoso.com certificate, which lets the gateway read the URL path for path-based routing. Setting the back-end protocol to HTTPS makes the gateway open a new TLS connection to each server, which is end-to-end TLS. The v2 SKU trusts back-end certificates from well-known CAs automatically, but a certificate from an internal CA is trusted only if its root matches a trusted root certificate in the back-end settings. The gateway also checks that the certificate name matches the host name it uses for the back end, here app1.contoso.com.

Why the other choices do not fit

  • A. Without the internal CA’s root certificate, the v2 gateway cannot build a trusted chain for the back-end certificates. It marks every server unhealthy, and no requests are routed.
  • B. Path-based routing requires the gateway to decrypt the request and read its URL, so it cannot be combined with passing TLS through untouched. This option also installs certificates on the virtual machines, which the scenario forbids.
  • D. The certificates are handled correctly, but a multi-site rule selects a pool by host name. Every request here uses app1.contoso.com, so the rule cannot separate /api/* from other paths, and all traffic would go to Pool2.
Question 4 of 5NSGs and application security groups

In VNet-Fin, web servers run in Subnet-Front, and their network interfaces are members of the application security group ASG-WebTier. Database servers run in Subnet-Back, which is associated with NSG-Back. NSG-Back contains a custom inbound rule that denies traffic from any source at priority 4000. Each database server’s network interface is associated with NSG-DB, which contains only the default rules. The web servers must connect to the database servers on TCP port 1433, all other inbound traffic to the database servers must be blocked, and you must use the fewest security rules. What should you do?

  1. In NSG-DB, create an inbound rule that allows TCP 1433 from ASG-WebTier at priority 100
  2. In NSG-Back, create an inbound rule that allows TCP 1433 from ASG-WebTier at priority 4096
  3. In both NSG-Back and NSG-DB, create an inbound rule that allows TCP 1433 from ASG-WebTier at priority 100
  4. In NSG-Back, create an inbound rule that allows TCP 1433 from ASG-WebTier at priority 100
Show answer and explanation

Correct answer: D · In NSG-Back, create an inbound rule that allows TCP 1433 from ASG-WebTier at priority 100

Inbound traffic is evaluated by the subnet NSG first and then by the NIC NSG, and both must allow it. In NSG-Back, an allow at priority 100 matches before the deny at 4000, because lower numbers are processed first. NSG-DB already permits the web servers through its default AllowVnetInBound rule, because both tiers are in VNet-Fin. Everything else is still stopped by the deny at 4000 in NSG-Back. Using the ASG as the source is valid because the web and database interfaces are in the same virtual network.

Why the other choices do not fit

  • A. NSG-DB already allows this traffic through AllowVnetInBound. The block is the deny at 4000 in NSG-Back, which is evaluated first for inbound traffic and is not changed.
  • B. Priority 4096 is valid for a custom rule, but it is processed after the deny at 4000. The deny still matches the traffic first.
  • C. This works, but the NSG-DB rule is redundant because the default AllowVnetInBound rule already permits the traffic. Two rules fail the fewest-rules requirement.
Question 5 of 5Network Watcher troubleshooting

VNet1 and VNet2 are peered. VM1 (10.1.0.4, in VNet1) cannot reach VM2 (10.2.0.4, in VNet2) on TCP port 443. Another team recently deployed a network virtual appliance and several route tables. IP flow verify on VM1 for an outbound packet to 10.2.0.4:443 returns Allow, matched by AllowVnetOutBound. IP flow verify on VM2 for the corresponding inbound packet from 10.1.0.4 also returns Allow. The service on VM2 is listening, and its guest firewall allows TCP 443. You need to identify the cause with the fewest additional steps. What should you do?

  1. View the effective security rules on the network interface of VM1
  2. Run Next hop from VM1 with a destination IP address of 10.2.0.4
  3. Start a Network Watcher packet capture on VM2 filtered to TCP port 443
  4. Enable VNet flow logs on VNet1 and review the data in traffic analytics
Show answer and explanation

Correct answer: B · Run Next hop from VM1 with a destination IP address of 10.2.0.4

IP flow verify evaluates the effective NSG rules on each network interface. Allow results in both directions rule out NSG filtering, so the likely cause is the path. Next hop returns the next hop type, next hop IP address and route table ID for the destination. A VirtualAppliance result with a route table ID shows that a user-defined route is sending the traffic to the new appliance. A VirtualNetworkPeering result from System Route shows that routing from VM1 is normal.

Why the other choices do not fit

  • A. Effective security rules lists the same NSG rules that IP flow verify has already evaluated. It cannot show where a route sends the packet.
  • C. A capture on VM2 can show that packets never arrive, but not where they went instead. It also needs a capture session and a reproduced failure.
  • D. Flow logs need to be enabled, then collect data, and traffic analytics processes it in intervals. Even then, they record flows rather than the route that sends traffic elsewhere.

These original practice questions are adapted from the Pass104 question bank. They are not actual Microsoft exam questions and do not reproduce or predict exam difficulty or results. The selected answers and explanations were checked against the linked Microsoft Learn documentation on 26 September 2026. Azure services and exam objectives can change, so use the references for the latest details. Pass104 is independent of Microsoft.