NSG practice questions

Connection troubleshoot

Why wrong: Connection troubleshoot is wrong for this scenario because it performs an end-to-end connectivity test between a source VM and a target destination over a given protocol and port, reporting latency, path hops, and any failures. However, a failed connection can result from multiple causes—such as routing issues, DNS resolution, network virtual appliances, or workload misconfigurations—and the output does not specifically identify which NSG rule allowed or denied the traffic. It is useful for general connectivity problems, but it lacks the rule-level precision needed to determine whether an NSG permits a specific TCP flow.

Packet capture

Why wrong: Packet capture is incorrect here because it records raw network traffic at the virtual machine's network interface, capturing the actual packets that traverse the NIC for later analysis with packet inspection tools. While this can reveal whether packets were sent or received, it does not directly report which NSG rule matched or whether traffic was blocked before reaching the OS—because packets dropped by an NSG never appear in the capture. It requires extensive manual analysis and cannot provide the definitive 'allowed/denied' answer with the governing rule that IP flow verify delivers.

Next hop

Why wrong: Next hop is not the correct tool because it focuses exclusively on layer-3 routing: given a source VM and a destination IP, it returns the next hop type (e.g., internet, virtual network, virtual appliance, VPN gateway) and the next hop IP address. This indicates which route is used to forward traffic, but it completely ignores layer-4 protocol and port information and never evaluates NSG security rules. Therefore, it cannot determine whether an NSG would allow or deny a TCP flow—it only tells you the route the packet would take if it were allowed.

Step 1: Create the virtual network with address space. Step 2: Deploy the virtual machine. Step 3: Add a subnet. Step 4: Associate an NSG to the subnet. Step 5: Verify network connectivity.

Why wrong: This order is invalid because a virtual machine cannot be deployed without a subnet existing. During VM creation (portal, CLI, or template), you must specify an existing virtual network and subnet for the NIC; the subnet is a mandatory parameter and cannot be created after the VM. Skipping or reordering the subnet creation causes the deployment to fail with a resource-not-found error.

Step 1: Create the virtual network with address space. Step 2: Add a subnet. Step 3: Deploy the virtual machine. Step 4: Associate an NSG to the subnet. Step 5: Verify network connectivity.

Why wrong: This order incorrectly prioritizes VM deployment over NSG association. While a VM can technically be deployed without an NSG, best practice is to associate the NSG to the subnet first so that the planned inbound and outbound rules are evaluated as soon as the VM's NIC comes online. Deploying the VM first leaves a time window during which traffic is governed only by Azure's default rules, potentially allowing unintended access to the instance.

Step 1: Deploy the virtual machine. Step 2: Create the virtual network with address space. Step 3: Add a subnet. Step 4: Associate an NSG to the subnet. Step 5: Verify network connectivity.

Why wrong: This sequence cannot work because a VM is a resource that depends on foundational network infrastructure: it requires a virtual network and a subnet before its NIC can be attached. Azure does not support dynamically creating a VNet or subnet at the moment of VM deployment; both must be pre-existing resources. Consequently, starting the process with a VM deployment is fundamentally invalid and the request will be rejected.

Default inbound rule: Allows all inbound traffic by default.

Why wrong: Default inbound rules in an NSG actually deny all inbound traffic by default, not allow it. The built-in 'DenyAllInBound' rule with the lowest priority ensures that any inbound traffic not matched by a higher-priority allow rule is blocked. There are also default allow rules for virtual network traffic and Azure Load Balancer health probes, but these are exceptions to the default deny posture. You must explicitly create an allow rule with a priority number lower than the deny rule (i.e., a higher priority) to let traffic reach the VM.

Service tags: Override default system routes.

Why wrong: Service tags are groups of Azure service IP prefixes, such as 'Storage' or 'AzureLoadBalancer', that you can use as source or destination in NSG rules to allow or deny traffic for an Azure service without hard-coding IP addresses. They represent a collection of IP ranges, not a routing capability; they do not override default system routes. Route overriding is performed exclusively by User Defined Routes (UDRs) in route tables, not by service tags. Thus, using a service tag in an NSG might filter traffic, but it will never change the next hop or the path traffic takes.

