8.1 Introduction to Azure Network Security

Every Virtual Machine, database, and application hosted in Azure communicates over a network, and that same network can also be used by an attacker to reach a resource if it is left unprotected. Azure Network Security is the collective term for the tools, components, and rules that control which traffic is allowed to enter or leave Azure resources. Chapter 8 focuses on the practical, exam-relevant building blocks -- Network Security Groups, Route Tables, User Defined Routes, and Network Interface Cards -- that an AZ-104 administrator configures every day. Understanding how these pieces fit together is essential before moving on to more advanced services such as Azure Firewall or Azure Bastion.

What is Network Security?

Definition: Network Security in Azure is the practice of controlling, filtering, and monitoring the traffic that flows into and out of Azure resources such as Virtual Machines, Subnets, and Virtual Networks, so that only authorized and expected communication is allowed. It combines several services and controls -- including Network Security Groups, Firewalls, Route Tables, and monitoring tools -- to reduce the attack surface of a cloud environment. Rather than relying on a single control, Azure network security is applied in layers, so that if one control is misconfigured, another layer can still reduce risk. This layered approach is often called defense in depth, and it is a core principle tested throughout the AZ-104 exam.

(Network Security का सीधा मतलब है कि Azure resources तक सिर्फ जरूरी और authorized traffic ही पहुंचे। इसके लिए हम अलग-अलग layers इस्तेमाल करते हैं, जैसे NSG, Firewall और Route Tables, ताकि अगर एक layer में गलती हो जाए तो दूसरी layer resource को फिर भी protect करे।)

Why Network Security is Required

Without proper network security, any Virtual Machine that has a public IP address could be exposed to the entire Internet, including automated scanning tools and attackers looking for open ports such as RDP (3389) or SSH (22). Organizations also need to isolate sensitive workloads -- for example, a database Subnet should generally not accept direct traffic from the Internet, only from the application tier. Compliance requirements in many industries specifically mandate that traffic be restricted and logged, which makes network security both a technical and a business necessity. Finally, human error such as an accidentally opened port is far more common than a sophisticated attack, so simple, well-documented NSG rules prevent the majority of real-world incidents.

Azure Network Security Components

The Module 8 syllabus introduces six core components that work together to secure Azure network traffic: Internet, Azure Firewall, Network Security Group (NSG), Virtual Network, Subnet, and Virtual Machine. Traffic conceptually flows from the public Internet, is optionally inspected by Azure Firewall, enters the Virtual Network, passes through a Subnet, is filtered by an NSG, and finally reaches the Virtual Machine. Each component has a distinct responsibility, and an administrator must understand where each one sits in the traffic path to design an effective security model. The diagram below illustrates this flow from the outermost, least-trusted zone (the Internet) to the innermost, most specific resource (the VM).

Why is it Important?

A layered network security design ensures that even if one control fails or is misconfigured, other layers continue to protect the environment. For the AZ-104 exam, candidates are frequently tested on scenario questions that ask which combination of NSG, Route Table, or Firewall setting would achieve a specific security outcome. In real projects, correctly designed network security also reduces the blast radius of a compromised resource, because traffic from that resource is still constrained by the rules applied to its Subnet and NIC.

8.2 Network Security Group (NSG)

A Network Security Group, commonly abbreviated as NSG, is the primary traffic-filtering tool used by AZ-104 administrators on a daily basis. It is a free, software-defined firewall built into Azure that evaluates every packet against an ordered list of rules and decides whether to allow or deny it.

What is NSG?

Definition: An Azure Network Security Group (NSG) is a software-defined set of security rules that controls inbound and outbound network traffic to Azure resources such as Virtual Machines and Subnets. Each rule specifies conditions -- Source, Destination, Protocol, Port, and Direction -- along with an Action of Allow or Deny, and rules are evaluated strictly in order of Priority, from the lowest number to the highest. An NSG can be associated with a Subnet, a Network Interface, or both, which gives administrators flexibility in deciding exactly where traffic filtering should be enforced. Because NSGs are stateful, a rule that allows outbound traffic automatically allows the matching return traffic back in, without a separate inbound rule being required.

(NSG को आप एक traffic filter की तरह समझ सकते हैं जो हर packet को check करता है और Priority के हिसाब से decide करता है कि उसे Allow करना है या Deny। यह Subnet पर भी लगाया जा सकता है और किसी VM की Network Interface (NIC) पर भी।)

