An Azure network diagram becomes useful when you can explain one request moving through it. Naming a virtual network, subnet and security group is only the start. Choose a source, destination and service, then identify the evidence needed at each step of the path.
This is a fictional paper exercise using two private virtual machines in one virtual network. It does not deploy resources, require a subscription or describe a customer environment. If you later build an authorised lab, check its costs and access rules first; the addresses and rules below are an example to reason about, not a production template.
Draw a small network with explicit assumptions
Use a virtual network with address space 10.20.0.0/16. Put a worker VM at 10.20.1.4 in subnet 10.20.1.0/24, and an application VM at 10.20.2.4 in subnet 10.20.2.0/24. The worker wants to connect to a service on TCP port 443 at the application VM.
For this exercise, assume no peering, gateway, network appliance, user-defined route or Virtual Network Manager admin rule. The destination subnet has the example NSG below, neither VM has a separate NIC-level NSG, and the source path has no custom rule that blocks this outbound request. Write these assumptions beside the drawing; do not infer them from a real diagram that omits details.
Worker: 10.20.1.4
subnet: 10.20.1.0/24
|
| TCP request to port 443
v
Application: 10.20.2.4
subnet: 10.20.2.0/24
Both inside VNet 10.20.0.0/16Describe the packet you are tracing
Record the protocol, source address and port, and destination address and port. For one illustrative connection, use TCP from 10.20.1.4:49152 to 10.20.2.4:443. The source port is an example client port, not a requirement for every connection.
Work with the private destination address for this first trace. A hostname introduces a separate DNS question: what address did the caller actually resolve? In a real investigation, preserve that answer instead of assuming that a familiar hostname points to the resource shown on the diagram.
Check the route before interpreting the security rule
Microsoft's Azure routing documentation explains the system routes and how route selection uses the destination address. For this example, the destination falls inside 10.20.0.0/16. With the stated assumptions, the virtual-network route is more specific than the default 0.0.0.0/0 route.
Write the selected prefix and next-hop type on your worksheet. In an actual authorised lab, inspect the effective routes associated with the source VM's network interface rather than relying only on a route-table resource name. A diagram may not show all the rules affecting the interface.
Now alter the paper example: imagine a more specific user-defined route for the destination subnet through a network appliance. That introduces another component to investigate. Do not continue describing the original direct path after changing the assumptions.
Evaluate the destination's inbound rule
An NSG filters traffic; it is not the route or the application itself. Microsoft's NSG overview explains that lower priority numbers are evaluated first and processing stops at the matching rule.
For the example destination-subnet NSG, use these two custom inbound rules. Source port is any in both; destination is 10.20.2.4. Existing default rules remain below them.
| Priority / action | Match fields |
|---|---|
| 200 / Allow | Source: 10.20.1.4 TCP, destination port 443 |
| 210 / Deny | Source: 10.20.1.0/24 Any protocol, any destination port |
The sample request matches priority 200, so this NSG allows it. A request from 10.20.1.5 to the same destination and port misses that allow and matches priority 210. A request from the original worker to port 80 also misses the allow and matches the deny. Check each field instead of deciding that the whole subnet is “open”.
If a real environment also has an NSG on the destination NIC, include it in the assessment. The exercise deliberately omits it; a subnet allow is not evidence that every other applicable control allows the connection.
Distinguish a policy result from a working service
Azure Network Watcher's IP flow verify evaluates a specified packet against applicable security and admin rules and identifies an allowing or denying rule. That is evidence about those controls, not proof that the application responded successfully.
Your worksheet should therefore separate three observations: the route selected, the security decision and the application result. Even when the first two support the intended path, the guest operating system's firewall, service listener or application configuration may still prevent the expected response.
A TCP connection to port 443 also does not establish that a certificate, hostname or application response is correct. Define what the application test must demonstrate. Avoid disabling controls broadly just to turn a failed test into a green result.
Include the response and record uncertainty
Draw the response arrow back to the worker. NSGs are stateful, so return traffic for an allowed established flow does not require a matching reverse NSG rule merely for that response. Still account for the actual routing and any other components on the return path.
If your lab behaves differently from the worksheet, record the exact time, addresses, ports, selected route and rule result. Mark missing evidence as unknown. A screenshot of a rule name without the tested packet details is difficult for another person to interpret.
Finish with a short troubleshooting handover
Submit the diagram, assumptions, packet description and three test cases. For each case, show your predicted rule match and the actual observation if you ran an authorised lab. Keep paper predictions clearly separate from executed tests.
End with the next unresolved question. For example: “The documented route and security test permit the connection; the service response has not yet been checked.” That statement is more useful than declaring the entire network healthy from one successful policy lookup.
Common questions
Does an allow rule guarantee the request succeeds?
No. It answers one filtering question. Routing, other applicable controls and the destination service still matter.
Should I add an internet route for this exercise?
No. The stated example uses two private addresses inside one virtual network. Internet connectivity is a separate design question.
Can I complete it without creating cloud resources?
Yes. Draw the path and predict the rule matches on paper. Label the result as an exercise, not a verified deployment.
Explore Microsoft Azure training and the Cloud Project Lab, or discuss your learning goal. Bring your diagram and ask how networking exercises are checked and explained.