Configure a virtual network peering to connect the frontend and database subnets.

Why wrong: Virtual network peering is the wrong tool here because peering connects two separate virtual networks, not subnets within the same VNet. Subnets in a single VNet already have implicit connectivity and do not require any peering relationship; attempting to peer subnets is conceptually invalid and not supported in Azure. If the goal were to connect separate VNets, peering would be relevant, but for tier separation within one VNet it is unnecessary and misleading.

Use Azure Firewall to inspect traffic between the frontend and application tiers.

Why wrong: Using Azure Firewall to inspect traffic between the frontend and application tiers is not the correct answer for this design because Azure Firewall is a managed, layer-3/7 service intended for centralized inspection across VNets or at the perimeter, not for simple intra-VNet subnet-to-subnet filtering. For east-west traffic between subnets inside the same VNet, network security groups are typically sufficient and more cost-effective. Deploying a firewall here would add complexity and require user-defined routes to force traffic, which is unnecessary for a three-tier application.

Route traffic from the application tier to the database tier using a user-defined route (UDR) pointing to the Azure Firewall.

Why wrong: Routing application-to-database traffic through a UDR that points to Azure Firewall is wrong in this scenario because it introduces unnecessary chaining and cost; the database subnet should be protected by NSGs that only permit the application tier, not by forcing all traffic through a stateful firewall. A UDR is useful for forced tunneling or when you need an NVA/appliance, but Azure's default system routes already provide connectivity between subnets within the VNet. Also, if the UDR's next hop is a firewall, the firewall must have SNAT and high availability considerations, complicating a simple architecture.

An inbound rule that uses the current web VM's private IP as the source and the current app VM's private IP as the destination.

Why wrong: Hard-coding the current web VM's private IP as the source and the app VM's private IP as the destination creates a brittle rule that breaks the moment either VM is recreated, scale-set scaled out, or a new tier member is added; the rule must be manually updated for every IP change or new instance. Application security groups (ASGs) solve this by letting the rule reference role-based groups, so new members are automatically included without rewriting the NSG rule.

A route table that sends TCP 8443 traffic from the web subnet to the app subnet.

Why wrong: A route table (UDR) controls the next hop for traffic based on destination IP prefixes, not the TCP destination port, so it cannot permit or deny TCP 8443 between the web and app subnets. Even if a UDR directed 8443 traffic toward the app subnet, it would only change the path; it has no filtering capability. Access control for specific ports must be enforced by an NSG or a firewall, not by routing logic.

An Azure Firewall application rule collection that permits all traffic between the two subnets.

Why wrong: An Azure Firewall application rule collection is designed to allow outbound access based on FQDN/URLs (e.g., HTTP/S), not to filter east-west TCP port 8443 traffic between subnets by IP; network rules would be needed for that, and opening all traffic between the subnets violates least privilege. This approach is also far heavier than an NSG for simple tier-to-tier filtering, because Azure Firewall is a fully managed central service rather than a lightweight, subnet- or ASG-scoped rule.

Allow TCP 8443 from the entire virtual network to the app subnet with a lower priority than the deny rule.

Why wrong: Using the entire virtual network as the source allows every subnet, including management or other workloads, to reach the app tier on TCP 8443, which violates least-privilege access. The correct rule should scope the source to the web tier's application security group and the destination to the app tier's ASG, not broad IP/subnet ranges. This over-permissive rule unnecessarily expands the attack surface and could be blocked by security policy.

Allow UDP 8443 from WebASG to AppASG with any priority below 65000.

Why wrong: UDP is the wrong transport protocol because the application listens on TCP 8443, and an NSG rule for UDP never matches TCP segments, so the traffic would still be blocked. Additionally, the phrase "any priority below 65000" is not guaranteed to outrank the existing deny-all rule; the numeric value must be lower than that specific deny rule's priority. The protocol mismatch alone makes this option invalid.

Allow TCP 8443 from WebASG to AppASG with a priority higher number than the deny rule.

