AZ-104 Implement and manage virtual networking: 130 practice questions

12 of the 130 Implement and manage virtual networking questions in the Certsqill AZ-104 bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AZ-104? Take the free 5-min readiness check →

1. Create a direct peering between AppVNet and DataVNet: Which action meets this requirement?

1. Create a direct peering between AppVNet and DataVNet. ✓

   Direct peering connects the two required VNets over the Microsoft backbone, and their nonoverlapping address spaces satisfy the stated prerequisite.
2. Create a private DNS zone link from DataVNet to AppVNet.

   A private DNS VNet link supports name resolution for a zone; it does not connect the VNets or provide network communication between their VMs.
3. Rely on the existing AppVNet-to-HubVNet and HubVNet-to-DataVNet peerings.

   VNet peering is not transitive. The two existing peerings do not create connectivity between AppVNet and DataVNet.
4. Link the existing private DNS zone to both AppVNet and DataVNet.

   Linking a private DNS zone to both VNets can enable DNS resolution in each VNet, but peering is still required for the requested VM-to-VM network connectivity.

Create direct peering between AppVNet and DataVNet; existing peering through HubVNet is not transitive.

2. Create a virtual network link from corp.internal: Which change is still required?

1. Create a second peering connection between the hub VNet and the spoke VNet.

   The VNets are already peered. Additional peering does not create the private DNS zone link required for spoke VMs to resolve the zone.
2. Add an NSG rule allowing DNS traffic between the hub and spoke VNets.

   An NSG rule can affect network traffic, but it does not configure the private DNS zone link that enables VNet-based resolution.
3. Create a virtual network link from corp.internal to the spoke VNet with autoregistration disabled. ✓

   The spoke VNet needs its own link to the private DNS zone for its VMs to resolve records. Autoregistration is unnecessary because the requirement is resolution, not automatic VM-record registration.
4. Enable automatic VM registration on the existing hub-VNet link.

   That changes registration behavior for the hub link but does not link corp.internal to the spoke VNet, so spoke VMs still lack the required DNS-zone link.

Peering provides network connectivity but does not substitute for a private DNS zone link. Link corp.internal to the spoke VNet; use resolution-only behavior when autoregistration is not required.

3. Create a direct peering between App-VNet and Data-VNet: What should you do?

1. Add an allow rule to the App-VNet subnet NSG for the Data-VNet address space.

   The stated NSGs already permit the required traffic. An NSG rule controls traffic filtering; it does not establish connectivity between non-directly peered VNets.
2. Create a private DNS zone link from Data-VNet to App-VNet.

   A DNS link can enable name resolution for a private DNS zone, but it does not connect the VNets or provide network traffic connectivity.
3. Create a direct peering between App-VNet and Data-VNet. ✓

   This supplies the missing direct peering. VNet peering is not transitive, so the existing two peerings do not provide App-VNet-to-Data-VNet connectivity.
4. Add another peering between App-VNet and Hub-VNet.

   The VNets are already peered. Adding another peering to Hub-VNet does not create the missing App-VNet-to-Data-VNet path because peering is not transitive.

Create direct peering between App-VNet and Data-VNet; VNet peering is not transitive.

4. Add an allow rule to the WebSubnet NSG for AppSubnet: Which change will allow the connections?

1. Change the NIC-level allow rule priority from 100 to 150.

   Changing only the NIC rule does not override a deny in an applicable subnet NSG.
2. Add an allow rule to the WebSubnet NSG for AppSubnet, TCP 443, at priority 100. ✓

   The new subnet-level allow is evaluated before the priority-200 deny, and both the subnet and NIC NSGs then permit the traffic.
3. Add an allow rule to the WebSubnet NSG for AppSubnet, TCP 443, at priority 300.

   The priority-200 deny is evaluated first and matches, so the later allow is not reached.
4. Add an allow rule to the WebSubnet NSG for AppSubnet, TCP 443, at priority 250, and rely on the NIC allow at priority 100.

   The subnet-level deny at priority 200 still matches before the new subnet allow; the NIC allow cannot override it.

Choose the subnet-level allow with a priority lower than the existing deny. The subnet NSG must permit the traffic as well as the NIC NSG.

5. Link the private DNS zone to VNet-B: Which action verifies that the requested DNS resolution works?

1. Send a network connectivity test to the record’s resolved IP address from the VM in VNet-B without linking the private DNS zone to VNet-B.

   Testing connectivity to an IP address does not verify DNS resolution, and VNet-B still lacks the required private DNS zone link.
