Core networking infrastructure for Microsoft AZ-700 Azure Network Engineer: Concepts, Scenarios, and Study Priorities

 

Core networking infrastructure is the foundation of AZ-700 because almost every other domain depends on it. Hybrid connectivity still needs address planning and routes. Private endpoints still need DNS. Application delivery still depends on reachable, healthy backends. Security controls still depend on topology and traffic paths. The current Microsoft blueprint gives core networking infrastructure the largest individual weighting, 25–30%, and the scope includes IP addressing, virtual networks and subnets, DNS, peering, Virtual Network Manager, routing, NAT, monitoring, DDoS-related design, and network security posture.

The best way to study this domain is to stop treating each service as a separate feature and build a layered mental model. At minimum, every design should answer six questions: what addresses are used, how names resolve, which route is selected, which security policy applies, whether translation changes the flow, and what evidence proves the path is healthy. If those six questions are clear, many AZ-700 scenarios become easier even when the service names change.

Start with address architecture because every later decision inherits it

Azure virtual networks are defined by address spaces, and subnets divide those spaces into operational and security boundaries. Good address planning is not only about avoiding immediate overlap. It should preserve room for growth, support regional or organizational allocation, simplify route summarization where possible, and avoid collisions with on-premises, partner, or acquired networks.

Imagine an organization planning three Azure regions. A weak design assigns random /16 or /24 blocks as each team requests them. The network works until a new region, acquisition, or hybrid connection introduces overlap. A stronger design reserves larger non-overlapping blocks by region, then divides those blocks into hubs, workloads, gateways, management, private endpoints, and growth space. The exact prefix sizes depend on demand; the important skill is explaining the allocation logic.

For AZ-700, practice reading CIDR ranges well enough to recognize overlap and containment. You do not need to calculate every address manually, but you should understand that peering requires non-overlapping address spaces and that hybrid routing becomes much more complex when different environments reuse the same private ranges.

Subnets are more than address slices

Subnets create places where Azure services, route tables, NSGs, delegations, and platform requirements apply. Treat them as control boundaries. A three-tier application might separate web, application, and data tiers to support different security rules, routing, and service dependencies. A gateway requires its own designated subnet. Some managed services require subnet delegation. Private endpoints may be placed in dedicated or workload-aligned subnets depending on design.

Avoid two extremes. One giant subnet removes useful policy boundaries and makes growth harder. Excessive micro-segmentation can create operational complexity without meaningful risk reduction. The design should map to trust boundaries, service requirements, and management needs.

A useful scenario exercise is to redesign the same application for a small development environment and a regulated production environment. The development design may accept simpler segmentation. The production design may separate tiers, management, private endpoints, and shared services more deliberately. The difference should be driven by risk and operations, not by a rule that every workload needs its own subnet.

VNet peering creates direct connectivity, not automatic transit architecture

Virtual network peering is one of the simplest ways to connect Azure VNets with private IP connectivity over Microsoft’s backbone. The common mistake is to assume that once spokes are peered to a hub, every network can automatically route through every other network. Peering relationships are explicit, and transit scenarios require deliberate design.

In a hub-and-spoke model, the hub can host shared services such as firewalls, DNS components, VPN or ExpressRoute gateways, and management tooling. Spokes isolate workload networks. But you still need to decide how spoke-to-spoke traffic flows, whether it must pass through a security appliance, whether gateway transit is used, and how route tables support the path.

Practice tracing the forward and return path. If a spoke sends traffic to a firewall in the hub and the firewall forwards to another spoke, what route brings the response back through the same stateful appliance? If the return path bypasses it, sessions can fail. This is why hub-and-spoke knowledge must include routing, not just peering diagrams.

Virtual Network Manager changes the scale of connectivity administration

When an organization has many VNets across subscriptions or regions, manual peering and security management can become difficult to operate consistently. Azure Virtual Network Manager provides centralized network-management capabilities that can help define connectivity configurations and security administration across network groups.

The AZ-700 study priority is not memorizing the interface. Understand the operating problem. If new VNets are created frequently, a centralized grouping and connectivity model can reduce repetitive configuration. If security administration needs consistent rules across broad scope, centralized management may reduce drift.

Still, centralized management does not eliminate architecture decisions. You must define group membership, intended topology, rollout scope, exceptions, and change control. In exam scenarios, look for requirements around scale, consistency, and reduced management effort rather than assuming Virtual Network Manager is appropriate merely because several VNets exist.