Why wrong: An NSG rule with a higher numeric priority is evaluated later than the deny-all rule, so the deny rule matches first and drops the TCP 8443 traffic before the allow rule can be considered. In Azure, lower numbers win, so to override a deny rule the allow must have a smaller priority value. Thus even though the source and destination ASGs are correctly identified, the ordering defeats the rule.

Increase the deny rule priority number from 200 to 300.

Why wrong: Increasing the deny rule's priority number from 200 to 300 lowers its precedence, meaning it will be evaluated later in the rule sequence. However, the admin allow rule still has a higher numeric priority (e.g., 400), so it is evaluated after the deny rule and will never be matched. The correct fix is to make the allow rule's numeric priority lower than 200 so that it is evaluated before the deny rule; simply renumbering the deny rule does not guarantee the allow rule is reached.

Change Allow-HTTPS-Admin to use protocol Any.

Why wrong: Changing the protocol to Any would only broaden the rule's matching criteria; it does not change the order in which NSG rules are evaluated. Because the deny rule at priority 200 is processed first, any subsequent allow rule, regardless of protocol, will never be reached. It also weakens security by permitting all protocols for that rule while leaving the precedence issue unresolved.

Assign a public IP address to the VM.

Why wrong: Assigning a public IP address to the VM only provides a routable inbound endpoint; it has no effect on NSG rule evaluation. NSG filters are applied at the subnet or network interface level before traffic reaches the guest OS, so the deny rule still applies exactly the same. The VM's own public IP does not change the source IP of the request, nor does it cause the NSG to skip the deny rule.

Packet capture

Why wrong: Packet capture records actual network packets at a VM's network interface, capturing headers and payload for deep protocol analysis. While it can reveal whether TCP SYN packets leave the source or arrive at the destination, it does not directly map captured frames to NSG rule evaluations, and if an NSG drops the traffic before it reaches the target NIC, the packets may be entirely absent from the capture. Analyzing the capture and correlating it with NSG configuration takes significantly more time and effort than IP flow verify, which actively tests the rule engine for the exact flow.

Connection troubleshoot

Why wrong: Connection troubleshoot is a Network Watcher feature that performs an end-to-end connectivity test between two VMs, checking multiple components such as DNS resolution, routing, and NSG permissions. It returns a readable 'reachable' or 'unreachable' result and may list potential causes, but it runs a broader set of checks and is slower to produce a precise answer. IP flow verify is the more targeted tool when the specific question is whether an NSG rule allows or denies TCP 1433, because it isolates the NSG rule evaluation rather than testing the entire network path.

Effective routes

Why wrong: Effective routes shows the routing table in effect for a VM's NIC, including system routes, user-defined routes, and BGP-learned routes, and it determines the next hop for a given destination IP prefix. It addresses layer-3 routing decisions, not layer-4 filtering, so it cannot indicate whether an NSG permits or denies TCP port 1433. Even if the effective routes correctly deliver the packet to the destination VM, a network security group might still be blocking the session, making this tool useless for diagnosing a port-specific failure.

Service tag

Why wrong: A service tag is a predefined, Microsoft-managed label representing a set of Azure service IP prefixes (e.g., AzureLoadBalancer, Storage, Sql) that updates automatically as ranges change. It cannot represent your own backend VMs because those are customer-managed resources with arbitrary private IPs, and service tags are not user-definable or assignable to a specific application tier. Using a service tag in an NSG rule would match Microsoft service traffic, not the traffic among your three backend application servers, so it fails to address the direct rule-targeting need.

Route table

Why wrong: A route table (user-defined route) overrides Azure's default system routes by specifying next-hop behavior for traffic leaving a subnet or NIC, such as forcing traffic through a firewall or virtual appliance. It influences the path packets take, not whether they are permitted; NSG rules still need explicit source/destination constructs like IP ranges, service tags, or application security groups. A route table cannot be referenced in an NSG rule, so it is incapable of grouping the three backend servers into a reusable security rule target.

Private endpoint

