10.3 Networking, Monitoring, and Security Integrated Cases
Key Takeaways
- Networking case questions require checking effective routes, effective security rules, DNS, health probes, and endpoint configuration in order.
- Monitoring evidence should guide remediation instead of being treated as a separate exam domain.
- NSGs, ASGs, UDRs, peering, private endpoints, and load balancers can all affect the same user-visible outage.
- Azure Bastion and private access patterns reduce exposure but require correct subnet, DNS, and route design.
- Alert rules and action groups should target actionable signals, not every noisy metric.
Case 1: Web tier cannot reach database tier
A web VM subnet and database VM subnet are in the same VNet. The web tier cannot connect to TCP 1433 on the database tier. The database VM is running, and the application worked last week. A new NSG rule and a route table were added during a security review.
Start with the packet path. Source is the web VM NIC or subnet. Destination is the database VM private IP and port. Use Network Watcher connection troubleshooting, IP flow verify, effective security rules, and effective routes. Then inspect guest OS firewall and application listener. Do not remove all NSGs or make both VMs public.
Useful checks:
az network watcher test-ip-flow \
--resource-group rg-net \
--vm web-vm-01 \
--direction Outbound \
--protocol TCP \
--local 10.10.1.4:* \
--remote 10.10.2.5:1433
az network nic show-effective-route-table -g rg-net -n web-vm-01-nic -o table
az network nic list-effective-nsg -g rg-net -n web-vm-01-nic -o table
If IP flow verify says denied outbound, inspect the web subnet or NIC NSG. If denied inbound, inspect the database subnet or NIC NSG. If effective routes send traffic to a virtual appliance, validate appliance rules and return path. If Azure says the flow is allowed but the connection still fails, inspect the OS firewall, service binding, and database configuration.
Case 2: Private endpoint resolves publicly
A storage account has public network access disabled and a private endpoint in vnet-prod. A VM in vnet-prod still resolves the storage account name to a public IP. Connection fails. The private endpoint shows approved.
The private endpoint object is only part of the solution. DNS must resolve the public service name to the private endpoint address from the client network. For storage, that usually means the correct private DNS zone is linked to the VNet, with the expected record. If custom DNS servers are used, they must forward or resolve Azure private DNS names correctly.
The remediation is not to enable public access unless the requirement changed. Fix the private DNS zone link, DNS forwarding, or records. The packet path can be perfect and the endpoint can be approved, but wrong name resolution sends the client toward a blocked public endpoint.
Scenario tree:
- Confirm private endpoint connection state is approved.
- Confirm the private DNS zone exists for the service subresource.
- Confirm the zone is linked to the VNet where the client lives.
- Confirm the name resolves to a private IP from the client.
- Confirm NSGs and UDRs allow the path to the private endpoint IP.
- Confirm the service firewall is consistent with the private access model.
Case 3: Load balancer sends no traffic
An internal load balancer fronts two VMs. Clients can reach the frontend IP, but connections fail. Metrics show no healthy backend instances. The VMs respond locally on port 8080, but the health probe is configured for port 80.
Load balancers depend on backend pool membership, probe health, load-balancing rules, NSGs, and the service listener. If the probe is unhealthy, the load balancer will not send traffic to that backend. Fix the probe port or path to match the application health endpoint, then confirm NSGs allow probe and client traffic.
Portal path: Load balancer > Backend pools, Health probes, Load balancing rules, and Metrics. For VM membership, check NIC backend pool associations. For NSG, check effective rules on the NIC.
Do not confuse public and internal load balancers. If the requirement says private access inside a VNet, an internal load balancer is appropriate. If internet users must reach the app, a public frontend or another public entry service is required. If HTTP layer routing is required, Azure Application Gateway may appear in broader Azure design, but AZ-104 load balancer questions usually focus on transport rules and probe health.
Case 4: Bastion hardening blocks administrators
A security team removes public IP addresses from VMs and deploys Azure Bastion. Administrators still cannot connect. The VNet does not contain a subnet named AzureBastionSubnet, and NSGs were copied from an application subnet.
Bastion has specific deployment requirements. It uses a dedicated subnet with the required name and sizing requirements. It also needs allowed management and session traffic. The remediation is to deploy Bastion correctly, not to reattach public IP addresses to every VM. If an NSG is associated with the Bastion subnet, it must allow required Bastion traffic.
This is a classic security integration question. The business requirement is no public VM exposure. The technical fix is correct Bastion architecture. The wrong answer weakens security to restore access quickly.
Monitoring and alert design
Monitoring should prove the failure and prevent recurrence. For network cases, use Network Watcher tools, VM connection metrics, NSG flow logs where applicable, load balancer metrics, and resource health. For application symptoms, use logs and metrics from App Service, VMs, storage, and containers.
A good alert is actionable. Alert on load balancer backend health dropping below expected count, VM CPU saturation with sustained duration, storage availability or latency, backup job failures, or failed deployment operations when your team owns remediation. Pair alert rules with action groups and alert processing rules for maintenance windows. Do not create a broad alert for every transient metric spike unless the operations team can respond meaningfully.
Exam traps
Do not assume NSG rules are the only network control. UDRs, peering settings, DNS, private endpoint approval, service firewalls, load balancer probes, and guest firewalls all matter. Do not assume a successful ping proves an application port works. ICMP behavior is not enough evidence for TCP service readiness.
Do not solve private endpoint failures by opening public access unless the requirement permits it. Do not solve Bastion problems by restoring public IP addresses when the stated goal is to remove them. Do not solve load balancer health by adding more VMs before fixing an incorrect probe.
A private endpoint is approved, but a VM resolves the storage account name to a public IP and cannot connect because public access is disabled. What should be fixed?
An Azure Load Balancer shows no healthy backend instances. The app listens on 8080, but the probe uses port 80. What is the best remediation?
Which tool is most directly useful to determine whether an NSG permits a specific VM flow?