Routing begins with the destination prefix

Azure routing questions are easier when you follow a fixed sequence. Identify the destination IP. List candidate routes that match it. Find the most specific prefix. Then consider route-source behavior, propagation, and any relevant override or platform rule. This approach is more reliable than trying to memorize a large table without context.

System routes provide baseline behavior for a VNet. User-defined routes allow you to steer traffic toward next hops such as virtual appliances or other supported targets. BGP-learned routes can enter through hybrid connectivity. The effective route table on a network interface shows the result Azure is actually using.

A practical study exercise is to create a default route to a firewall or NVA and then add a more specific route for a particular network. Predict which route wins. Add a learned route from a simulated or real hybrid connection. Change one prefix at a time. The goal is to build intuition for route selection rather than memorize one example.

Forced tunneling is a policy decision with availability consequences

Forced tunneling typically redirects internet-bound or selected traffic through a central inspection point rather than allowing direct egress. It can support security and compliance requirements, but it introduces dependencies. If the appliance or path is unavailable, outbound connectivity may fail. If routes are incomplete, traffic may bypass inspection or become asymmetric.

For AZ-700, ask why the organization wants forced tunneling. Is centralized inspection mandatory? Does the NVA support the traffic scale? How is high availability implemented? What is the return path? How are platform services or management traffic handled? A route table alone is not the architecture.

A good lab is to point a subnet’s default route to a forwarding appliance, confirm the path, then disable forwarding or break the return route. The resulting failure makes the dependency memorable.

Route Server is useful when dynamic routing to network appliances is the requirement

Azure Route Server enables dynamic route exchange with supported network virtual appliances using BGP. Its value appears when maintaining large sets of static UDRs between appliances and Azure becomes operationally difficult.

Do not reduce the feature to “BGP for Azure.” Ask what problem it solves. If a hub contains third-party appliances that learn and advertise routes dynamically, Route Server can simplify exchange. If the environment has a small fixed set of routes, static UDRs may remain sufficient.

Readiness means understanding the relationship between dynamic route exchange, hub architecture, and appliance capabilities. You should also be able to explain that introducing BGP does not remove the need to reason about route preference, propagation, high availability, and asymmetric paths.

NAT Gateway gives subnets a deliberate outbound identity

Outbound connectivity is easy to ignore until a partner needs source-IP allow listing or an application creates enough outbound connections to stress SNAT resources. NAT Gateway provides managed outbound network address translation for associated subnets, using configured public IP addresses or prefixes.

The key design concept is separation of outbound and inbound behavior. NAT Gateway provides scalable outbound connectivity and predictable egress addresses; it does not publish an inbound application endpoint. That makes it useful for private workloads that need internet egress without direct inbound exposure.

Study how NAT Gateway interacts conceptually with other egress designs. A firewall can also provide outbound translation as part of centralized inspection. A load balancer may provide outbound behavior for backends. The best choice depends on whether the requirement is simple subnet egress, centralized security policy, or application publication.

Also understand SNAT as a finite translation resource. You do not need to memorize every current limit, but intermittent outbound failures under high connection volume should make you consider port exhaustion and egress architecture.

DNS is the control plane for names, and names often decide the network path

Azure DNS public zones host internet-visible DNS records. Azure Private DNS zones provide private name resolution to linked virtual networks. Custom DNS servers can be configured for VNets, and Azure DNS Private Resolver provides managed inbound and outbound resolution capabilities for hybrid scenarios.

The critical study skill is tracing a query. A client uses a configured resolver. That resolver may answer directly, forward the request, or rely on Azure-provided DNS. Private-zone links determine visibility. Conditional forwarding can direct specific namespaces. The returned address then becomes the input to routing.

This is why DNS is not separate from connectivity. If a private endpoint exists but the service FQDN resolves to a public address, the client may not use the private path. If on-premises DNS cannot resolve an Azure private zone, hybrid connectivity alone is insufficient.

Private Resolver reduces the need for custom DNS forwarding appliances in many hybrid designs

Azure DNS Private Resolver can provide inbound endpoints for queries entering Azure and outbound endpoints plus forwarding rules for queries Azure needs to send elsewhere. This can simplify hybrid name-resolution designs that would otherwise depend on custom DNS forwarder VMs.

The exam decision is usually operational. Does the organization need managed DNS forwarding between on-premises and Azure private namespaces? Are custom servers an unnecessary management burden? Which VNets and rulesets should participate? What is the query direction?