Why wrong: A private endpoint creates a network interface with a private IP for a specific Azure PaaS resource (e.g., SQL Database, Storage) to bring that service into your virtual network. It does not act as a security grouping construct: NSG rules cannot reference a private endpoint as a source or destination for traffic between your own backend servers. Selecting it would attempt to solve a VNet-internal NSG rule target problem with a feature designed for private connectivity to managed services, leaving the requirement unsatisfied.

A static private IP address for each backend VM.

Why wrong: Static private IP addresses ensure the backend VMs keep stable addresses, but an NSG rule that references individual IPs still requires one rule per VM, or a range that may be brittle as the tier grows or shrinks. When backend VMs are rebuilt frequently, their NICs might be recreated, and even with static IPs you must track and manage address assignments manually. Static IPs do not group VMs logically or reduce rule maintenance; they only avoid DHCP changes, while an ASG provides a role-based target that stays constant regardless of IP changes.

A user-defined route pointing frontend traffic to the backend subnet.

Why wrong: A user-defined route (UDR) controls the next hop for packets, not which traffic is permitted or denied. Pointing frontend traffic to the backend subnet would simply change the forwarding path and could even break asymmetric routing, but it does not create an authorization boundary. NSG rules require a source, destination, and port scope; a UDR cannot reference a logical group of backend VMs, so it is fundamentally the wrong mechanism for replacing ASG-based targeting.

A private endpoint for the backend tier.

Why wrong: A private endpoint is a PaaS construct that exposes an Azure service (such as Storage or SQL Database) over a private IP address inside a virtual network; it is not a grouping mechanism for IaaS VMs. You cannot attach a private endpoint to a subnet as a source or destination in an NSG rule to represent a workload tier. Concepts like private endpoints are relevant for network-level isolation of Azure services, not for authorizing traffic to a set of backend VMs, so using one here is a category error.

Destination 10.1.4.4/32 with next hop type Internet.

Why wrong: A host route to 10.1.4.4/32 is too specific and only applies to traffic destined to the appliance itself, not to general outbound internet traffic. The next hop type Internet is also incorrect because it would send traffic using Azure's default internet path, not to the NVA's private IP as a next hop. This option fails to override the system default route for 0.0.0.0/0, leaving internet-bound traffic to bypass the security appliance entirely.

Destination 0.0.0.0/0 with next hop type Virtual network gateway.

Why wrong: A Virtual network gateway next hop designates traffic for an IPsec VPN tunnel or ExpressRoute circuit, not for a network virtual appliance (NVA) residing inside the same virtual network. Even if the destination is 0.0.0.0/0, the gateway would attempt to send outbound internet traffic to your on-premises network, not to the appliance at 10.1.4.4. This option is incorrect because the next hop type must be Virtual appliance to forward traffic to the NVA's private IP address, not a VPN/ExpressRoute gateway.

Destination 10.1.4.0/24 with next hop type None.

Why wrong: This route has the wrong destination prefix: 10.1.4.0/24 only covers the subnet containing the NVA, so internet-bound traffic to other destinations would still match the default system route and bypass the appliance. Moreover, the next hop type None creates a blackhole, causing any traffic that does match this route to be silently dropped instead of being forwarded. To force all outbound internet traffic through the NVA, the route must use 0.0.0.0/0 with the Virtual appliance next hop type and the appliance's IP address.

Remove the inbound allow rule from DbSubnet so the default rules can take over.

Why wrong: Removing the inbound allow rule on DbSubnet does not influence the outbound filtering performed on AppSubnet. Even though the default AllowVNetInBound rule would broadly permit traffic from the virtual network, that default rule is evaluated only on the destination side, after the packet has already been blocked at the source. You would lose the explicit TCP 1433 authorization and undermine the least-privilege model without resolving the actual failure point—the outbound deny at priority 200.

Move the inbound allow rule on DbSubnet to priority 100 so it is evaluated sooner.

Why wrong: Lowering the priority number of the DbSubnet inbound rule from 200 to 100 increases precedence only within the destination NSG's inbound rule list. The TCP packet still must first traverse the AppSubnet's outbound NSG, where the deny rule at priority 200 wins over any lower-priority allows; as a result, the packet never reaches the DbSubnet. Priority adjustments are only meaningful within the same NSG and direction, so changing the destination rule cannot override a block on the source side.

