Network Connectivity Design — Azure Security Engineer (AZ-500)
Network Segmentation Is Not Just Subnets
Requirement: isolate a backend SQL database from all internet traffic while allowing access from a specific App Service. Competing approaches: VNet integration with a service endpoint, or a Private Endpoint with DNS resolution. The deciding constraint is whether the scenario says 'restrict' or 'eliminate' public access. Service endpoints route traffic over the Microsoft backbone but leave the public endpoint active. Private Endpoints remove the public endpoint entirely. The verb in the requirement is the answer key.
What This Pattern Tests
Network connectivity questions test whether you match the connectivity model to the topology requirement. Few connections need simple peering. Many connections need a central hub. On-premises connectivity needs VPN or dedicated links depending on bandwidth and latency requirements.
Decision Axis
Topology complexity and bandwidth requirements determine the connectivity approach.
Associated Traps
Decision Rules
Whether the selected architecture provides built-in transitive routing through a central inspection point for spoke-to-spoke flows, or merely establishes peering adjacency that a learner mistakenly assumes is transitive.
When on-premises-to-Azure connectivity requirements are bounded by modest bandwidth, no latency SLA, and an explicit cost constraint, Azure VPN Gateway is the right-sized choice; ExpressRoute's dedicated circuit capacity is justified only when bandwidth, latency, or uptime SLA requirements exceed the VPN Gateway operational envelope — none of which apply to a sub-100 Mbps batch workload.
Whether intra-VNet, multi-tier micro-segmentation is best satisfied by ASGs combined with NSG rules (correct: native, zero additional cost, no topology overhead) or by a higher-capability network management overlay such as Azure Virtual Network Manager (over-provisioning trap: introduces cross-subscription topology management where none is needed).
Whether Azure Virtual WAN with Secured Virtual Hub or Azure Virtual Network Manager connectivity configurations plus UDRs better satisfies a small-topology spoke-to-spoke inspection enforcement requirement when a cost constraint disqualifies over-provisioned managed WAN infrastructure.
Whether to use Azure Virtual WAN with a secured virtual hub (managed transitivity, premium per-GB pricing) or Azure Virtual Network Manager hub-and-spoke connectivity configuration with UDR-based routing through a hub-resident NVA (explicit routing, predictable flat cost) to satisfy the inspection choke-point and fixed budget constraints simultaneously.
Whether Azure Virtual WAN with a secured virtual hub — which natively enforces transitive routing and directs all spoke-to-spoke flows through the hub inspection tier — or Azure Virtual Network Manager connected groups — which achieve reachability at scale but delegate inspection-path enforcement to operator-managed UDR overlays — satisfies the unconditional requirement that inter-spoke traffic cannot bypass the central inspection point.
When encryption-in-transit is the dominant compliance constraint and bandwidth is moderate and predictable, the correct choice is the connectivity service that natively satisfies the encryption requirement via IPsec/IKEv2 rather than a premium private circuit that requires an additional encryption layer to achieve the same compliance outcome at significantly higher total cost.
Whether to express NSG allow-rules as explicit source/destination IP address prefixes per VM NIC or to bind VMs to Application Security Groups and write tier-to-tier rules against ASG names, where the IP-based approach satisfies the security control mechanically but scales to hundreds of rules requiring manual updates on every VM addition or IP change.
Domain Coverage
Difficulty Breakdown