Practice with diagrams even if you do not deploy the service. Draw on-premises clients resolving a private Azure service name. Then draw Azure workloads resolving an on-premises internal name. Those are opposite query directions and may use different resolver endpoints or rules.

Private endpoint DNS is a must-know dependency

Private Link allows supported services to be accessed through private endpoints, each represented by a network interface and private IP address in a VNet. But applications normally use service FQDNs, not hardcoded private IPs. Therefore DNS must map the normal service name to the private address for clients that should use the private endpoint.

A common failure sequence is: private endpoint created, public access restricted or disabled, DNS left unchanged, client still resolves the public endpoint, connection fails. Another is that Azure clients work because their VNet is linked to the private zone while on-premises clients fail because their DNS path does not know about the zone.

For AZ-700, be able to explain the full chain: service FQDN, private DNS zone, VNet link, hybrid forwarding where necessary, returned private address, route, security policy, and service authorization. The AZ-700 practical preparation guide includes a lab pattern that deliberately breaks this chain so you can practice diagnosis.

Public DNS design still matters in global application delivery

Public DNS determines how clients find public endpoints and can participate in global distribution through services such as Traffic Manager. The key distinction is whether the service makes a DNS-level decision or proxies application traffic.

Traffic Manager responds to DNS queries with an endpoint choice based on its routing method and endpoint health; the client then connects to that endpoint. Front Door, by contrast, is an application-delivery proxy at Microsoft’s global edge. This difference affects caching, TLS, request processing, failover behavior, and visibility.

Even in a core-infrastructure study article, you should understand that DNS can be part of application delivery, not just a record-hosting service.

Monitoring should start with the question you need answered

Network Watcher and Azure Monitor for Networks provide capabilities for topology, connection diagnosis, route visibility, flow analysis, and network health. The mistake is learning tool names without mapping them to operational questions.

When a connection fails, use a layered diagnostic model. First, does the name resolve to the expected address? Second, does the source have a route to that address? Third, do network security controls permit the traffic? Fourth, is the destination listening or healthy? Fifth, are there platform-specific access controls?

Effective routes answer the routing question. Effective security rules answer the NSG question. Connection troubleshooting can help evaluate reachability. Flow logs can support traffic analysis. Topology and network monitoring provide broader context.

A candidate who starts from the question will choose diagnostic evidence more accurately than one who clicks through every available tool.

Flow logs are evidence, not policy

Flow logs and related telemetry can show communication patterns, denied or allowed flows, and network behavior useful for troubleshooting or security analysis. They do not themselves block traffic. This distinction matters because exam questions can mix monitoring and enforcement options.

Use flow evidence to validate whether traffic is occurring as designed, identify unexpected communication, or support investigation. Then change policy in the appropriate control: NSGs, firewall rules, routes, application access, or other services.

In study notes, label every service as primarily enforcement, routing, translation, delivery, resolution, or monitoring. Many wrong options become easier to eliminate when the control function is clear.

DDoS design belongs to exposure architecture

Distributed denial-of-service protection matters for internet-facing resources where volumetric or protocol attacks can exhaust capacity or availability. It is not a substitute for WAF, firewalling, or application security. Those controls operate at different layers.

For core infrastructure study, think about which public IP resources are exposed, which workloads are business-critical, and whether the organization’s risk justifies enhanced DDoS protection. Then connect the design to monitoring and incident response. Avoid the mistake of adding DDoS protection to a purely private service or using it as an answer to an application-layer injection problem.

The broader lesson is to classify the attack before selecting the control.

Network security recommendations should be prioritized by attack path

Defender for Cloud and exposure-management concepts can highlight network findings such as unnecessary public exposure or risky configurations. A large environment may have many recommendations. The architect’s job is to prioritize the ones that contribute to plausible attack paths toward important assets.

Suppose a public VM has an exposed management port, a vulnerable service, and a highly privileged managed identity. That combination creates a much more serious path than an isolated low-value finding elsewhere. Remediation can break the chain at several points: reduce exposure, patch the workload, narrow permissions, segment the network, or improve monitoring.

This attack-path lens helps connect infrastructure configuration to security outcome, which is increasingly important in modern Azure design.

Scenario 1: multi-region hub-and-spoke with centralized inspection

A company runs workloads in two Azure regions and requires all internet egress from production spokes to pass through centralized firewalls. Each region has a hub and several spokes. On-premises connectivity reaches the hubs.