Assign the database VM NIC to ASG-App so the destination rule matches a broader group.

Why wrong: Assigning the database VM NIC to ASG-App would place it in the same logical source group as the app VMs, but that does not affect the outbound path from AppSubnet. The connection is dropped by the outbound deny rule on the AppSubnet NSG before the DbSubnet NSG inbound rule can match the now-broader ASG membership. Altering ASG assignments also muddles the design intent and can make the database VM match its own inbound rule as both source and destination, but it still cannot circumvent the source-side deny.

Add a subnet-to-subnet peering connection between the web and app subnets.

Why wrong: Subnet-to-subnet peering is not a valid construct: VNet peering connects entire virtual networks, whereas subnets inside the same VNet already have built-in routing to one another. This option only establishes or relies on connectivity; it does not restrict which sources can reach the app tier on TCP 8080. Without NSG rules (or a network virtual appliance) that evaluate source and destination identities, traffic between the web and app subnets remains open to other workloads and a malicious VM. Thus it does not meet the security requirement.

Create a load balancer backend pool rule for TCP 8080.

Why wrong: A load balancer backend pool rule defines how traffic arriving at a frontend IP and port is distributed to backend VM instances, typically for inbound client traffic. It does not inspect whether the source of an east-west request from the web tier is authorized to call the app tier on TCP 8080; it simply forwards or load-balances based on the destination mapping. Backend pool membership controls which endpoints receive that traffic, not which source roles may communicate, so anyone who can reach the load balancer frontend could still access the app service. Therefore, this is a traffic distribution mechanism, not a security control for inter-tier access.

Use a user-defined route that sends TCP 8080 traffic to the app tier.

Why wrong: A user-defined route overrides Azure's default routing by specifying a next hop for traffic destined to a particular IP address prefix, and it cannot match on TCP port 8080 because route tables only contain address prefixes and next-hop types. Even if the web tier's traffic were forced toward the app subnet or an appliance, the route would affect forwarding for all traffic with that destination prefix, not selectively permit the app's port. UDRs are a routing mechanism, not an access-control list, and they provide no source-based authorization to block or allow web-to-app communication. This approach neither filters by port nor enforces the required allow-list.

Azure Backup vault names

Why wrong: A Recovery Services vault name is merely an Azure Resource Manager identifier assigned to a backup vault's configuration. It is not a log stream, metric, or queryable audit artifact, so it cannot reveal historical operations or roles that performed changes. Backup jobs themselves are recorded in the Activity log, but the vault name alone contains no telemetry about who changed any resource.

Virtual network address spaces

Why wrong: Virtual network address spaces define the IP CIDR ranges assigned to a vNet and are stored as a property of the network resource. These values are configuration data, not event records, and querying them returns only the current address plan, never the identity of the person who modified it. Any change to an address space is captured by the Activity log as a separate write event, but the address space setting itself cannot be used for forensic analysis.

Managed disk size settings

Why wrong: Managed disk size settings describe the current allocated capacity of a disk, such as 128 GiB, and are part of the resource's configuration state. Although resizing a disk generates an Activity log entry, the size value itself is a property, not a log record, and cannot be queried to show who performed the operation. Therefore, examining disk size in Log Analytics would provide only current configuration, not a change history or caller identity.

Change the deny rule source from VirtualNetwork to Internet.

Why wrong: Modifying the deny rule's source from VirtualNetwork to Internet would cause it to ignore all internal traffic, including the web tier's traffic, making the allow rule unnecessary for that path. However, this would eliminate the intended restriction on internal sources, allowing any virtual network resource (e.g., other subnets or compromised VMs) to reach AppTier-ASG on TCP 8443. It also leaves the underlying precedence problem unsolved, as the deny rule would no longer block the web tier but would create a broader, less secure rule.

Associate the NSG with the virtual machine NIC instead of the subnet.

