Azure networking interview questions that test judgment

1. A private endpoint is approved, but the app still resolves a public IP. What do you check?

I would first run DNS resolution from the same network and runtime as the application, then compare the result with the endpoint's assigned private IP. I would verify the private DNS zone group, the zone's A record, the VNet link, and any custom DNS forwarder or conditional forwarding rule. An approved endpoint confirms the connection state; it does not prove that every client resolves its name privately.

If DNS returns the expected private address, I would move to routing, NSG/UDR, service firewall, and application authorization checks rather than changing DNS blindly.

2. Can two peered spokes communicate through a hub automatically?

No. VNet peering is non-transitive. I would identify whether traffic should traverse a firewall or another network virtual appliance, then design explicit routing and inspection. If direct spoke communication is required, I would compare direct peering, a routed hub design, and Virtual WAN against scale, governance, and operational requirements.

3. How would you troubleshoot a failed on-premises-to-Azure connection?

I would define the exact source and destination IPs, ports, protocol, and direction, then trace the path across the on-premises route, VPN or ExpressRoute, gateway, Azure effective routes, NSGs, firewall, and target listener. I would validate non-overlapping address spaces and return routing as well as the forward path.

I would use connection troubleshooting and flow or firewall logs to test the specific tuple. A healthy tunnel alone does not establish that routes, policy, DNS, and the destination are correct.

4. A workload needs private access to Storage from several VNets. Where do you place the private endpoint?

I would ask whether access is limited to one workload, shared across many spokes, or must be inspected centrally. A spoke endpoint can keep ownership close to one workload; a hub endpoint can suit shared access and inspection, subject to routing and DNS design. I would document the trade-off instead of treating one placement as universally correct.

The design must also link the correct private DNS zone to every client VNet that needs to resolve the service privately.

5. What is the difference between NSGs, UDRs, and Azure Firewall?

An NSG applies stateful allow/deny rules at a subnet or network interface. A user-defined route influences next-hop selection. Azure Firewall is a managed network security service that can provide centralized network and application filtering, logging, and egress control. They solve different parts of the path and may be combined.

I would describe the packet route first, then identify which control evaluates it at each hop and verify the effective route and rule logs.

6. How do you design outbound internet access for private workloads?

I would clarify whether outbound access is required, which destinations are allowed, whether inspection is required, and how source addresses must appear. Then I would choose an explicit egress design such as a firewall, NAT Gateway, or approved proxy based on control and scale needs. I would not assume that a private subnet automatically has the required outbound path.

The answer should include DNS, route tables, firewall policy, source NAT expectations, monitoring, and failure behavior.

7. How do you distinguish a DNS failure from a routing or firewall failure?

Resolve the target FQDN from the failing client first. If it maps to an unexpected address or returns NXDOMAIN, inspect private DNS records, VNet links, resolver rules, and forwarding. If it resolves correctly, test TCP reachability and inspect effective routes, NSGs, firewall logs, endpoint state, and the service's own network restrictions.

Keep the test anchored to the same FQDN, client network, port, and time as the failure; a test from an administrator laptop may follow a different path.

8. What would you monitor after a network change?

I would capture a baseline and monitor connection success, DNS failures, latency, drops, firewall denies, gateway health, and service-side errors. I would run synthetic tests from representative spokes and hybrid locations, not only check that resources show a green status in the portal.

For a risky rollout, use a staged change with an owner, expected signals, rollback trigger, and a saved record of effective routes and policy before and after.

A repeatable answer framework

For each scenario: clarify the requirement; sketch source, destination, DNS, and hops; state the expected route; name the security and identity controls; give a test that distinguishes likely causes; and mention a fallback or rollback. This shows operational reasoning without pretending there is one topology for every organization.

Frequently asked questions