Begin with non-overlapping regional address blocks. Peer spokes to their regional hub. Use UDRs to direct default or selected traffic to the firewall. Ensure the firewall can forward and that return paths remain symmetric. Decide whether inter-region traffic traverses connected hubs, another transit architecture, or a managed service such as Virtual WAN. Configure DNS so shared and private services resolve correctly across the topology.

The design should include high availability for firewalls and gateways, route monitoring, and a failure plan. “Hub-and-spoke” is not the answer; the answer is the set of routes, controls, and dependencies that make the topology work.

Scenario 2: hybrid access to a private platform service

An on-premises application must access an Azure Storage account without using the public endpoint. The organization already has private hybrid connectivity.

Create a private endpoint for the storage service in an appropriate Azure VNet. Configure the relevant private DNS zone. Provide a DNS resolution path from on-premises to that private namespace, potentially using Azure DNS Private Resolver or a managed/custom forwarding design. Confirm that the service FQDN resolves to the private IP from on-premises. Ensure routing reaches the private endpoint and that security controls and service authorization permit the connection.

This scenario demonstrates why “we have ExpressRoute” or “we have VPN” is not enough. Connectivity, DNS, private access, and authorization all need to align.

Scenario 3: predictable outbound IPs for private workloads

A company runs backend workloads with no inbound internet requirement, but a third-party API accepts traffic only from allow-listed public IP addresses. The backend makes many outbound connections.

Place the workloads in a private subnet and associate a NAT Gateway with a controlled public IP or prefix. The workloads receive managed outbound translation without requiring their own public IPs. Monitor connection behavior and understand SNAT scale considerations.

If the organization already mandates centralized firewall egress, compare the NAT design with using the firewall as the outbound path. The security and management requirement decides which architecture is more appropriate.

Study priorities: what to master first

Start with address spaces, subnet design, peering, and route selection. Without them, every later domain is harder. Next, master DNS, especially private zones and hybrid resolution. Then study outbound connectivity and NAT. Add Virtual Network Manager and Route Server as operating-model and dynamic-routing capabilities. Finally, tie the domain together with monitoring, DDoS concepts, and security posture.

At each stage, use scenario questions and small labs. The AZ-700 readiness matrix can help you decide whether a concept is recognition-level or exam-ready. A Level 3 skill means you can predict behavior, validate it with evidence, and troubleshoot a deliberate failure.

Use AZ-700 practice questions only after building the mental model. For every miss, identify whether the failure was address planning, routing, DNS, NAT, monitoring, security, or reading. Then reproduce the concept in a small exercise.

Prefix allocation should anticipate platform growth, not only today’s hosts

A prefix can look comfortably large when you count today’s virtual machines and still become a poor design because Azure networking consumes space in ways that differ from a flat on-premises VLAN. Managed services can require dedicated subnets, delegated subnets may be reserved for a particular service, gateways have their own placement requirements, and private endpoints can accumulate as teams move platform services behind private access. Growth also arrives through regions, subscriptions, acquisitions, disaster-recovery environments, and new application tiers.

For that reason, practice allocating from the top down. Begin with an enterprise or regional block, reserve room for future networks, then carve VNets and subnets according to workload and platform needs. The exercise is not to memorize a perfect prefix size. It is to defend why the plan reduces overlap risk and leaves operational room. If a scenario says that dozens of application teams will create new networks every quarter, a design that consumes every available range on day one should look suspicious even if it technically works now.

Bring-your-own-IP and public IP prefixes introduce a related planning idea on the public side: address identity can be an architectural dependency. Organizations may need predictable public ranges for partner allow lists, migration continuity, reputation management, or large-scale outbound and inbound designs. The exam-relevant skill is recognizing when address ownership or contiguous public allocation is part of the requirement rather than assuming that any dynamically assigned public address is equivalent.

Subnet delegation is a contract with a managed service

Subnet delegation is easy to memorize as a configuration checkbox, but it is better understood as an explicit relationship between a subnet and an Azure service. A delegated service may receive permissions or expect subnet characteristics that ordinary IaaS workloads do not. This affects placement, policy, and future reuse.

When you see a scenario involving a managed service that integrates into a VNet, ask whether the service requires or supports delegation, whether the subnet can host unrelated workloads, how many addresses the service can consume, and which NSG or route behaviors remain under your control. A common design mistake is to place everything into a shared subnet first and discover later that a managed service needs a dedicated delegated range.