Why wrong: Changing the NSG association from the subnet to the VM NIC alters the scope of enforcement—NIC-level NSGs apply only to that VM, while subnet-level NSGs apply to all resources in the subnet—but it does nothing to change rule precedence. The identical NSG rules are evaluated in the same order whether attached to a subnet or a NIC, so the deny rule at priority 100 would still be processed before the allow rule for WebTier-ASG. This action is therefore ineffective for resolving the traffic block.

Replace the ASG destination with the subnet address range.

Why wrong: Replacing the ASG destination with the subnet address range changes the rule's matching logic from a logical group to a CIDR range, which would apply the same priority order but potentially match traffic to any VM in that subnet, not just the application tier. The core issue remains: the deny rule at priority 100 is evaluated before any allow rule with a higher priority number, so the allow rule for WebTier-ASG would still be bypassed. This approach degrades rule precision and fails to address the precedence conflict.

It guarantees that attacks cannot succeed.

Why wrong: Centralized logging cannot guarantee that attacks will never succeed because it is passive—it only captures events that have already occurred. Even with real-time alerting, an intrusion can partially or fully execute before a security team or automated system can intervene; prevention requires active controls like endpoint detection and response, firewalls, and intrusion prevention systems. Logging supports post-incident analysis and helps improve defenses, but it is not a barrier to attack execution.

It replaces access control mechanisms.

Why wrong: Centralized logging is inherently a detective control—it records user and system activity after the fact, but it cannot enforce security policies, verify identities, or authorize resource access. Access control depends on mechanisms such as role-based access control, attribute-based policies, and multi-factor authentication, which operate at the authentication and authorization layer. Logging provides evidence of who accessed what, but it in no way substitutes for these preventive security controls.

It forces all systems to use one VLAN.

Why wrong: Centralized logging is a logical data-collection architecture, not a physical or logical network configuration; it determines where log records are sent from, not how segments are structured. VLANs are Layer 2 segmentation mechanisms designed to isolate broadcast traffic and enforce network boundaries, which are orthogonal to log shipping. In fact, forcing all systems onto one VLAN would eliminate segmented security zones and increase lateral movement risk, making it a counterproductive and unrelated idea.

Static private IP addresses for each virtual machine.

Why wrong: Assigning static private IP addresses would let you predefine NSG rules with exact IPs that survive a VM rebuild, but it forces your team to manually track and allocate each IP and to reconfigure rules whenever a VM is added, removed, or changed. It also creates a single point of human error when NICs are replaced, and it fails to group multiple VMs with the same function into a manageable policy object. Unlike ASGs, static IPs offer no abstraction layer for expressing tier-level connectivity.

A user-defined route between the app and backend subnets.

Why wrong: A user-defined route (UDR) is a routing-table entry that controls the next hop for traffic leaving a subnet, such as forcing it through a firewall or VPN gateway; it never evaluates or filters which application tier may talk to which other tier. Adding a UDR between app and backend subnets would only alter the network path taken by packets, not authorize or deny the communication, and it does not respond to VM IP changes. Effective tier-to-tier access control still requires NSG rules, ideally with ASGs as the source/destination.

An availability set for each tier.

Why wrong: An availability set only governs how physical hardware failures and patching events are distributed across replicas—it places VMs into separate fault and update domains to raise the availability SLA. It provides no networking identity or policy construct that can be referenced in an NSG rule, so it cannot specify which application tier is allowed to communicate with the backend tier. Even with VMs in an availability set, you still have to write explicit allow/deny rules based on IP addresses, CIDRs, or ASGs.

Change the allow rule from inbound to outbound traffic.

Why wrong: RDP access from a workstation to a VM is inbound traffic from the perspective of the VM's network interface, so the rule must be configured as an inbound rule. Changing it to outbound would apply to traffic leaving the VM, which is irrelevant to a remote client initiating a connection to port 3389 on the VM. Inbound NSG rules are evaluated for the first packet of a connection, and the deny-all inbound rule at priority 200 would still block the connection before any outbound rule could have an effect.

Change the protocol from TCP to Any on the deny-all rule.

