Crafting with AZ-700: Designing and Implementing Microsoft Azure Networking Solutions
Designing an Azure network is not the same as selecting a list of Azure network services. The difficult part is predicting how a change to addressing, DNS, routing, filtering or application delivery affects a real workload—and proving that the implementation behaves as intended. The AZ-700 exam measures those choices for an Azure network engineer, but an operationally useful design has to survive maintenance, outages and the occasional configuration mistake as well.
Consider a business moving a customer portal to Azure while keeping a finance database on-premises. Employees connect from branches, customers reach the portal over HTTPS, and an application service needs private access to an Azure data store. The business wants predictable response times and a way to recover if the primary private circuit fails. Rather than start with product names, write down the flows that must work, the flows that must be refused, and the tests that will prove the difference.
Freeze the address plan and trust boundaries before configuring services
Begin by mapping source and destination networks, expected growth, and the teams that allocate address space. Avoid overlapping private ranges between branches, hub networks and application spokes; overlap can make peering and hybrid routing impractical long before resource limits become a concern. Reserve capacity for delegated subnets, gateways, private endpoints and any future expansion. A region or VNet name is not an addressing strategy.
Segment workloads according to trust and operating responsibilities, not merely application labels. A frontend, internal API and management interface may deserve separate subnets, but subnets alone do not constitute isolation. Document the expected security controls, route tables and DNS behavior at each boundary. When the same subnet serves a delegated platform service, validate that service’s networking requirements before adding arbitrary routes or policies.
The practical acceptance artifact is a source-to-destination matrix with protocol, port, authentication expectation, failure behavior and owner. For example, the web tier may reach the private database port, but a support workstation may not. A network diagram that cannot answer those questions is too high level for implementation or for AZ-700 scenario reasoning.
Make the hybrid path resilient instead of simply connected
A site-to-site VPN provides IPsec/IKE connectivity over the internet. ExpressRoute uses a provider-backed private connection, but a private route is not automatically encrypted, immune to outages or compliant with a particular law. Decide based on throughput, latency variability, provider locations, encryption requirements, recovery time, cost and who is responsible for the connection. Point-to-site VPN serves a different user-connectivity problem and is not a blanket substitute for branch connectivity.
For the finance database, record the intended primary path, the backup path, route advertisements and change authority. Check effective routes on both sides rather than assuming that a gateway object means the traffic can return. BGP advertisements, asymmetric paths, forced tunneling and user-defined routes can each produce a failure that looks like an application outage. Test failover with real connection flows and an agreed maximum interruption, not only by checking gateway status.
An organization with many branches may prefer Azure Virtual WAN over hand-built peering and individual transit hubs, but the operational model matters. Virtual WAN has routing and SKU decisions of its own; a classic hub-and-spoke design may still fit a smaller, tightly controlled estate. Choose an approach the team can explain and operate during an incident. The right answer depends on topology, not a claim that the managed option is always superior.
Trace name resolution, routing and filtering as one chain
Suppose the Azure application resolves the data-store hostname to a public IP even though a private endpoint has been deployed. The endpoint resource can be healthy while the request follows the wrong network path. Test the answer returned by each relevant DNS resolver, the private DNS zone link, forwarding from on-premises servers, and the client-side cache. Only then inspect effective routes, virtual appliances and network security rules. Treat DNS, routes and NSG troubleshooting as one flow-based investigation rather than three independent checklists.
Security groups are stateful filters applied at supported subnet or interface boundaries. An allow rule cannot grant access if an earlier matching rule blocks the connection, and an open port does not grant an application identity permission to read the data. Use effective-rule checks and IP flow verification to confirm filtering; use the service’s authorization and firewall settings to confirm the second boundary. A private address does not make a workload exempt from identity policy.
When several spokes require inspection through a hub firewall, trace the return path as carefully as the outbound path. A user-defined route that sends traffic to an appliance is only one half of a working inspection design. The appliance must be able to route back and the application must tolerate the path’s latency. Document what happens when the inspection service is unavailable instead of silently granting a bypass.
Select delivery services from the protocol and failure model
Azure Load Balancer distributes TCP or UDP traffic at the transport layer. Application Gateway understands HTTP(S), listeners and web application firewall patterns. Front Door handles global HTTP(S) entry, routing and edge features; Traffic Manager uses DNS-based endpoint selection. Those names are not interchangeable answers to “make it highly available.” First specify whether the client uses HTTP, what health checks actually detect, how state is managed, and whether global failover is required.
For the customer portal, a regional Application Gateway may protect and route web requests, while a global entry point becomes relevant if the service spans regions. A private internal API may instead need a regional internal load balancer. A CDN or WAF is not a replacement for backend health checks or application-level authorization. When Front Door is justified, test origin health, cached content, TLS configuration and the consequence of a region being withdrawn.
Define tests before deployment: block one unhealthy backend; deny one unauthorized path; expire one certificate in a test environment; simulate loss of a region or gateway. Check that alerts, client-facing errors and recovery procedures agree. A green portal dashboard is not enough if login succeeds while the payment flow fails.
Implement private service access without accidental public dependencies
A private endpoint exposes a supported service through a private IP inside a VNet. It is not the same as service endpoints, and neither should be treated as a universal replacement for the platform’s authentication controls. Confirm approval where required, DNS answers, subnet and policy configuration, and how users outside the VNet will resolve and reach the service. The practical subject of Azure private endpoints includes both name resolution and authorization boundaries.
Decide when to disable public access based on actual client migrations and fallback requirements. Disabling it early can strand a workload whose DNS or routing has not yet been adjusted. Leaving it enabled indefinitely may defeat the intended private-access policy. Record the rollout sequence, observation window and rollback switch with the service owner.
For every endpoint, prove a permitted client reaches the intended private address and an unauthorized client fails for the expected reason. A failed connection caused by broken DNS is not evidence of a well-designed security control. Conversely, a connection to a private IP is not proof that data-plane permissions are least privilege.
Use current logging and an explicit rollback plan
Azure Network Watcher supplies diagnostics such as effective routes, next hop, connection troubleshooting and IP flow verification. For new network flow capture, use virtual network flow logs rather than creating NSG flow logs: Microsoft stopped creation of new NSG flow logs after June 30, 2025 and schedules the legacy feature for retirement on September 30, 2027. Plan the log destination, retention, access and storage cost, then validate records for both allowed and denied test flows. Some traffic is outside an NSG’s observation scope, which is another reason to avoid assuming that “no NSG log” means “no traffic.”
A defensible network change record contains the previous configuration, intended effect, acceptance tests, actual observations, named approver and reversal steps. A DNS-zone or route-table change can appear small but break many applications at once. Roll out gradually when possible and measure what the users experience, not just whether Azure reports that the resource update succeeded.
The final AZ-700 exercise should therefore be one change review: explain the required flow, select the connectivity and delivery pattern, predict a failure, implement a minimum test, examine effective network evidence and decide whether to proceed or roll back. It is different from memorizing the service catalog, and it reflects the engineering responsibility behind the certification.
- Category: All Certifications Microsoft