A strong preparation exercise is to compare three cases: an ordinary VM subnet, a subnet delegated to a managed platform service, and a subnet containing private endpoints. Write down who owns the workload interface, which network controls you manage, how DNS behaves, and whether the subnet is intended for mixed use. That comparison prevents several Azure networking concepts from collapsing into the vague idea of “service inside my VNet.”

Effective routes and effective security rules are the fastest reality checks

Architecture diagrams show intent. Effective routes and effective security rules show what a particular network interface actually experiences after Azure combines system behavior, user configuration, propagation, and policy. That makes them essential troubleshooting evidence.

Suppose a workload cannot reach an on-premises prefix. The diagram says the subnet has a route table pointing to a hub firewall, and the hub has a gateway. Instead of changing routes immediately, inspect the effective route for the destination. You may discover a more specific learned route, disabled propagation, an incorrect next hop, or no matching route at all. Then inspect effective security behavior rather than assuming an NSG is irrelevant simply because its visible rule list seems permissive.

This evidence-first habit is valuable on AZ-700 because many scenarios contain several plausible causes. A candidate who asks “what is Azure actually applying to this interface?” is less likely to chase an unrelated service. It also mirrors production engineering: validate the control plane result before inventing a new architecture.

Network Watcher troubleshooting should follow a hypothesis

Network Watcher features are most useful when paired with a precise question. “The network is broken” is not a useful hypothesis. “The source has no effective route to 10.40.8.12,” “the NSG denies TCP 443,” or “the destination resolves to the public address instead of the private endpoint” are testable hypotheses.

Build a repeatable diagnostic sequence. Resolve the name and record the IP. Check the effective route toward that IP. Check security rules on the source and destination path. Validate whether the expected next hop is reachable and forwarding. Test the connection. If the path crosses a gateway or NVA, inspect both directions. If a load balancer or application gateway is involved, verify backend health separately from basic IP reachability.

This sequence matters because network symptoms can be misleading. A timeout might be routing, filtering, a dead backend, asymmetric return traffic, or name resolution to the wrong endpoint. The symptom alone does not tell you the layer. Good AZ-700 reasoning narrows the layer with evidence.

Virtual Network Manager needs deployment discipline

Centralized connectivity configuration can remove large amounts of repetitive peering work, but the blast radius of mistakes grows with centralization. That is why a mature Virtual Network Manager design includes network-group logic, staged deployment, regional or environment boundaries, exception handling, and validation.

Imagine a global enterprise that groups VNets dynamically by subscription or tags. A new rule can automatically bring a newly created VNet into a connectivity topology, which is operationally powerful. The same automation can also connect a network to places it should not reach if membership criteria are too broad. Study centralized networking as both a consistency benefit and a governance responsibility.

A useful exam pattern is to distinguish “we need to connect two VNets” from “we need to enforce a repeatable topology across hundreds of VNets that change over time.” The former may need ordinary peering. The latter creates the scale and drift problem that centralized network management is designed to address.

A compact path-analysis method for scenario questions

When a long question describes several networking services, reduce it to a path table before selecting an answer. Record the source, destination name, resolved address, longest-prefix route, next hop, translation point, security controls, and return path. Then add the business constraint: cost, latency, private connectivity, centralized inspection, operational scale, or availability.

For example, a spoke VM must reach a private database service while all internet traffic is inspected centrally. The database FQDN should resolve to a private endpoint address. The route to that private address should remain private and should not be confused with the default route used for internet egress. NSG and service authorization still apply. The firewall requirement for internet traffic does not automatically mean private platform-service traffic must hairpin through it.

This method prevents one requirement from swallowing the entire design. AZ-700 questions often test whether you can satisfy multiple constraints without applying a single service everywhere.

Final perspective: core networking is the ability to explain the path

The heart of AZ-700 core networking infrastructure is not resource creation. It is being able to explain why traffic follows a path and what controls or dependencies influence it. Addressing defines where networks can connect. DNS turns names into destinations. Routes choose next hops. NAT changes source identity for egress. Security policy permits or blocks flows. Monitoring provides evidence.

When you can predict all of those layers for a new scenario, the larger AZ-700 architecture becomes much easier. Hybrid connectivity and application delivery add new components, but they still rely on the same fundamentals. Study the foundation deeply enough that you can reason from source to destination—and back again—without treating Azure networking as a collection of unrelated service names.