Why NSG is Used

NSGs are used because they provide a simple, cost-free, and portal-manageable way to control exactly which traffic reaches a Virtual Machine or Subnet. Instead of configuring firewall software separately inside every VM, an administrator can apply one consistent NSG at the Subnet level, and Azure enforces it before traffic even reaches the operating system. This reduces the management overhead of securing many VMs individually and makes audits easier, since all the rules are visible in one place in the Azure Portal. NSGs are also a required building block for AZ-104 exam scenarios involving least-privilege network access, such as restricting RDP or SSH access to only a specific administrator IP address.

NSG Components

Every NSG security rule is built from the same seven components: Security Rules (the individual entries), Priority, Source, Destination, Protocol, Port Number, Action, and Direction. Understanding each field is essential because AZ-104 exam questions often describe a rule using these exact terms and ask what traffic it will allow or block. The diagram below groups these seven components together as they would appear when creating a new rule in the Azure Portal.

(Priority सबसे महत्वपूर्ण field है -- सबसे कम number वाला rule सबसे पहले check होता है, और एक बार match हो जाने के बाद बाकी rules ignore हो जाते हैं।)

8.3 NSG Security Rules

What Can NSG Filter?

Definition: NSG security rules can filter traffic based on six criteria: Source IP, Destination IP, Port Number, Protocol, Direction, and Action. By combining these criteria, an administrator can write a very specific rule, such as allowing only TCP traffic on port 443 from a single corporate IP range to a specific Subnet, while denying everything else by default. Azure automatically includes a small set of default rules at the lowest priority (highest number) that allow VNet-to-VNet traffic, allow traffic from the Azure Load Balancer, and deny all other inbound traffic, which acts as a safety net. Administrators add their own custom rules with lower priority numbers so that those custom rules are evaluated before the defaults.

Inbound Security Rules

An Inbound Security Rule controls traffic that is coming into a resource from outside, such as a management connection from an administrator's laptop or a request from a web client. Because inbound traffic originates from potentially untrusted sources, inbound rules are usually written more restrictively, often allowing only specific ports from specific, known IP addresses. A very common real-world example is restricting RDP (port 3389) so that it is allowed only from the corporate office IP range, rather than from Any source, which would expose the VM to the entire Internet. Getting inbound rules wrong is one of the most frequent causes of both security incidents and AZ-104 exam trick questions.

Common Inbound Ports

Outbound Security Rules

An Outbound Security Rule controls traffic that is leaving a resource and heading toward another Subnet, the Internet, or an on-premises network. Outbound rules are important for preventing a compromised VM from being used to attack other systems, exfiltrate data, or communicate with a malicious command-and-control server. A typical outbound rule might allow HTTPS (443) so applications can reach external APIs, while denying outbound traffic on uncommon ports that legitimate applications rarely use. Because NSGs are stateful, an inbound request that was allowed in automatically has its response traffic permitted out, so outbound rules mainly matter for connections that a resource initiates itself.

Difference Between Inbound and Outbound Rules

(Inbound Rule यह control करता है कि बाहर से resource तक traffic आ सकता है या नहीं, जबकि Outbound Rule यह control करता है कि resource से बाहर traffic जा सकता है या नहीं।)

8.4 Applying NSG to Subnets and NICs

NSG Association

Definition: NSG Association refers to the point in the Azure network hierarchy where a Network Security Group is attached so that it can actually filter traffic. Azure allows an NSG to be associated with a Subnet, with an individual Network Interface Card (NIC), or with both at the same time, giving administrators fine-grained control over exactly which traffic is evaluated at which layer. When an NSG is associated at both levels, Azure evaluates the Subnet NSG and the NIC NSG separately, and traffic must be allowed by both for it to reach the Virtual Machine. This dual-association model is a frequent source of AZ-104 exam questions, since a VM can be unreachable even though its NIC-level NSG looks correctly configured, simply because the Subnet-level NSG is blocking the traffic first.

(NSG को Subnet पर भी लगाया जा सकता है और NIC पर भी। अगर दोनों जगह NSG लगी है, तो traffic को दोनों rules pass करने होंगे, तभी VM तक पहुंचेगा।)

Applying NSG to a Subnet

