Cascade Regional Airlines just created a network security group for the crew-scheduling subnet without adding any custom rules yet. A VM in a different subnet of the same virtual network needs to reach a VM in the crew-scheduling subnet. Will that traffic be allowed?
Select an answer to reveal the explanation.
Short Explanation
A brand-new NSG isn't a blank wall — Azure ships every one with a small set of built-in default rules already in place. One of them, AllowVnetInBound, already trusts anything coming from inside the same virtual network. So two subnets in the same VNet can talk to each other on day one, no custom rule required.
Full Explanation
Every NSG is created with six default rules: three inbound (AllowVnetInBound, AllowAzureLoadBalancerInBound, DenyAllInBound) and three outbound (AllowVnetOutBound, AllowInternetOutBound, DenyAllOutBound), and these apply automatically before any custom rule is added. AllowVnetInBound permits traffic whose source is the VirtualNetwork service tag, which covers every subnet within the same VNet (and peered VNets, when peering is configured), so the crew-scheduling subnet's VM is reachable from another subnet in the same VNet without any custom rule at all. The claim that NSGs block everything until a custom rule exists misunderstands the default rule set, which is permissive for VNet-internal traffic specifically. The claim that different subnets require VNet peering confuses subnet-to-subnet communication (already routable within one VNet by design) with VNet-to-VNet communication (which does require peering or a gateway). The AllowAzureLoadBalancerInBound distractor misattributes the correct behavior to the wrong default rule, which actually only covers Azure's load balancer health-probe traffic. To confirm this behavior in practice, an engineer can review ‘Effective security rules’ on the target NIC in the Azure portal.