2. Keep the existing link only to VNet-A and run the DNS lookup from the VM in VNet-B because the VNets are peered.

   VNet peering is not a substitute for a private DNS link. VNet-B requires its own link to resolve records from the zone.
3. Check that the peering between VNet-A and VNet-B is in a connected state, then conclude that the VM can resolve the record.

   Peering connectivity does not configure a private DNS zone link, so its status does not verify name resolution from VNet-B.
4. Link the private DNS zone to VNet-B, then run a DNS lookup for app.internal.contoso.com from the VM in VNet-B. ✓

   A virtual network link is required for VMs in that VNet to resolve records in a private DNS zone. The lookup tests the requested result directly.

Link the private DNS zone to VNet-B and perform a DNS lookup from its VM. Peering alone does not provide private DNS resolution.

6. Use a subnet NSG: Which configuration meets the requirement with the least administrative effort?

1. Add an outbound deny rule for TCP 3389 from the VM subnet to the internet, using priority 100, and add no inbound rules.

   The requirement concerns new inbound connections to the VMs. An outbound rule does not filter those inbound RDP attempts, regardless of its priority.
2. Use a subnet NSG: allow admin-subnet RDP at 100; deny internet RDP at 200. ✓

   The subnet-level NSG applies the inbound policy to every VM in the subnet. The lower-priority-number allow is evaluated first for administrative traffic, while the deny blocks internet RDP; both rules specify the required direction, protocol, port, and sources.
3. Attach an NSG to the subnet with an inbound allow for TCP 3389 from Internet at priority 100.

   Allowing RDP from the internet violates the required source restriction.
4. Attach an NSG to the subnet with an inbound deny for TCP 3389 from all sources at priority 100.

   A deny for all sources also prevents the required administrative-subnet connections.

Use a subnet-level NSG with a specific administrative-subnet allow at priority 100 and an internet deny at priority 200.

7. Remove the AppSubnet outbound deny rule for 10.20.1.0/24: What should the administrator do?

1. Remove the AppSubnet outbound deny rule for 10.20.1.0/24 on TCP 443. ✓

   The subnet NSG evaluates the deny first, so the later allow cannot permit the new flow. Removing the matching deny allows the private-endpoint HTTPS traffic, assuming the NIC-side rules also permit it.
2. Create a second private endpoint for the storage account in AppSubnet.

   The existing private endpoint already provides a private address, and DNS resolves the app to that address. Duplicating the endpoint does not remove the subnet NSG deny.
3. Disable public network access on the storage account.

   That setting controls public access; it does not permit the blocked private HTTPS flow through AppSubnet. The failing flow is stopped by the subnet NSG before this change can help.
4. Change the NIC-side allow rule for TCP 443 to a numerically lower priority.

   A lower-priority number on the NIC NSG cannot override a matching deny on the subnet NSG. Traffic must be permitted by both NSGs.

Remove the matching subnet NSG deny. NSG evaluation is required at both scopes, and the subnet deny is encountered before its later allow.

8. Add a subnet NSG allow rule for TCP 22 from 10.20.1.0/24: What is the smallest correction?

1. Change the subnet deny-all rule's priority from 200 to 300.

   The NIC allow rule does not override a subnet deny, and moving the deny to priority 300 still leaves it ahead of any lower-priority matching subnet rule that is not added.
2. Add a subnet NSG allow rule for TCP 22 from 10.20.1.0/24 at priority 100. ✓

   The subnet allow at priority 100 is evaluated before its deny at 200; the NIC also allows this traffic.
3. Add an outbound allow rule for TCP 22 to the VM subnet NSG.

   An outbound allow does not remove the inbound deny that blocks the requested new connection.
4. Change the NIC allow rule's priority from 200 to 100.

   A higher-priority NIC rule cannot override the subnet NSG's matching deny. Traffic must be permitted by both applied NSGs.

Add an inbound subnet allow at priority 100 for the required source and port, before the deny at priority 200.

9. Create a private endpoint for the App Service: Which configuration should the administrator implement?

1. Create a private endpoint for the App Service and rely on that endpoint alone to block all public access, without changing the App Service public network access setting.

   Creating a private endpoint does not by itself guarantee that public access is disabled; the service's public network access setting must be configured explicitly.