Applying an NSG at the Subnet level means the same set of rules automatically applies to every resource placed inside that Subnet, which is efficient for enforcing common, organization-wide rules. This approach is commonly used to apply a baseline set of protections -- for example, denying all inbound Internet traffic to a database Subnet -- without having to configure each VM's NIC individually. It also simplifies management, because adding a new VM to an already-secured Subnet automatically brings that VM under the existing rule set with no extra configuration. The trade-off is that a Subnet-level NSG cannot easily give one specific VM different access than its neighbours in the same Subnet.

Applying NSG to a Network Interface (NIC)

Applying an NSG directly to a Network Interface Card means the rules apply only to that single VM's network traffic, regardless of what other resources share the same Subnet. This is useful when one VM in a Subnet needs an exception -- for instance, a jump-box or bastion VM that requires RDP access while its neighbouring VMs in the same Subnet should never allow RDP at all. NIC-level NSGs give administrators very precise, resource-specific control, but they also increase management overhead because each VM's rules must be reviewed and maintained individually. In production environments, NIC-level NSGs are typically reserved for exceptions rather than being the primary security control.

Subnet NSG vs NIC NSG

Why Should We Apply NSG?

Applying NSGs consistently ensures that Azure resources are protected by design rather than by accident, and it gives administrators a clear, auditable record of exactly which traffic is permitted. Choosing the right association level -- Subnet, NIC, or both -- allows a design that balances ease of management against the need for granular, resource-specific control. In enterprise environments, best practice is generally to apply a baseline NSG at the Subnet level and reserve NIC-level NSGs only for genuine, documented exceptions.

Practical Difference Between Subnet and NIC NSG

In practice, if a Subnet NSG denies inbound RDP but a specific VM's NIC NSG allows it, the connection will still fail, because both NSGs must allow the traffic for it to succeed. Conversely, if the Subnet NSG allows RDP but the NIC NSG denies it, the same connection will also fail. This 'both must allow' behaviour is one of the most commonly tested troubleshooting concepts in the AZ-104 exam, and it is the first thing an administrator should check when a VM is unexpectedly unreachable.

8.5 Azure Route Tables

What is a Route Table?

Definition: An Azure Route Table is a governance object that contains a set of rules, called routes, which determine where network traffic from a Subnet is directed. Azure automatically creates a default system route table for every Subnet, but administrators can create and associate a custom Route Table to override this default behaviour for specific business or security needs. Each route in a Route Table specifies an Address Prefix (the destination) and a Next Hop Type (where matching traffic should be sent), such as Virtual Network, Internet, Virtual Network Gateway, or Virtual Appliance. Route Tables are essential when traffic needs to be forced through a specific device, such as a firewall appliance, before it reaches its final destination.

(Route Table यह decide करती है कि Subnet से निकलने वाला traffic किस रास्ते से जाएगा। By default Azure अपनी खुद की system routes बनाता है, लेकिन जरूरत पड़ने पर हम custom Route Table बनाकर traffic को अपने हिसाब से direct कर सकते हैं।)

Default Azure Route

Every Subnet in Azure automatically receives a set of default system routes even if the administrator never creates a custom Route Table. These default routes ensure that basic connectivity works out of the box: resources within the same Virtual Network can reach each other, resources can reach the public Internet, and, where a VPN or ExpressRoute connection exists, resources can reach the on-premises network. Administrators cannot delete these default system routes directly, but they can override specific ones by adding a User Defined Route with a more specific address prefix. Knowing what the default routes cover is important because it explains why a brand-new Subnet already has basic connectivity before any custom routing is configured.

Virtual Network

The Virtual Network default route ensures that traffic destined for any address range within the same Virtual Network -- including peered Virtual Networks -- is delivered directly, without leaving the Azure backbone network. This is what allows a web-tier VM in one Subnet to communicate with a database-tier VM in another Subnet of the same VNet without any additional routing configuration. Because this route is created automatically, most intra-VNet communication problems are actually caused by NSG rules rather than routing issues.

Internet

The Internet default route sends any traffic that does not match a more specific destination out toward the public Internet through Azure's infrastructure. This route is what allows a VM with a public IP address, or one behind a NAT Gateway or Load Balancer, to reach external websites, package repositories, or APIs. Administrators sometimes override this default route with a UDR to force Internet-bound traffic through a Network Virtual Appliance or Azure Firewall for inspection first, a design pattern known as 'forced tunnelling'.