Why wrong: Changing the deny-all rule's protocol from TCP to Any is counterproductive because the existing deny-all rule already blocks all protocols, including TCP. The real issue is rule priority: the deny rule at priority 200 is evaluated before the allow-RDP rule at priority 300, so the RDP packet is denied before the allow rule is ever considered. Broadening the deny rule to Any would simply expand the block to UDP and ICMP as well, making it even harder for any RDP traffic to be accepted, and it would not fix the order-of-evaluation problem.

Attach a user-defined route so the workstation can reach the VM directly.

Why wrong: A user-defined route (UDR) controls the next hop for packets, such as directing traffic through a network virtual appliance, but it does not influence NSG rule evaluation. Even if the UDR makes the workstation's packets reach the VM's subnet, the inbound NSG deny-all rule at priority 200 will still drop the RDP packet on port 3389 before it can reach the VM's operating system. RDP access is governed by NSG allow rules for inbound traffic; routing only affects the layer-3 path, not layer-4 security filtering.

Change the deny rule priority to 65000 so it is evaluated first.

Why wrong: NSG rules are processed in ascending numeric order, so a smaller priority value is always evaluated first. Moving the deny rule to 65000 (a larger number) actually makes it one of the last rules evaluated, after the allow rule at 250—meaning HTTPS would be permitted, not denied. The suggestion incorrectly assumes higher priority numbers are evaluated first, so it does not accomplish the intended block-everything-except-admin-HTTPS behavior.

Convert the allow rule to an outbound rule instead of inbound.

Why wrong: Inbound traffic to the VM's HTTPS port is governed exclusively by the NSG's inbound rule list. Converting the allow rule to an outbound rule does not affect how the inbound deny rule at priority 200 is applied, so the HTTPS packet is still dropped before any outbound rule is ever evaluated. The allow rule must remain an inbound rule and simply be assigned a lower priority number than the deny rule.

Replace the NSG with a route table so HTTPS can pass through the subnet.

Why wrong: Route tables (user-defined routes) control the next-hop path for traffic leaving or traversing a subnet; they are not firewalls and contain no allow/deny actions. Replacing the NSG with a route table would remove all stateful filtering, but the real problem is the rule evaluation order inside the existing NSG. Even if a route table directed HTTPS traffic toward the VM, the inbound deny rule at priority 200 would still drop the packets before they reach the application.

Source: Internet, Destination: VirtualNetwork, Protocol: TCP, Port: 8080, Priority: 250

Why wrong: This rule permits any source on the Internet to reach any destination within the entire VirtualNetwork on TCP port 8080. That exposes the app tier and database tier directly to inbound internet traffic, not just the web-tier VMs that belong to the WebASG. The correct rule scopes the source to WebASG and the destination to AppASG, preserving the intended subnet isolation and least-privilege security. Because the rule is allowed at priority 250, it would also preempt the deny rule at 300 and create a broad network exposure far beyond the explicit web-to-app requirement.

Source: AppASG, Destination: WebASG, Protocol: TCP, Port: 8080, Priority: 250

Why wrong: This rule has the source and destination ASGs reversed: it would allow traffic from the AppASG to the WebASG on TCP 8080, which is the opposite of the required web-to-app flow. Since the rule specifies the wrong direction, any legitimate web-tier requests to the app tier on port 8080 would not match it, and those packets would still be evaluated against the deny rule and dropped. Even though the priority of 250 correctly precedes the deny rule, the ASG orientations render it useless for the intended purpose. The correct rule must place WebASG as the source and AppASG as the destination.

Source: WebASG, Destination: AppASG, Protocol: TCP, Port: 8080, Priority: 350

Why wrong: NSG rules are evaluated in ascending numeric priority order, so a lower number is processed first. If a deny rule exists at priority 300 that blocks web-to-app traffic on port 8080, the deny is processed first and the packet is discarded before a rule at priority 350 is ever reached. The allow rule at 350 would therefore never be effective, and the required traffic would still be blocked. To override or precede the deny, the allow rule must have a priority that is numerically lower than 300 (for example, 250) so it is evaluated earlier.