Microsoft AZ-700: Designing Hybrid and Private Azure Networking

AZ-700: Designing and Implementing Microsoft Azure Networking Solutions assesses engineers who build the network foundation for secure, reliable applications in Azure. Microsoft's July 27, 2026 skills outline spans IP addressing, virtual networks, hybrid connectivity, application delivery, private access and network security. This role goes beyond creating a subnet. It requires predicting what traffic path a workload will use, where failures can occur, how identities and security policies affect access, and how to prove that users reach the right service through the intended route.

Network engineers work with architects, administrators, developers and security teams because network decisions shape every connected workload. A private database endpoint is useful only when application DNS resolves it correctly; a gateway design is valid only when route propagation and resilience match the enterprise topology. Those principles apply whether the organization has one application or a large hybrid estate. The Azure Administrator AZ-104 skill set provides useful implementation context, but AZ-700 is particularly concerned with planning and managing the network path itself.

Model IP addressing, VNet segmentation and routing

A good Azure network design begins with address planning. Reserve nonoverlapping spaces for virtual networks, hybrid sites, future growth and specialized subnets. Existing on-premises ranges may constrain cloud design more than the address allocation available in a new subscription. Overlapping prefixes complicate routing and migration, especially when teams expect to connect networks through VPN or ExpressRoute. Document which ranges belong to which environment and who can approve future expansion.

A VNet can contain subnets for workloads with different trust or platform requirements. Some services need delegated or specially named subnets; others need private endpoints or gateways. Use network security groups to restrict flows and route tables to specify forwarding. Subnet boundaries alone do not enforce every requirement. For example, a VM might have a security rule permitting database access but still send traffic through an inspection appliance because a user-defined route takes precedence. Diagnose the effective path, not just the intended topology drawn in a diagram.

VNet peering, private connectivity and centralized hubs are useful patterns, but not all connections are automatically transitive. A peered spoke may reach the hub without automatically reaching a second spoke. Consider where firewalls, gateways and DNS forwarding sit when planning a shared connectivity service. Test each required path with actual ports and name resolution; a successful ICMP probe is incomplete evidence for a TLS-based application.

Design hybrid connectivity for resilience and cost

A site-to-site VPN offers encrypted connectivity over internet transport, while ExpressRoute uses private connectivity arrangements with different operational and commercial properties. The choice depends on throughput, latency, predictability, compliance, provider availability and how critical traffic behaves during failure. An organization may use a primary private connection with a tested VPN contingency, but the fallback route must be able to carry acceptable traffic and preserve relevant security controls.

ExpressRoute and VPN Gateway are not simply faster and slower versions of the same service. Their circuit dependencies, routing and operational responsibilities differ. Plan BGP advertisements, prefix filters, route preference and failure detection carefully. If a private circuit becomes unavailable, routes may converge while the remaining VPN link is too small for peak demand. A connectivity design succeeds when critical applications still meet tolerable behavior after the failure, not merely when a tunnel reports "connected."

Azure Virtual WAN and network connectivity constructs can simplify large hybrid estates when central policy, branching and scale justify them. Smaller environments might be better served by straightforward gateway and peering configurations. Review cross-region traffic charges, circuit fees and operational expertise, not only provisioning speed. An implementation that centralizes everything through one region may create unnecessary latency and a common failure point, so connectivity choices should be justified against the locations of users and data.

Select the right application delivery service

Network load balancing operates differently from HTTP-aware application delivery. An Azure Load Balancer handles traffic at transport layers and depends on correct backend health and reachability. Application Gateway and other HTTP-focused offerings can provide routing and application-layer controls. Global routing or content delivery may be appropriate where users are geographically distributed. Select based on protocol, TLS termination, path-based routing, client affinity and required protection. Azure load balancer choices are technical decisions with different failure modes.

A healthy endpoint must reflect application usefulness. A backend that responds to a simple probe while failing database transactions can continue receiving customer traffic. Define probes that accurately identify whether an instance should serve requests without creating expensive or fragile checks. Understand how source address, session persistence, TLS and client connections behave during failover. A system that drops long-lived connections during each deployment may need a different draining or application design rather than a larger network device.