2. Keep VNet integration and configure its delegated subnet so that clients can use the integration path to connect inbound to the App Service; then disable public network access.

   VNet integration provides outbound access from the App Service to virtual-network resources; it does not provide private inbound access to the app.
3. Create a private endpoint for the App Service in the virtual network, configure private DNS resolution for the app hostname, and disable public network access on the App Service. ✓

   A private endpoint provides private inbound connectivity through a private IP. DNS must resolve the app name to that private endpoint, and public access must be disabled explicitly.
4. Create a private endpoint for the App Service, but leave DNS unchanged because private endpoint creation automatically makes clients resolve the app hostname to its private IP.

   The private endpoint supplies the private network interface, but clients still require appropriate DNS resolution for the service name.

Use a private endpoint for private inbound access, configure DNS for the private address, and explicitly disable public network access.

10. From the app runtime: Which verification step best confirms the requested private outbound connectivity from t

1. Verify that the private endpoint exists in the virtual network, then test whether a client can initiate a private inbound connection to the App Service through VNet integration.

   VNet integration provides outbound access from the app; it does not provide private inbound access to the app. The test also targets the wrong traffic direction.
2. Confirm in the portal that the private endpoint and the App Service VNet integration connection both show a successful provisioning state.

   Provisioning state confirms resource configuration, not that the app resolves the service name privately or can reach the service.
3. From the app's runtime environment, resolve the service hostname and confirm that it returns an address, without sending a request to the service.

   Name resolution alone does not verify network connectivity or that the app can use the service; DNS and connectivity are separate concerns.
4. From the app runtime, confirm private DNS resolution and a successful authenticated request. ✓

   This tests the result from the app: DNS resolution to the private address and actual outbound access. Authentication remains a separate requirement, so an authenticated request verifies both connectivity and usable access.

Test from the app itself: resolve the service name to the private endpoint address and complete an authenticated request.

11. Create a resolution-only virtual network link: Which action meets the requirement with the least administrativ

1. Create a resolution-only virtual network link from priv.contoso.internal to AppVNet. ✓

   A resolution-only link lets VMs in AppVNet resolve records in the private DNS zone without enabling automatic VM record registration.
2. Create a resolution-only virtual network link from priv.contoso.internal to a different VNet and leave AppVNet unlinked.

   The link must target AppVNet for its VMs to resolve records in the private DNS zone; linking another VNet does not provide that scope.
3. Create a registration-enabled virtual network link from priv.contoso.internal to AppVNet.

   This links the correct VNet, but registration-enabled links automatically register VM records, which violates the requirement.
4. Peer AppVNet with another VNet that is linked to the private DNS zone, leaving AppVNet unlinked.

   Peering does not itself grant AppVNet resolution through that private zone. AppVNet needs an appropriate DNS configuration.

Use a resolution-only private DNS zone link to AppVNet. It enables resolution without automatic VM record registration.

12. Change the existing HTTPS probe path to `/ready`: What should you do to make backend eligibility reflect appli

1. Leave the probe on `/` because it returns HTTP 200, and create an additional load-balancing rule for `/ready`.

   A load-balancing rule does not change what the health probe verifies. The existing probe would still mark an instance healthy based on `/`, which can conceal application unavailability.
2. Replace the HTTPS probe with a TCP probe so a successful TLS connection marks the instance healthy.

   A connection or certificate handshake does not test HTTP application readiness. This would allow an instance that accepts connections but returns HTTP 503 from `/ready` to remain eligible.
3. Change the existing HTTPS probe path to `/ready` and ensure the application returns HTTP 200 there only when it is ready. ✓

   The probe determines eligibility for new flows, and an HTTP/HTTPS probe requires HTTP 200 on its configured path. Testing the readiness endpoint prevents unready instances from being selected.
4. Add a virtual network peering connection between the client VNet and the backend VNet so the probe can reach `/ready`.

   Peering connects VNets but does not configure or change Load Balancer probe behavior. The scenario already states that probe traffic is allowed by the NSG.

Use the existing HTTPS probe against the readiness path and require HTTP 200. The current root-path probe validates an unrelated endpoint, so it can mark an unready backend eligible.

Other AZ-104 domains

• Manage Azure identities and governance — 186 questions →
• Deploy and manage Azure compute resources — 169 questions →
• Implement and manage storage — 141 questions →
• Monitor and maintain Azure resources — 96 questions →
• All 722 AZ-104 questions →