LEARN. PRACTICE. GROW.Describe the flow before changing rules
During an incident, “the network fails” is not a testable hypothesis. Record the client VM, source and destination, ports, protocol, direction, and time. In the example, 10.20.1.7:51024 initiates TCP to 10.30.2.9:443. The reply reverses those pairs; it is not a new attempt equivalent to the original. Preserve the DNS answer actually used and distinguish existing from new connections. A configuration change, a tool result, and an application transaction are different evidence. The objective is to explain which layer is confirmed and which remains to be observed, preserving enough context to repeat the test.
Compare rules within the correct scope
Priority orders rules within one NSG. It does not combine NIC and subnet rules into a single list. For an outbound connection the NIC is evaluated before the subnet when both have NSGs; inbound order is reversed. In the fixture, NIC Allow 200 and subnet Deny 300 leave the flow blocked at the subnet. The NIC’s lower number does not override that second control. Before adding rules, identify the first match in each scope and verify the tuple used. Limit the adjustment to the approved source, destination, and service. A broader rule can hide the cause and alter flows outside the incident.
Existing sessions and admin policies
Removing NSG permission for new connections may leave an established session functional. An access-withdrawal request should distinguish preventing new sessions from ending existing ones. Record evidence, perform targeted termination through the approved procedure, and verify both outcomes. If security admin rules exist, identify the exact action: Allow continues to NSGs; Always allow bypasses that evaluation for the matching flow; Deny ends it with a block. None establishes the listener, TLS, or application. This lesson’s models represent these differences in explicit fixtures; they implement neither Azure’s authorization engine nor real session expiry.
Prefix before origin, with explicit exceptions
In the ordinary-route example, 10.40.8.19 belongs to both 10.40.0.0/16 and 10.40.8.0/24. The /24 is more specific and wins even when learned through BGP alongside a /16 UDR. For equal prefixes, normal precedence is UDR, BGP, then system. Do not blindly apply this teaching rule to documented exceptions: preferred network/peering routes and service endpoint routes need separate treatment. Service endpoint routes are not overridden by a default route to an NVA. Always compare the specific destination’s effective route with change intent instead of using UDR presence as proof of inspection.
A route to the NVA does not prove transit
A route may deliver traffic to an appliance unprepared to forward it. Confirm NIC requirements, NVA operating-system or product requirements, policies, and the return path. In the fictional case, SYN traverses NVA-A while SYN-ACK returns through NVA-B and is dropped because session state is absent there. Resolution depends on a return and availability design compatible with the product. A longer timeout does not repair the demonstrated drop. Assume neither state sharing nor universal safety of route changes: check support, capacity, dependencies, and rollback options before execution.
Choose the next observation
IP flow verify helps assess security and admin rules for a described packet. Allow narrows a filtering hypothesis but does not establish a transaction. Connection troubleshoot adds connectivity, port, and path evidence according to the test. If a port does not accept connections, compare the actual listener, bind address, guest firewall, and startup logs. If TCP is reachable but TLS fails, address the hostname and certificate contract. Current documentation presents an agentless experience in preview; do not assume it is mandatory or generally available in every context. Choose the environment’s supported mode and record result scope.
Change exercise with an inspection requirement
A batch must traverse NVA-A, but the observed /24 route points to gateway-B. Produce a record containing the destination, matching prefixes, selected route, and unmet requirement. Propose a scoped correction or deferral, identify the approver, and define rollback criteria. Subsequent testing should confirm forward and return paths, appliance observations, and the batch outcome without duplicates. The task does not require executing Azure: it requires a technically justified decision and a validation sequence RUN can repeat in an authorized lab before production.
Summary: prove the path and the outcome
A complete analysis keeps tuple, rules, session state, route, forwarding, and application separate. Attach an observation and its limit to each conclusion. An old session does not test new rules; a UDR does not prove the effective next hop; Allow does not prove a listener; TCP does not prove TLS or business success. Handover should include rejected hypotheses, approved changes, recovery criteria, and regression signals. Local models only check these explicit rules and IPv4 arithmetic. They send no traffic and do not fully simulate Azure, BGP, appliances, policies, or convergence.
CLIENT 10.20.1.7:51024 -> SERVER 10.30.2.9:443 TCP
NIC NSG: priority=200 action=Allow matches=true
SUBNET NSG: priority=300 action=Deny matches=true
DESTINATION 10.40.8.19
UDR 10.40.0.0/16 -> NVA-A
BGP 10.40.8.0/24 -> gateway-B
SCOPE ordinary routes only; preferred-route exceptions excludedFixture: destination 10.40.8.19; UDR 10.40.0.0/16 → NVA-A; BGP 10.40.8.0/24 → gateway-B. Without exceptions, /24 is selected. Required inspection remains unproven.
Common pitfalls
Comparing priorities across NSGs as one list; testing only old sessions; applying longest-prefix rules to exceptions; confusing Allow with availability.
Related topics: Production diagnosis · Changes and recovery · Operational evidence
Explain the outcome using the specific flow and establish recovery through the affected operation.
Reference: Azure routing and UDRs · AZ-104; skills measured 2026-04-17