Local Network

The Local Network route direction refers to traffic destined for an organization's on-premises network, reachable via a Site-to-Site VPN Gateway or ExpressRoute circuit. When such a connection exists, Azure automatically adds a route so that Azure resources can communicate with on-premises servers as if they were part of the same extended network. This route is fundamental to hybrid cloud scenarios, where some workloads remain on-premises while others are migrated to Azure, and both sides need to communicate securely.

8.6 User Defined Routes (UDR)

What is User Defined Route (UDR)?

Definition: A User Defined Route, commonly abbreviated as UDR, is a custom route that an administrator manually creates within a Route Table to override Azure's default system routing behaviour for a specific address prefix. A UDR specifies an Address Prefix and a Next Hop Type, which can be Virtual Appliance (using a specific private IP address), Virtual Network Gateway, None (to drop the traffic), Virtual Network, or Internet. UDRs are most commonly used to force traffic through a Network Virtual Appliance, such as a third-party firewall or Azure Firewall, so that all traffic can be inspected, logged, or filtered before reaching its destination. Without UDRs, traffic would always follow Azure's default, most-direct path, which is not always desirable from a security or compliance standpoint.

(UDR का इस्तेमाल तब होता है जब हमें Azure के default routing behaviour को बदलना हो, जैसे traffic को जबरदस्ती किसी Firewall Appliance से होकर भेजना, ताकि हर packet पहले inspect हो सके।)

Why UDR is Used

UDRs are used whenever the default, direct routing path does not meet a business or security requirement, such as needing every packet leaving a Subnet to pass through a centralized firewall for inspection. They are also used in hub-and-spoke network topologies, where spoke Virtual Networks route all their traffic through a shared hub Virtual Network Appliance rather than communicating directly. Another common use case is deliberately blocking traffic to a specific destination by setting the Next Hop Type to None, which silently drops matching packets. Because a single misconfigured UDR can accidentally cut off connectivity for an entire Subnet, changes to Route Tables should always be tested carefully before being applied to production.

Benefits of UDR

Allows traffic to be forced through a centralized firewall or Network Virtual Appliance for inspection.

Supports hub-and-spoke network designs where spokes route through a shared hub.

Provides the ability to deliberately block traffic to specific destinations using Next Hop Type: None.

Gives administrators precise control over traffic paths for compliance or auditing requirements.

Works alongside NSGs to provide both routing control and traffic filtering.

Associating Route Tables with Subnets

A Route Table containing one or more UDRs must be explicitly associated with a Subnet before its routes take effect; simply creating the Route Table is not enough. Once associated, every resource within that Subnet automatically follows the custom routes defined in the table, in addition to any default system routes that were not overridden. A single Route Table can be associated with multiple Subnets at the same time, which is efficient for applying the same custom routing logic across several Subnets in a hub-and-spoke design. If a Subnet's Route Table association is later removed, the Subnet immediately reverts to using only Azure's default system routes.

8.7 Network Interface Card (NIC)

What is a Network Interface (NIC)?

Definition: A Network Interface Card, or NIC, is the Azure resource that provides the actual network connectivity between a Virtual Machine and a Virtual Network Subnet. Every Azure VM has at least one NIC, which holds configuration such as a private IP address, an optional public IP address, DNS settings, and any NSG associated directly with that interface. Some VMs, particularly those used for network appliances or routing, can have multiple NICs attached to different Subnets to allow traffic separation. Because the NIC sits between the VM and the network, it is the exact point where NIC-level NSG rules are enforced before traffic reaches the VM's operating system.

(NIC वह component है जो VM को Network से जोड़ता है। हर VM के पास कम से कम एक NIC होता है, और इसी NIC पर IP address, DNS settings, और NIC-level NSG configure होते हैं।)

 

NIC and Azure Virtual Machine

A Virtual Machine relies entirely on its Network Interface to send and receive traffic; without a NIC, a VM would have no network connectivity at all. When a VM is created through the Azure Portal, a NIC is automatically created and attached on the administrator's behalf, though it can also be created and attached manually for more advanced scenarios. Some administrators detach a NIC from a stopped VM and re-attach it to another VM to preserve a specific private IP address or MAC-address-dependent licensing configuration. This tight coupling between VM and NIC is why troubleshooting connectivity issues almost always starts by examining the VM's NIC configuration.

