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

12 of the 149 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. Change the AppSubnet NSG outbound TCP 443 deny to an allow: Which two actions will allow the new connection?

Select two. More than one option is correct — every correct one is ticked below.

1. Create VNet peering between the application and database VNets.

   Peering provides network connectivity but does not remove the AppSubnet or DbSubnet NSG restrictions.
2. Change the database NIC allow rule from priority 200 to priority 100.

   Changing only the NIC rule does not override a deny in an applicable subnet NSG.
3. Change the AppSubnet NSG outbound TCP 443 deny to an allow rule. ✓

   The source-side NSG must permit the outbound connection; its priority-100 deny currently blocks it.
4. Change the DbSubnet NSG inbound TCP 443 deny to an allow rule. ✓

   The subnet NSG must permit inbound traffic. The existing NIC allow cannot override the subnet-level deny.
5. Wait for the current NSG rules to affect the connection without changing them.

   The question concerns a new connection, and the existing deny rules will continue to block it; waiting does not change effective rule evaluation.

Choose A and B. Both the source-side outbound path and destination-side inbound path must be permitted; the NIC allow does not override a subnet deny.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. Configure DNS so the app's service name resolves: Which two actions should the administrator take?

Select two. More than one option is correct — every correct one is ticked below.

1. Configure DNS so the app's service name resolves to the private endpoint address for virtual-network clients. ✓

   Private connectivity requires appropriate name resolution. Virtual-network clients must resolve the app name to the private endpoint rather than to a public address.
2. Create a private endpoint for the App Service app in the virtual network. ✓

   VNet integration provides outbound access from the app; it does not provide private inbound access. A private endpoint addresses inbound private connectivity to the app.
3. Add another App Service VNet integration connection and use it for inbound client traffic.

   Additional VNet integration still provides outbound connectivity from the app; it does not create a private inbound path for clients.
4. Rely on the existing database private DNS configuration to make the App Service name resolve privately.

   DNS configuration for the database does not configure name resolution for the App Service private endpoint. The app's service name requires its own appropriate DNS configuration.
5. Create a second private endpoint for the database so clients can reach the App Service privately.

   A database private endpoint maps to the database resource. It does not provide inbound connectivity to the App Service app.

Choose two: create an App Service private endpoint and configure DNS for that endpoint. VNet integration handles outbound app connectivity, not private inbound access.

10. 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.

11. 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.

12. 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.

Other AZ-104 domains

• Manage Azure identities and governance — 213 questions →
• Deploy and manage Azure compute resources — 196 questions →
• Implement and manage storage — 164 questions →
• Monitor and maintain Azure resources — 112 questions →
• All 834 AZ-104 questions →
• AZ-104 certification: requirements, cost and exam format →