Traffic distribution also involves security. A publicly reachable web application may require WAF rules and origin restrictions; a private internal API should not inherit that internet exposure by default. The network engineer must coordinate certificates, backend private connectivity and application identity. Endpoint success should be verified by a user journey, not only the platform's resource status display.

Implement private access and resolve DNS precisely

Private endpoints let clients connect to certain managed services through private addresses, while service endpoints and other connectivity options have different behaviors. A private endpoint does not automatically prevent access through every public path unless the service configuration is also restricted appropriately. The most common practical failure is name resolution: a client continues resolving a service's public address when the expected private DNS record or resolver path is missing. Private Link versus service endpoints clarifies the underlying distinction.

Hybrid name resolution can involve Azure DNS Private Resolver, DNS forwarders and on-premises authoritative servers. Map the query path from the actual client location, including split-horizon behavior and conditional forwarding. A VM in Azure may resolve a database correctly while an employee in a branch office does not. The fix may be DNS forwarding rather than a firewall rule. Test records and TTL changes with controlled tools and document the expected result for each network segment.

Network address translation can also affect access. A workload using a NAT Gateway has different outbound address behavior from one reaching a service through a firewall or proxy. Where third-party services use source IP allowlists, unexpected egress changes can break integrations. Plan stable outbound addresses where needed and track which team owns source-address changes. Security and network teams should share a current inventory rather than maintaining unrelated lists of "approved" endpoints.

Integrate network security without hiding routing problems

NSGs, Azure Firewall, web application firewalls and cloud-native protection solve different enforcement problems. Azure Firewall, NSGs and WAF helps illustrate where each fits, but the effective security posture depends on end-to-end policy placement. A flow can be denied by an NSG, routed into a central firewall, blocked at an application gateway or rejected by the application itself. Investigating the symptom requires knowing which layer made the decision.

Use logs, effective routes, network watcher diagnostics and application traces to narrow failures. During an outage, creating an allow-any security rule can make a connection work but introduce unacceptable exposure. Prefer a controlled test of exact source, destination, protocol and port, then verify that the required traffic succeeds. Remove temporary exceptions once a permanent, reviewed rule is deployed. Security design should state who owns the rule and why the service requires it.

Defend against lateral movement by reducing unnecessary reachability between workloads. An application subnet generally does not need administrative access to every database or management endpoint. Consider segmentation for production, testing and partner access, with explicit paths for monitoring and backup. Do not confuse network isolation with a substitute for identity controls: the application must still authorize the caller after traffic reaches the service.

Suppose a branch uses two hybrid connections to Azure and experiences intermittent latency after a routing-policy change. An engineer should identify the affected prefixes, compare effective routes and verify BGP advertisements in both directions. A healthy tunnel does not prove return traffic takes the expected route. Asymmetric paths may cause a stateful firewall to drop packets even though both endpoints are reachable. Troubleshoot one representative workload and destination before changing a global network policy.

Private database endpoints introduce another layer. When the client cannot connect, first confirm that the hostname resolves to the intended private address from the client network. Then check endpoint approval, network filters and the database's identity authorization. Resolving correctly does not grant a login; an authorization failure does not imply a routing fault. Recording the exact stage of failure prevents engineers from disabling a security control to solve a name-resolution mistake. Clear network documentation should trace DNS, routing, filtering and application identity independently.

Troubleshoot one path at a time and document the design

A realistic AZ-700 investigation begins with a client unable to reach a private database. Check DNS resolution, address prefix allocation, effective route, gateway status, NSG rules, firewall logs and service-side configuration in that order according to the evidence. Each observation should confirm or eliminate a hypothesis. Record the originating subnet and resolved address; identical application errors from two clients may conceal different network paths. Test from the actual affected location where possible.

For a resilience lab, build two networks, a shared connectivity path and a sample service. Measure normal reachability and latency. Withdraw one route or disable a test connection, then observe convergence and application behavior. Increase load on the backup path to see whether it can sustain critical transactions. A diagram that shows two links is not proof of resilience until failover works at expected traffic levels and security inspection remains correct.

Microsoft's live AZ-700 study guide defines current objectives and product focus. Prepare by implementing small networks, inspecting effective state and explaining design trade-offs. Network engineering expertise lies in making traffic paths deliberate, secure and observable so another engineer can understand their behavior during routine operations and an unexpected failure.