NIC and NSG

A Network Security Group can be associated directly with a NIC, in which case the rules apply only to traffic for that specific Virtual Machine, independent of any Subnet-level NSG. This NIC-level association is what allows a single exception VM, such as a management jump-box, to have different access rules than the rest of its Subnet. As covered in section 8.4, when both a Subnet NSG and a NIC NSG exist, traffic must be permitted by both before it reaches the VM, which makes the NIC an important checkpoint when diagnosing connectivity problems.

NIC and Network Connectivity

Beyond security, the NIC also determines core connectivity settings such as the VM's private IP address (static or dynamic), whether IP forwarding is enabled, and which accelerated networking options are available for improved throughput. Administrators troubleshooting a connectivity issue should check the NIC's effective routes and effective security rules, both of which are available directly from the NIC's page in the Azure Portal, to see the combined result of all Route Tables and NSGs affecting that interface. This effective view is extremely useful because it shows the final, evaluated outcome rather than requiring the administrator to manually combine multiple rule sets.

8.8 Verify Network Connectivity

Why Network Connectivity is Verified

Definition: Verifying network connectivity is the structured process of confirming that traffic can actually flow between two Azure resources, or between an Azure resource and an external endpoint, as intended by the network design. It is performed both proactively, as part of testing a new deployment, and reactively, when users report that an application is unreachable or slow. Azure provides a dedicated tool called Network Watcher specifically for this purpose, which includes features such as IP Flow Verify, Connection Troubleshoot, and Next Hop, so administrators do not have to guess which rule is causing a problem. Regularly verifying connectivity after any network change -- such as updating an NSG rule or Route Table -- helps catch misconfigurations before they affect production users.

(Connectivity verify करने का मतलब है यह confirm करना कि traffic actually resource तक पहुंच पा रहा है या नहीं। इसके लिए Azure Network Watcher जैसे tools का इस्तेमाल किया जाता है।)

Basic Connectivity Verification

Basic verification often starts with simple, familiar tools such as ping or a Telnet-style port test run from inside or toward a VM, to confirm at a low level whether packets are reaching the destination. However, ICMP-based tools like ping are frequently blocked by default NSG rules or Azure infrastructure, so a failed ping does not always mean the application itself is unreachable. For that reason, testing the actual application port -- for example, using Test-NetConnection in PowerShell against port 443 -- gives a more reliable picture of real-world connectivity than ping alone. Documenting the exact source, destination, port, and protocol tested also makes it much easier to compare results before and after a configuration change.

Verify Communication Between Azure Resources

Azure Network Watcher's IP Flow Verify tool lets an administrator specify a source and destination IP, port, and protocol, and it returns whether the traffic would be allowed or denied, along with the exact NSG rule responsible for that outcome. The Connection Troubleshoot tool goes a step further by actually testing live connectivity between two endpoints and reporting latency, hop-by-hop details, and any blocking issue found along the path. The Next Hop tool shows exactly which route -- default or user-defined -- traffic from a given source would take to reach a given destination, which is invaluable when diagnosing routing rather than filtering problems. Using these three tools together typically identifies the root cause of most Azure connectivity issues within minutes rather than hours of manual investigation.

8.9 Troubleshoot Azure Network Communication

Common Network Communication Problems

Definition: Most Azure network communication problems fall into one of four categories: an NSG rule blocking the traffic, a missing or incorrect Subnet/NIC association, an incorrect IP address configuration, or a Route Table sending traffic down an unexpected path. Recognizing which category a problem belongs to quickly narrows down where to look, rather than randomly checking every setting in the environment. Many real-world incidents are caused by a recent change, such as someone editing an NSG rule or adding a new UDR, so checking recent activity logs is often a fast way to identify the likely cause. A systematic, step-by-step troubleshooting approach, rather than guessing, is what the AZ-104 exam expects administrators to demonstrate.

Check NSG Rules

The first troubleshooting step should always be checking both the Subnet-level and NIC-level NSG rules, since either one denying traffic will block the connection regardless of the other. Administrators should pay close attention to rule Priority, because a lower-priority-number Deny rule placed above an intended Allow rule will silently block traffic that the administrator expected to work. The Effective Security Rules view on the NIC page is the fastest way to see the final, combined result of all applicable NSGs without manually cross-referencing multiple rule sets.

