Question 4 of 10Implement and Manage Virtual Networking
CramHQ runs incident-processing VMs in a spoke VNet. A peered ingestion tier and an on-premises SOC connected through ExpressRoute must reach the workers through one stable address, while no endpoint for the workers can be reachable from the internet. The workers expose TCP 443 and are in one region. Which load-balancing configuration should you recommend?
- AA. Deploy a Standard Azure Load Balancer with a private frontend IP in the ingestion VNet, add worker NICs to the backend pool, and use a TCP 443 rule with a health probe.
- BB. Deploy a Standard Azure Load Balancer with a public frontend IP, add worker NICs to the backend pool, and use network security group rules to allow only known source ranges.
- CC. Deploy a Standard Azure Load Balancer with a private frontend IP in the spoke VNet, add worker NICs to the backend pool, and use a TCP 443 rule with a health probe.
- DD. Deploy a Standard Azure Load Balancer with a private frontend IP in the spoke VNet, add worker NICs to the backend pool, and create inbound NAT rules for TCP 443.
Show answer and explanation
Answer: C
A private frontend IP is reachable from the virtual network, peered networks, and connected on-premises networks without creating an internet endpoint. The TCP rule and probe distribute only to healthy worker instances.
If you picked AWhy it is tempting: The frontend is private, and peered VNets can communicate privately, so the option looks aligned with the no-internet requirement.
Why it is wrong: Keep the load balancer frontend and the NIC-based backend pool members aligned within the VNet scope supported by the load-balancing rule.
If you picked BWhy it is tempting: NSG rules can limit who is allowed through, so the configuration can appear private from an access-control perspective.
Why it is wrong: A public frontend IP creates an internet-facing load balancer endpoint; use a private frontend IP when the endpoint must be reachable only through private networking.
If you picked DWhy it is tempting: The frontend is private and in the worker VNet, so the exposure and location cues look correct.
Why it is wrong: Use a load-balancing rule with a health probe when one listener must distribute traffic across backend instances.
Question 5 of 10Implement and Manage Virtual Networking
CramHQ publishes a case intake API from two Azure VMs in the same virtual network. During maintenance, either VM can be rebuilt without changing the client-facing endpoint, and firewall records must not identify individual VM addresses. Administrators also need inbound access controlled by existing network security rules on the workload subnets. Which recommendation best meets the requirement?
- AA. Create a Standard public IPv4 address, associate it with an Azure NAT Gateway on the subnet, and keep the VMs behind an internal load balancer.
- BB. Create a Standard public IPv4 address, associate it with an Azure Standard Load Balancer frontend, and place both VMs in the backend pool.
- CC. Create a Standard public IPv4 address on a network virtual appliance NIC, route Internet-bound subnet traffic to the appliance, and publish that address.
- DD. Create one Standard public IPv4 address for each VM network interface, publish both addresses in Azure DNS, and keep matching NSG rules.
Show answer and explanation
Answer: B
A Standard public IP address can be associated with a Standard Load Balancer frontend. Clients use one stable frontend while the VMs remain backend members, and subnet or NIC NSG rules control allowed inbound traffic.
If you picked AWhy it is tempting: NAT Gateway uses Standard public IP addresses, so it can look like a way to give a subnet a public endpoint.
Why it is wrong: Use NAT Gateway for outbound source translation from a subnet; use a public load balancer frontend when clients need to initiate inbound connections to backend VMs.
If you picked CWhy it is tempting: Network virtual appliances and route tables are often used to control traffic paths, so they can appear relevant when firewall or routing language is present.
Why it is wrong: A route table next hop should match the traffic path you need to control; it does not automatically turn an appliance NIC public IP into a shared load-balanced API endpoint.
If you picked DWhy it is tempting: Public IPs on VM NICs can support inbound access, and DNS can publish multiple records for a service name.
Why it is wrong: When the requirement forbids identifying individual VM addresses, put the public IP on a shared frontend rather than on each VM NIC.
Question 6 of 10Implement and Manage Virtual Networking
CramHQ deployed an alert relay VM in a spoke virtual network. After simultaneous route table and network security changes, outbound connections from the VM to an allied collector time out. The team must first determine whether the exact source, destination, protocol, and port would be blocked at the VM boundary before reviewing path selection or packet contents. Which recommendation is best?
- AA. Use Azure Network Watcher connection troubleshoot from the relay VM to the collector endpoint and port.
- BB. Use Azure Network Watcher IP flow verify on the VM NIC with the collector IP, protocol, direction, and port.
- CC. Use Azure Network Watcher next hop on the VM NIC with the collector IP as the destination.
- DD. Use Azure Network Watcher packet capture on the relay VM NIC with a filter for the collector endpoint and port.
Show answer and explanation
Answer: B
IP flow verify evaluates whether traffic with the specified details is allowed or denied for a VM network interface by applicable security rules, matching the team's first decision point.
If you picked AWhy it is tempting: Connection troubleshoot includes endpoint and port details, so it can look like the closest fit for a failed connection.
Why it is wrong: Use IP flow verify when the first question is whether a specified flow tuple is allowed or denied at a VM network interface.
If you picked CWhy it is tempting: Route table changes happened at the same time, so next hop looks relevant to the outage.
Why it is wrong: Use next hop when the diagnostic question is which route Azure selects toward a destination; use IP flow verify for a VM NIC allow-or-deny decision.
If you picked DWhy it is tempting: A packet capture filter can target the same endpoint and port, which makes it feel precise.
Why it is wrong: Use packet capture to collect traffic evidence; use IP flow verify to evaluate the configured allow-or-deny result for a VM NIC flow.
Question 7 of 10Implement and Manage Virtual Networking
CramHQ moved an analytics VM into a subnet that uses an Azure Firewall in a hub for outbound inspection. The VM can resolve names, but connections to an approved market-data API now time out. Its subnet NSG already has an allow rule for the API TCP port. You need to inspect the applied route entries on the VM network interface and confirm which route selects the next hop for the API prefix. What should you review?
- AA. Run IP flow verify in Network Watcher for the API address and port, and use the matching rule result as the next-hop validation.
- BB. Review Effective routes on the VM network interface in Network Watcher and verify the selected next hop for the API prefix.
- CC. Run Next hop in Network Watcher from the VM to the API address, and use it instead of reviewing the interface's applied route entries.
- DD. Review Effective security rules on the VM network interface in Network Watcher and verify that an outbound allow rule matches the API port.
Show answer and explanation
Answer: B
Effective routes shows the routes applied to a network interface, including system routes, user-defined routes, and propagated routes. It is the right view to confirm whether the destination prefix uses the intended next hop.
If you picked AWhy it is tempting: The API address and port are in the stem, so IP flow verify looks relevant to the timeout.
Why it is wrong: IP flow verify answers whether security rules allow or deny a flow; Effective routes answers which route entry and next hop apply to the destination prefix.
If you picked CWhy it is tempting: Next hop is a routing diagnostic and can report the next hop for the API address.
Why it is wrong: Use Next hop to test the next-hop result for a destination; use Effective routes when the requirement is to inspect the applied route entries that explain the selection.
If you picked DWhy it is tempting: The timeout and TCP port make an outbound security rule check feel relevant.
Why it is wrong: Effective security rules show the NSG rules applied to the NIC or subnet; they do not show which route or next hop traffic will use.
Question 8 of 10Implement and Manage Virtual Networking
CramHQ publishes HTTPS inference requests through an Azure Standard Load Balancer to a backend pool of gateway VMs. New client sessions must be spread only across healthy gateways. Operators also need break-glass SSH to a chosen gateway through the same public frontend IP by using predictable, unique external ports. A recent change made HTTPS reach a single VM instead of the healthy pool. Which recommendation best corrects the configuration?
- AA. Use an Azure Load Balancer load balancing rule for TCP 443 with a health probe, and use separate inbound NAT rules with unique frontend ports for SSH.
- BB. Use Azure Load Balancer inbound NAT rules for TCP 443 and SSH, assigning each gateway unique frontend ports and keeping the existing health probe.
- CC. Use an Azure Load Balancer inbound NAT rule for TCP 443 with the gateway backend pool, retain the health probe, and use inbound NAT rules for SSH.
- DD. Use an Azure Load Balancer load balancing rule for TCP 443, and use another load balancing rule for TCP 22 with session persistence set to Client IP.
Show answer and explanation
Answer: A
A load balancing rule uses the backend pool and probe state when selecting healthy gateways for new HTTPS flows. Inbound NAT rules provide deterministic per-gateway port forwarding for SSH without replacing the shared HTTPS path.
If you picked BWhy it is tempting: Unique frontend ports are correct for per-VM SSH, so applying that same pattern to TCP 443 can look consistent.
Why it is wrong: Inbound NAT rules forward to designated backend instances; a shared HTTPS service needs a load-balancing rule to distribute flows across healthy backends.
If you picked CWhy it is tempting: The option mentions the backend pool and health probe, which are real load balancer concepts tied to healthy service traffic.
Why it is wrong: The traffic construct matters first: use a load-balancing rule for pooled service distribution, and reserve inbound NAT rules for direct instance forwarding.
If you picked DWhy it is tempting: Using a load-balancing rule for TCP 443 is correct, and Client IP persistence sounds like a way to keep traffic tied to one backend.
Why it is wrong: Session persistence only influences repeated load-balanced flow selection; chosen per-VM SSH access through unique external ports requires inbound NAT rules.
Question 9 of 10Implement and Manage Virtual Networking
CramHQ has a shared-services virtual network and three workload virtual networks in different subscriptions, including one in another Azure region. The workload VMs have only private IP addresses. Admins must use browser-based RDP/SSH from Azure, and the team wants the fewest managed jump points. Which recommendation should you make?
- AA. Deploy Azure Bastion Basic in the shared-services virtual network and configure virtual network peering, including global peering where required, to each workload virtual network.
- BB. Deploy Azure Bastion Basic in the shared-services virtual network and rely on hub gateway transit to reach workload virtual networks without direct peering.
- CC. Deploy Azure Bastion Basic separately in each subscription and configure local virtual network peering only within that subscription.
- DD. Deploy Azure Bastion Standard in an Azure Virtual WAN hub and route traffic from the hub to each workload virtual network.
Show answer and explanation
Answer: A
This uses a supported dedicated deployment and extends reach through virtual network peering, including global peering. VMs in directly peered networks can be reached by private IP without VM public IPs.
If you picked BWhy it is tempting: Gateway transit sounds like it should extend hub connectivity to spoke networks without more peering work.
Why it is wrong: Gateway transit shares VPN or ExpressRoute gateway connectivity; it does not replace the direct peering boundary required for this centralized Bastion design.
If you picked CWhy it is tempting: Different subscriptions often imply separate ownership and can make separate management resources seem required.
Why it is wrong: Azure Bastion placement is based on supported VNet reachability, not on needing one deployment per subscription when cross-subscription peering can be used.
If you picked DWhy it is tempting: A Virtual WAN hub is designed for centralized connectivity, so it can appear to be the best place for a shared jump point.
Why it is wrong: Azure Bastion must be deployed in a supported virtual network placement; deploying it in an Azure Virtual WAN hub is not supported.
Question 10 of 10Implement and Manage Virtual Networking
CramHQ's grid analytics subnet hosts collectors and shared operations tools. A new telemetry storage account must be reachable from collectors, and auditors require an approval record on that account for this connection rather than accepting membership in the collectors' network segment as the control. The operations tools still need normal Azure access paths. Which recommendation best meets the requirement?
- AA. Create an Azure Private Endpoint for the storage account blob subresource and configure the privatelink.blob.core.windows.net private DNS zone for the collectors.
- BB. Enable a Microsoft.Storage virtual network service endpoint on the collectors subnet and add a storage account virtual network rule for that subnet.
- CC. Assign Azure NAT Gateway to the collectors subnet and add the gateway public IP address as a storage account IP network rule.
- DD. Enable a Microsoft.Storage virtual network service endpoint on the collectors subnet and attach a service endpoint policy allowing only the telemetry storage account.
Show answer and explanation
Answer: A
Azure Private Endpoint creates a private endpoint connection on the storage account subresource. Private DNS lets collectors resolve the account to that connection, giving the storage owner a resource-level approval boundary.
If you picked BWhy it is tempting: A storage service endpoint plus a storage account virtual network rule is a valid way to allow traffic from a subnet to Storage.
Why it is wrong: Service endpoint access is anchored to the subnet and storage firewall rule; it does not create a private endpoint connection approval on the storage account.
If you picked CWhy it is tempting: A NAT Gateway public IP can make outbound access easier to recognize and allow in firewall rules.
Why it is wrong: A shared public egress IP rule is not a private endpoint and does not provide a storage-account-owned approval record for a specific private connection.
If you picked DWhy it is tempting: A service endpoint policy can allow only selected storage accounts, so it sounds resource-specific.
Why it is wrong: Service endpoint policies restrict which storage resources a subnet can reach over service endpoints, but the enforcement remains subnet-scoped.
