Day 8: Azure Networking Interview Questions & Scenario-Based Architecture

Welcome to Episode 8 of the Azure Zero to Hero series. This session tests and solidifies the practical architectural knowledge covered from Day 1 to Day 7—spanning cloud fundamentals, Resource Groups, Virtual Machines, Virtual Networks (VNets), Subnets, Network Security Groups (NSGs), Application Security Groups (ASGs), Azure Firewall, Azure Bastion, and Load Balancers.

1. Why Do We Need Networking Interview & Scenario Prep?

While theoretical understanding of Azure primitives is essential, real-world interviews and enterprise architectural designs demand a deep comprehension of how these components interact under constraints.

• Bridging Theory and Practice: Moving beyond basic definitions to solve complex traffic routing and security dilemmas.
• Avoiding AWS Anti-Patterns: Recognizing that Azure's networking constructs (such as NSGs/ASGs versus AWS Security Groups/NACLs) have unique implementation models.
• Production Reliability: Mastering security isolation, stateful packet inspection, and scaling strategies before deploying to production.

2. Core Mental Model: The Enterprise Networking Ecosystem

When designing an ideal Azure VNet architecture, traffic flows through a strictly controlled hierarchy of security layers, edge devices, and load balancing mechanisms.

3. Question 1: Network Security Groups (NSGs) vs. Application Security Groups (ASGs)

The Problem

Imagine you have an application subnet (App Subnet) containing various microservices (login, logout, payments, billing, catalog) and a database subnet (DB Subnet). You want to block login and logout from reaching the database while allowing all other services (payments, billing, etc.) to communicate with the DB.

Furthermore, your microservices run on Virtual Machine Scale Sets (VMSS) and scale dynamically, meaning their IP addresses change frequently.

The Naive vs. Better Approach

• Naive Approach (IP-Based NSG Rules): You attach an NSG to the database and manually enter every single virtual machine IP address into the inbound rule.
  • Pitfall: When instances scale up/down or IP addresses rotate, your NSG rules break or miss newly spawned instances, leading to security gaps or connection failures.
• Better Approach (Using ASGs in Conjunction with NSGs):
  • You create an Application Security Group (ASG) (e.g., asg-allowed-apps) and assign it directly to the authorized VMs or VMSS instances.
  • In your database's NSG inbound rule, instead of specifying volatile IP addresses, you select the ASG as the Source.

Note: Do not compare Azure NSGs and ASGs directly to AWS Security Groups and Network ACLs (NACLs). In Azure, NSGs and ASGs work in conjunction. ASGs allow you to group VMs logically and apply security rules without worrying about underlying IP addresses.

4. Question 2: Blocking Access from a Specific Subnet within a VNet

The Scenario

Within a single Virtual Network, you have multiple subnets: a DB Subnet, various application subnets, and a Firewall subnet. By default, Azure VNets permit unrestricted internal communication across all subnets via an implicit default rule. How do you block traffic specifically originating from a designated XYZ Subnet to your database instances?

Step-by-Step Resolution

Every Azure NSG contains default system rules. One critical rule is:

• Rule Name: AllowVnetInbound
• Action: Allow
• Default Priority: 65000

To override this default behavior and block a specific subnet:

1. Create an Inbound Security Rule on the target VM or subnet's NSG.
2. Set Action to Deny.
3. Define Source as the CIDR block of the target XYZ Subnet.
4. Assign a Higher Priority (Lower Number): Priority numbers range from 100 (highest priority) to 65356 (lowest priority). Because 65000 allows all VNet traffic, you must assign your custom deny rule a priority number lower than 65000 (e.g., 300 or 100).

5. Question 3: Are Azure NSGs Stateful or Stateless?

The Question

If you open inbound Port 80 on an NSG to allow public web traffic to a Jenkins server, do you also need to create a corresponding outbound security rule for the server to reply back to the user?

The Answer

Azure NSGs are stateful in nature.

• Stateful Behavior: When an inbound request arrives at Port 80, the NSG remembers the connection state. When the application inside the virtual machine generates a response (HTML page, API payload), the NSG automatically allows the return traffic outbound—even if no explicit outbound security rule was defined for it.
• Contrast with Stateless Constructs: If NSGs were stateless (like AWS NACLs), you would be required to explicitly configure both inbound and outbound rules for traffic to flow in both directions.

6. Question 4: Azure Firewall vs. Network Security Groups (NSGs)

When designing network topology, choosing between Azure Firewall and NSGs depends on the scope and layer of protection required.

7. Question 5: Advantages and Best Practices of Resource Groups

Resource Groups are mandatory organizational containers in Azure, but they offer powerful operational advantages beyond mere grouping:

• Logical Organization & Lifecycle Management: Group resources by project and environment (e.g., Dev, Staging, Production), allowing you to delete an entire application stack with a single delete command during free-tier cleanup or environment teardown.
• Role-Based Access Control (RBAC): Grant developers, QA engineers, or DevOps specialists granular permissions at the Resource Group level rather than managing individual resource access.
• Cost Management & Billing: Track expenditure per project easily by filtering cost analysis reports by Resource Group.
• Resource Tagging & ARM Templates: Apply governance tags and deploy declarative infrastructure templates consistently across all contained resources.

8. Question 6: Azure Custom Data vs. User Data

The Distinction

While AWS users often conflate user data with custom data, Azure maintains a distinct architectural separation between Custom Data and User Data.

9. Question 7: Azure Application Gateway vs. Azure Load Balancer

Choosing the right load balancing tier depends on the OSI networking layer and the routing complexity required by your application architecture.

• Azure Load Balancer (Layer 4): Operates at the transport layer (TCP/UDP). It performs high-performance, low-latency load balancing based on IP addresses and ports. Ideal for backend application tiers and databases.
• Azure Application Gateway (Layer 7): Operates at the application layer (HTTP/HTTPS). It supports advanced routing capabilities such as path-based routing (e.g., routing /login to Server A and /logout to Server B), host-based routing, and integrated Web Application Firewall (WAF) protection. Ideal for public-facing web tiers.

10. Question 8: Scenario-Based Ideal VNet Traffic Flow

The Interview Scenario

Explain the ideal enterprise network setup and traffic flow for a secure web application deployed inside a web subnet.

Architectural Walkthrough

1. DNS Resolution: The user types the application URL into their browser. Azure DNS resolves the domain name to the public IP address of the Azure Firewall.
2. Perimeter Defense & DNAT: The request hits the Azure Firewall. Utilizing Destination Network Address Translation (DNAT) rules, the firewall safely translates and forwards legitimate traffic while dropping malicious payloads.
3. Layer 7 Load Balancing: Traffic passes from the firewall to an Application Gateway, which inspects HTTP paths and terminates SSL.
4. Subnet & NSG Enforcement: The request reaches the Web Subnet. Even if perimeter defenses were somehow bypassed, Network Security Groups (NSGs) and Application Security Groups (ASGs) enforce strict micro-segmentation rules, blocking unauthorized ports and internal lateral movement.
5. DevOps Management Access: Internal DevOps engineers do not expose VMs to the public internet. Instead, they securely connect via Azure Bastion over TLS, enabling agentless SSH/RDP directly through the Azure Portal with RBAC and MFA enforced.

11. Question 9: Purpose and Advantages of Azure Bastion

The Purpose

Azure Bastion is a fully managed PaaS service that provides secure and seamless RDP/SSH connectivity to virtual machines directly over SSL (Port 443) without needing public IP addresses on the target VMs.

Key Advantages

• Elimination of Public IPs: Target virtual machines do not require public IP addresses, completely hiding them from the public internet.
• Reduced Attack Surface: Ports 22 (SSH) and 3389 (RDP) no longer need to be exposed on NSGs to the outside world.
• Simplified Connectivity: One-click browser-based access straight from the Azure Portal.
• Enhanced Governance: Centralized control via RBAC, Multi-Factor Authentication (MFA) integration, and robust audit logging of administrative sessions.

Summary and Key Takeaways

• NSGs and ASGs Work Together: ASGs logically group virtual machines, while NSGs apply security rules using those ASGs as sources or destinations to prevent IP-management sprawl.
• Stateful NSGs: Azure NSGs remember inbound connection states; return outbound traffic is automatically permitted without explicit outbound rule creation.
• Rule Priority Mechanics: NSG evaluation happens by priority number order, where lower numbers mean higher priority (e.g., Priority 100 overrides Priority 65000).
• Resource Groups for Governance: Resource Groups provide the foundation for RBAC, cost tracking, lifecycle management, and environment isolation (Dev vs. Prod).
• Custom Data vs. User Data: Custom data executes strictly on the first VM boot (cloud-init), whereas User Data persists throughout the VM's lifecycle.
• Layer 4 vs. Layer 7 Load Balancing: Use Azure Load Balancer (L4) for fast TCP/UDP backend routing, and Application Gateway (L7) for HTTP path-based routing and WAF protection.
• Ideal Enterprise Architecture: Combine Azure Firewall (DNAT/perimeter defense), Application Gateway (L7 routing), NSGs/ASGs (subnet micro-segmentation), and Azure Bastion (secure admin access) for a bulletproof cloud environment.