Check Subnet and NIC Associations

Administrators should confirm that the correct NSG is actually associated with the intended Subnet or NIC, since it is common to accidentally create a new NSG without ever associating it, leaving the resource unprotected or the intended rules not applied. Similarly, confirming that a VM's NIC is attached to the correct Subnet is important, especially in environments with multiple similarly named Subnets for different environments such as Development and Production.

Check IP Addresses

Incorrect or conflicting IP address configuration is another common source of connectivity failures, particularly when a VM has a static private IP that falls outside its Subnet's address range, or when a public IP has been deallocated after a VM was stopped. Administrators should verify that the private IP address, subnet mask, and any public IP assignment match what the network design expects before investigating more complex causes.

Check Route Tables and UDRs

When NSGs and IP addressing both appear correct but traffic still fails to reach its destination, the next step is reviewing the Route Table associated with the Subnet for any User Defined Routes that might be sending traffic to an unintended or unreachable Next Hop. The Next Hop tool in Network Watcher directly answers 'where would this traffic actually go', which is far faster than manually reading through every route in the table.

Verify Network Connectivity

After making a corrective change -- whether to an NSG rule, a Route Table, or an IP configuration -- the fix should always be re-verified using the same Network Watcher tools described in section 8.8, to confirm the specific traffic flow now succeeds as expected. This closing verification step also creates a record that the issue was genuinely resolved, rather than assuming a configuration change fixed the problem without testing it.

8.10 Practical Labs and Exercises

Practical 1: Create and Configure NSG

• Sign in to the Azure Portal.
• Search for Network Security Groups and click Create.
• Select the required Subscription, Resource Group, and Region.
• Provide a meaningful NSG name (e.g., NSG-WebSubnet).
• Review and create the NSG.

Practical 2: Create Inbound and Outbound Security Rules

• Open the newly created NSG.
• Add an Inbound rule allowing RDP or SSH only from your own IP address.
• Add an Outbound rule allowing HTTPS (443) to the Internet.
• Set an appropriate Priority for each rule and save.

Practical 3: Associate NSG with Subnet

• Open the target Virtual Network and Subnet.
• Associate the NSG created in Practical 1 with the Subnet.
• Verify the association is shown under the Subnet's settings.

Practical 4: Associate NSG with NIC

• Open a test Virtual Machine's Network Interface.
• Associate an NSG with the NIC.
• Verify the Effective Security Rules view shows the combined Subnet and NIC rules.

Practical 5: Configure Route Table

• Search for Route Tables and click Create.
• Select the required Subscription, Resource Group, and Region.
• Provide a meaningful name (e.g., RT-HubFirewall) and create the Route Table.

Practical 6: Create User Defined Route

• Open the Route Table created in Practical 5.
• Add a route with Address Prefix 0.0.0.0/0 and Next Hop Type Virtual Appliance.
• Enter the private IP address of the Network Virtual Appliance or Firewall.
• Associate the Route Table with the required Subnet.

Practical 7: Verify Network Connectivity

• Open Azure Network Watcher.
• Run IP Flow Verify between two test resources.
• Run Connection Troubleshoot for an end-to-end connectivity test.
• Run Next Hop to confirm which route matching traffic will take.

Practical 8: Troubleshoot Network Communication

• Deliberately add a Deny rule with a low priority number to block a known-working connection.
• Observe the failure using Connection Troubleshoot.
• Review Effective Security Rules to identify the blocking rule.
• Remove or correct the rule and re-verify that connectivity is restored.

Common Student Confusions

Quick Revision

AZ-104 Interview Questions

1. What is Azure Network Security and why is it important?
2. What is a Network Security Group (NSG)?
3. What are the components of an NSG security rule?
4. What is the difference between an Inbound Rule and an Outbound Rule?
5. Can an NSG be applied to both a Subnet and a NIC at the same time? What happens if they conflict?
6. What is an Azure Route Table and what are the default system routes?
7. What is a User Defined Route (UDR) and when would you use one?
8. What is the role of a Network Interface Card (NIC) in Azure networking?
9. How would you verify connectivity between two Azure Virtual Machines?
10. How would you troubleshoot a VM that suddenly cannot be reached over RDP?
11. What tools does Azure Network Watcher provide for troubleshooting?
12. How would you force all outbound traffic from a Subnet through a firewall appliance?