Free guides, interview Q&As, and job responsibility breakdowns — curated by industry veterans to help you crack MNC interviews
Figure 2: Regional VNet Peering (same region) vs. Global VNet Peering (cross-region)
Virtual Network (VNet) Peering
Definition: A networking feature that connects two Azure Virtual Networks so resources in both can communicate using private IP addresses.
Day-to-Day Example: Like joining two office buildings with a private internal hallway - people walk straight between them without ever stepping outside.
Regional VNet Peering
Definition: A peering connection between two VNets located in the same Azure region.
Day-to-Day Example: Like two departments on the same office campus connecting a hallway between their buildings.
Global VNet Peering
Definition: A peering connection between two VNets located in different Azure regions.
Day-to-Day Example: Like connecting two branch offices in different cities with a dedicated private courier line instead of a public postal service.
Non-Transitive Peering
Definition: A property of VNet Peering where connectivity does not automatically pass through an intermediate peered VNet.
Day-to-Day Example: Like Alice knowing Bob, and Bob knowing Carol, but that alone doesn't mean Alice and Carol know each other.
Hub-and-Spoke Topology
Definition: A network design where a central "hub" VNet holds shared services and peers with multiple "spoke" VNets.
Day-to-Day Example: Like an airport hub where every regional flight connects through the main hub instead of flying directly between small cities.
Allow Virtual Network Access
Definition: A peering setting that permits resources in the two peered VNets to communicate with each other at all.
Day-to-Day Example: Like unlocking the door between two connected buildings so people can actually walk through.
Allow Forwarded Traffic
Definition: A peering setting that permits traffic forwarded from a firewall or network appliance in the peered VNet, not just traffic that originated there.
Day-to-Day Example: Like allowing mail that was re-routed through a sorting office, not only mail sent directly from the original building.
Allow Gateway Transit
Definition: A peering setting on the hub VNet that lets a peered spoke VNet use the hub's VPN or ExpressRoute gateway.
Day-to-Day Example: Like letting a neighboring building use your building's shared loading dock instead of building its own.
Use Remote Gateways
Definition: A peering setting on the spoke VNet that enables it to actually use a gateway shared from the hub.
Day-to-Day Example: Like a neighboring building agreeing to use that shared loading dock rather than insisting on a private one.
Address Space Overlap
Definition: A conflict that occurs when two VNets use the same or overlapping private IP ranges, which blocks peering.
Day-to-Day Example: Like two neighborhoods both numbering their houses 1 through 100 - mail carriers can no longer tell which house is which.
Azure Bastion
Definition: A fully managed PaaS service that provides secure RDP/SSH access to VMs directly through the Azure Portal, without a public IP on the VM.
Day-to-Day Example: Like a manned front desk that lets a verified visitor into a secure building, so the building itself never needs a public street entrance.
AzureBastionSubnet
Definition: A dedicated subnet, with this exact reserved name and a minimum /26 size, required to deploy Azure Bastion in a VNet.
Day-to-Day Example: Like a reserved parking bay at a building that must exist before the building's security desk can be installed.
Bastion Basic SKU
Definition: The entry-level Azure Bastion tier, offering core browser-based RDP/SSH access with fewer advanced features.
Day-to-Day Example: Like a basic hotel key card that opens your room, but not the gym, spa, or valet services.
Bastion Standard SKU
Definition: The higher Azure Bastion tier, adding features like native client support, IP-based connection, and shareable session links.
Day-to-Day Example: Like an upgraded hotel key card that also unlocks the gym, spa, and other premium amenities.
RDP (Remote Desktop Protocol)
Definition: A Microsoft protocol used to remotely view and control the graphical desktop of a Windows VM.
Day-to-Day Example: Like watching and operating a computer through a live video call where you can also control the mouse and keyboard.
SSH (Secure Shell)
Definition: An encrypted protocol used to remotely access and run commands on the command line of a Linux (or Windows) VM.
Day-to-Day Example: Like phoning someone and giving them step-by-step instructions to type, except the call itself does the typing for you securely.
Public IP Address (VM exposure context)
Definition: An internet-routable address assigned to a VM, making it directly reachable from outside Azure.
Day-to-Day Example: Like a shop having a storefront that opens right onto a busy public street.
Private IP Address
Definition: An internal, non-internet-routable address used for communication within a VNet or peered VNets.
Day-to-Day Example: Like a shop's internal staff-only hallway that customers on the street can't walk into.
Network Security Group (NSG)
Definition: A set of allow/deny rules that filters inbound and outbound traffic to subnets or network interfaces.
Day-to-Day Example: Like a security guard checking a list before letting anyone in or out of a building.
Jump Box / Bastion Host (traditional)
Definition: A self-managed VM, often with a public IP, that administrators log into first before hopping to other private VMs - the older approach Azure Bastion replaces as a managed service.
Day-to-Day Example: Like a single guarded front gate you must pass through and sign in at before reaching any building inside a compound.
Figure 3: Azure Bastion architecture - browser to Portal to Bastion to VM private IP
Figure 4: VNet Peering settings cheat sheet
1. VNet Peering vs. VPN Gateway
Feature VNet Peering VPN Gateway Path Microsoft backbone network Encrypted tunnel, can traverse the internet Speed / latency Low latency, high bandwidth, no gateway hop Higher latency, limited by gateway throughput Typical use VNet-to-VNet connectivity inside Azure Site-to-site or point-to-site connections, incl. on-premises
2. Regional Peering vs. Global Peering
Feature Regional Peering Global Peering Scope Same Azure region Across different Azure regions Cost Lower Higher (cross-region data transfer) Common confusion Assumed to be the only type of peering Often forgotten as an option for multi-region designs
3. VNet Peering vs. Hub-and-Spoke (Transitive Connectivity)
Feature Plain VNet Peering Hub-and-Spoke Design Transitivity Non-transitive by default Achieves effective transitivity via routing through the hub Complexity Simple, direct pairs Requires a firewall/NVA and route tables in the hub Best for Two VNets that need to talk directly Many VNets that need centralized, shared connectivity
4. Azure Bastion vs. Traditional Jump Box
Feature Azure Bastion Traditional Jump Box Management Fully managed PaaS by Microsoft Self-managed VM the admin must patch and secure Public IP needed? No - Bastion itself is the only internet-facing piece Usually yes, on the jump box VM Access method Browser via Azure Portal (or native client with Standard SKU) RDP/SSH client connecting to the jump box directly
5. Azure Bastion vs. Public IP + Direct RDP/SSH
Feature Azure Bastion Public IP + Direct RDP/SSH Attack surface VM has no public IP; not internet-reachable VM is directly exposed to internet scanning Brute-force risk Greatly reduced High - port 3389/22 openly reachable Client requirement Just a browser (Basic SKU) Dedicated RDP/SSH client and network path
6. Bastion Basic SKU vs. Standard SKU
Feature Basic SKU Standard SKU Native client support No Yes Connect by private IP directly No Yes (IP-based connection) Shareable session links No Yes
7. Allow Gateway Transit vs. Use Remote Gateways
Feature Allow Gateway Transit Use Remote Gateways Configured on The hub VNet (the one owning the gateway) The spoke VNet (the one borrowing the gateway) Effect Permits the gateway to be shared out Actually consumes/uses the shared gateway Analogy Owner unlocking the shared loading dock Neighbor choosing to use that dock
8. Allow Virtual Network Access vs. Allow Forwarded Traffic
Feature Allow Virtual Network Access Allow Forwarded Traffic Purpose Turns on basic communication between the peered VNets Accepts traffic that was forwarded through an NVA/firewall Required for peering to work at all? Yes No - only needed for forwarded/NVA-routed traffic Typical use Any standard peering connection Hub-and-spoke designs with a firewall in the hub
9. RDP vs. SSH
Feature RDP SSH Used for Windows graphical desktop access Linux (or Windows) command-line access Default port 3389 22 Interface Full graphical desktop Text-based terminal
10. Public IP vs. Private IP (VM Access Context)
Feature Public IP Private IP Reachable from internet? Yes No Typical management use Direct (riskier) RDP/SSH Access via Bastion or peered/VPN connection Security posture Larger attack surface Not internet-exposed, smaller attack surface
Q1. What is VNet Peering, and what kind of network path does traffic take between peered VNets?
Answer: VNet Peering connects two Azure VNets so their resources can communicate using private IP addresses, with traffic routed over the Microsoft backbone network rather than the public internet.
Q2. What is the difference between Regional and Global VNet Peering?
Answer: Regional VNet Peering connects VNets within the same Azure region, while Global VNet Peering connects VNets across different Azure regions, typically at a higher cost.
Q3. Why is VNet Peering described as non-transitive?
Answer: Because if VNet A peers with VNet B and VNet B peers with VNet C, A does not automatically gain connectivity to C - each peering relationship stands on its own.
Q4. How can an organization achieve transitive-style connectivity across many VNets?
Answer: By adopting a hub-and-spoke topology, where a firewall or network virtual appliance in the hub VNet routes traffic between spokes using route tables.
Q5. What must be true of two VNets' address spaces before they can be peered?
Answer: Their address spaces must not overlap; overlapping ranges cause the peering connection to fail.
Q6. What do the peering settings 'Allow Virtual Network Access,' 'Allow Forwarded Traffic,' and 'Allow Gateway Transit' each control?
Answer: Allow Virtual Network Access enables basic communication between the peered VNets; Allow Forwarded Traffic accepts traffic forwarded from an NVA/firewall; Allow Gateway Transit lets a spoke use the hub's shared VPN/ExpressRoute gateway.
Q7. What is Azure Bastion, and what problem does it solve?
Answer: Azure Bastion is a fully managed PaaS service that provides secure RDP/SSH access to VMs through the Azure Portal, removing the need to expose VMs with public IP addresses for remote management.
Q8. What subnet requirement must be met before deploying Azure Bastion?
Answer: A dedicated subnet named exactly AzureBastionSubnet must exist, with a minimum size of /26.
Q9. How does Azure Bastion reduce security risk compared to exposing RDP/SSH directly?
Answer: Because the target VM keeps only a private IP and is never internet-reachable, Bastion greatly reduces exposure to port scanning and brute-force attacks against ports 3389 and 22.
Q10. What is the difference between the Bastion Basic and Standard SKUs?
Answer: The Standard SKU adds native client support, IP-based connections, and shareable session links, while the Basic SKU offers only core browser-based access.
Q11. Why is Azure Bastion typically deployed in the hub VNet of a hub-and-spoke design?
Answer: Because a single Bastion in the hub can be shared by every peered spoke VNet, avoiding the cost and duplication of deploying Bastion separately in each spoke.
Q12. What is the practical difference between VNet Peering and a VPN Gateway connection?
Answer: VNet Peering routes traffic over the Microsoft backbone with low latency and no gateway hop, while a VPN Gateway creates an encrypted tunnel, often over the public internet, and is commonly used for on-premises connectivity.
Q13. What is the difference between 'Allow Gateway Transit' and 'Use Remote Gateways'?
Answer: Allow Gateway Transit is configured on the hub VNet to permit sharing its gateway, while Use Remote Gateways is configured on the spoke VNet to actually consume that shared gateway.
Q14. Does a user need any special client software to connect through Azure Bastion?
Answer: No - with the Basic SKU, a supported web browser through the Azure Portal is enough; the Standard SKU additionally allows native RDP/SSH clients.
Q15. What is a common misconception about VNet Peering across multiple VNets?
Answer: A common misconception is that peering is automatically transitive; in reality each peering link only connects the two VNets directly involved, so a hub-and-spoke design with routing is needed for broader connectivity.
Q1. A company has a Production VNet and a Development VNet in the same Azure region that need to exchange data directly with minimal latency. What should they configure?
Answer: They should configure Regional VNet Peering between the two VNets, allowing direct, low-latency communication over the Microsoft backbone without a gateway.
Q2. An organization has VNets in East US and UK South that must communicate securely. What type of peering is required, and why?
Answer: Global VNet Peering is required, because the VNets are in different Azure regions; regional peering only works within a single region.
Q3. A hub-and-spoke design has Spoke A and Spoke B, both peered only with the Hub. Spoke A tries to reach Spoke B directly. What happens, and why?
Answer: The connection fails by default, because VNet Peering is non-transitive - Spoke A's peering with the Hub does not extend to Spoke B unless traffic is explicitly routed through a firewall or NVA in the Hub.
Q4. An administrator wants to manage a VM's desktop without assigning it a public IP address or opening port 3389 to the internet. What should they use?
Answer: They should use Azure Bastion, which provides secure RDP access through the Azure Portal over the VM's private IP, with no public IP or open internet-facing port required.
Q5. A company wants every spoke VNet in its hub-and-spoke design to share a single Azure Bastion deployment instead of deploying Bastion in each spoke. What should they configure?
Answer: They should deploy Azure Bastion once in the Hub VNet and ensure VNet Peering is configured (with the necessary access settings) between the Hub and each Spoke so all spokes can use the shared Bastion.
Q6. An admin tries to peer two VNets, both using the address range 10.0.0.0/16, and the peering fails. Why?
Answer: The peering fails because the two VNets have overlapping address spaces; peered VNets must use non-overlapping address ranges.
Q7. A spoke VNet needs to reach on-premises resources through the Hub VNet's existing VPN Gateway instead of deploying its own gateway. What peering settings are needed?
Answer: The Hub VNet must enable Allow Gateway Transit, and the Spoke VNet must enable Use Remote Gateways, allowing the spoke to use the hub's shared gateway.
Q8. A security review finds a VM with a public IP and open port 22 for SSH access, flagged as a high risk. What is the recommended remediation?
Answer: Remove the public IP from the VM and deploy Azure Bastion (in an AzureBastionSubnet) so administrators connect securely over the VM's private IP instead of exposing SSH to the internet.
