AZ-700 notes: the path, the name, and the filter

Domain 1: IP addressing and name resolution

Start with an address plan that includes Azure, branch offices, VPN clients, partner networks, and future regions. Overlapping spaces prevent ordinary VNet peering and complicate hybrid routing. Reserve room for growth before dividing the VNet into workload and service subnets. Subnet delegation gives a supported service permission to manage resources in a subnet; it does not replace routes or security rules.

For an ordinary Azure IPv4 subnet, five addresses are reserved. A /27 contains 32 addresses and leaves 27 assignable addresses, before accounting for the resources your service needs. A design requiring 30 workload addresses cannot fit in that /27. Managed services can impose additional subnet size and dedicated-subnet requirements. Check those requirements before choosing a prefix simply from the VM count.

A public IP prefix reserves a contiguous set of Azure public addresses for predictable allocation. A custom IP prefix, or BYOIP, imports an eligible range you own. These are different requirements: a supplier asking for a stable outbound allowlist does not necessarily require BYOIP. Decide whether outbound identity belongs to each resource or to a shared egress service.

Trace the DNS query separately from the packet

Azure-provided DNS, custom DNS servers, public DNS zones, and private DNS zones serve different roles. A private zone link makes records available through Azure DNS in the linked VNet. Peering alone does not share zone links. A client using a custom DNS server follows that server's forwarding configuration, so creating a zone link does not automatically fix every client.

With Azure DNS Private Resolver, an inbound endpoint receives queries from on-premises DNS over a reachable private network path. An outbound endpoint and forwarding ruleset send queries for selected domains to another DNS server. Link the ruleset to the VNets that need it. Avoid rules that forward the same namespace back and forth in a loop. Record the actual resolver, returned address, and TTL when troubleshooting.

Study evidence: draw two arrows for a private application—one for its DNS query and one for its TCP connection. Label every resolver, route, and filter. If a diagram has only one arrow, it is probably hiding a dependency.

References: VNet addressing FAQ and Private Resolver overview.

VNet connectivity, route selection, and outbound access

VNet peering connects two networks but is not automatically transitive. If A peers with B and B peers with C, A does not gain a general path to C. Gateway transit requires the hub to allow gateway transit and the spoke to use the remote gateway, subject to gateway and peering constraints. For appliance transit, configure forwarding and routes for both directions. On an NVA, Azure NIC IP forwarding and the guest operating system's forwarding settings are separate checks.

Longest prefix first, route source second

Azure selects the longest matching prefix. For equal prefixes, the usual source order is user-defined route, BGP route, then system route. Special platform routes have exceptions, including service endpoint routes; inspect effective routes rather than treating the source order as universal.

A default route to a firewall therefore does not capture every more-specific peering route. Check the source subnet's route-table association and the destination's return path before declaring an inspection design complete. Azure Route Server exchanges BGP routes with NVAs; it is a routing control service, not an appliance through which application packets pass.

NAT Gateway provides outbound SNAT. For new internet connections from an associated subnet, it takes precedence over Load Balancer outbound rules and instance-level public IPs. A UDR directing traffic to an NVA or virtual network gateway changes that path and can override direct NAT Gateway egress. Existing connections may continue on their previous translation until closed. Test a new connection and the effective route before removing a public IP based on a stale observation.

References: Azure route selection, NAT Gateway FAQ, and outbound connectivity design.

Choose evidence that matches the failure

A successful DNS lookup, an allowed NSG decision, and a healthy application are different observations. Network Watcher IP flow verify evaluates a specified flow against applicable security rules. Next hop and effective routes explain routing. Connection troubleshoot investigates reachability. Packet capture helps investigate packets at a VM. Connection Monitor tracks connectivity over time. An allowed security rule does not prove that a service is listening.

Use Azure Monitor for trends and alerts. DDoS protection addresses network attack exposure; application-layer defenses need their own design. Defender for Cloud Secure Score, attack path analysis, and Cloud Security Explorer help prioritize exposed resources and connected risks. A recommendation is a starting point for investigation: record the affected resource, actual reachability, business need, and proposed change.

Reference: network monitoring and observability.

Domain 2: Site-to-site and point-to-site VPN

Site-to-site VPN connects networks through IPsec. The Azure virtual network gateway is the Azure endpoint; the local network gateway represents the remote gateway and its prefixes. Choose a gateway SKU and tunnel configuration that meet throughput, availability, and device requirements. Match the shared secret, IKE/IPsec parameters, and negotiated traffic selectors where applicable. A connected tunnel does not prove that every subnet has a usable route.

For a tunnel that is up but carries no application traffic, compare advertised or configured prefixes with effective routes, security filters, and return routes. With BGP, inspect the learned routes as well as session status. For resilience, distinguish multiple tunnels from independent customer devices and independent Azure gateway instances; two paths through one failing customer appliance do not remove that appliance as a failure point.

Point-to-site VPN connects individual clients. Match authentication, protocol, and client support together. Microsoft Entra ID authentication requires OpenVPN and the Azure VPN Client. Check supported client operating systems before planning deployment. Certificates and RADIUS have different prerequisites. When authentication settings change, redistribute an appropriate client profile and confirm tenant, audience, and issuer settings rather than repeatedly importing the same stale profile.

Separate failures before and after connection. Authentication errors point toward identity, certificates, client compatibility, or policy. A connected client that cannot reach a named application needs route and DNS checks. Always On VPN, Azure Network Adapter, and Azure Extended Network should be reviewed against their specific supported scenarios when named in the objective or requirement.

Reference: Entra ID VPN client requirements.

ExpressRoute: separate circuit, routing, and encryption

An ExpressRoute design includes a provider or Direct connectivity model, circuit bandwidth and tier, peering, VNet connectivity, and resilience. Azure private peering reaches VNet networks. Microsoft peering reaches supported Microsoft public services. For Microsoft 365, authorization and the appropriate route filter are required; enabling peering alone does not grant access or automatically advertise all desired services on a new circuit.

FastPath improves eligible data paths by bypassing the ExpressRoute gateway for that traffic. The gateway is still required for route exchange. Verify the current gateway SKU, circuit type, and supported destination features instead of assuming that every path uses FastPath. Global Reach connects on-premises networks through ExpressRoute circuits; it is a different requirement from improving the path to Azure workloads.

ExpressRoute is not encrypted by default. MACsec on ExpressRoute Direct protects the physical connection between your equipment and Microsoft's edge. It does not mean all traffic is encrypted end to end to a workload. IPsec can protect an end-to-end network connection over ExpressRoute. Identify the encryption boundary before selecting a solution, and account for throughput and operational constraints.

A circuit's redundant connections do not by themselves protect against loss of an entire peering location. Plan independent connectivity locations and validate failover. BFD can detect supported adjacency failures quickly, but recovery still depends on alternate routes and working infrastructure. Diagnose provider provisioning, BGP peering, route advertisements, gateway configuration, and workload access as separate layers.

References: Microsoft peering route filters, FastPath requirements, and encryption boundaries.

Virtual WAN and hub routing

Virtual WAN provides managed regional hubs and connectivity services. Identify the required connection types and inter-hub behavior before selecting a SKU. A managed virtual hub is not an ordinary VNet into which any VM appliance can be placed. Third-party NVA integration depends on supported partner offerings and deployment models.

A connection's route-table association determines which table it uses for forwarding. Route propagation determines which tables receive routes from that connection. These are distinct controls: publishing a route does not automatically make every other connection consult the table that contains it. When a branch can reach one spoke but not another, compare associations, propagation, effective routes, and the return path.

For secured hubs, understand routing intent and the selected security service. Do not copy a manually peered hub's UDR recipe into Virtual WAN without checking how managed hub routing works. In a design exercise, list each source and destination pair—branch to spoke, spoke to spoke, and internet egress—and explain whether the chosen policy sends it through inspection.

Reference: virtual hub routing.

Domain 3: Load Balancer and Traffic Manager

Azure Load Balancer distributes TCP and UDP flows at layer 4. Start with public versus internal frontend and the required regional or cross-region design. Connect the frontend, backend pool, health probe, and load-balancing rule. Inbound NAT rules target specific backend instances; an outbound rule is a different configuration. A healthy inbound application does not prove that its outbound SNAT capacity is adequate.

Check probe reachability independently of client reachability. For Azure Load Balancer, preserve the required AzureLoadBalancer probe traffic in your security design. A backend might respond to a direct test yet fail its configured probe because the probe uses a different port or protocol. Gateway Load Balancer serves a different purpose: inserting compatible network appliances while preserving the intended flow through them.

Traffic Manager answers DNS queries according to its routing method and endpoint health. It is not an HTTP reverse proxy and does not carry the application connection. Cached answers can delay the effect of a failover, and existing connections are not moved to another server just because a DNS response changes. Choose it when DNS-level steering fits the requirement; choose a proxy when the requirement includes request inspection or TLS termination at the entry point.

References: Load Balancer probes and Traffic Manager behavior.

Application Gateway: follow the HTTP request

For AZ-700 HTTP delivery scenarios, Application Gateway supplies regional host/path routing, TLS handling, and optional WAF. Trace the listener to the routing rule, backend pool, backend setting, and health probe. Autoscale capacity settings affect readiness for demand; they do not repair a wrong hostname or an unreachable backend.

A working browser request to a backend IP is insufficient evidence that the gateway's HTTPS probe will work. Compare protocol, port, path, Host header, TLS server name, certificate validity, and trust chain. A backend serving only a particular hostname may reject a default probe. Configure a custom probe for a meaningful health path and associate it with the correct backend setting.

When all backends are unhealthy, investigate the backend health details before changing unrelated listeners. If probes are healthy but requests fail, compare the actual request's routing rule and backend host settings with the probe configuration. End-to-end TLS involves separate client-to-gateway and gateway-to-backend sessions. Preserve certificate validation rather than disabling it as a permanent response to a name mismatch.

References: backend health troubleshooting and HTTP 502 diagnosis.

Front Door: global delivery and private origins

Azure Front Door provides a global HTTP(S) entry point with routes, origin groups, health probes, TLS, caching, and rules. Select a tier from the required features. Front Door Premium supports Private Link to supported origins and managed WAF rule sets. Standard supports custom WAF rules but does not provide that same managed-rule capability.

Private Link protects the Front Door-to-origin connection; it does not make the public Front Door endpoint private to clients. Configure the supported origin and approve its private endpoint connection. Check the origin host header, TLS certificate, and health probe before switching production traffic. An approved connection is necessary but does not prove that the application accepts the request.

Apply caching deliberately. Static versioned assets and personalized account pages have different requirements. Avoid caching authenticated or user-specific responses in a way that can serve one user's data to another. Decide query-string handling and cache rules from the application contract. A URL rewrite changes the request sent onward, while a redirect asks the client to make another request; this distinction matters for signed URLs, application routes, and search behavior.

References: Front Door Private Link and Front Door WAF tiers.

Domain 4: Private endpoints and hybrid DNS

A private endpoint creates a private IP connection to a supported service resource and subresource. Check the connection's approval state and target, then test the service's normal hostname from each client location. Some services use multiple subresources; for example, a storage design may need separate consideration of blob and DFS endpoints. Do not assume that one endpoint covers every operation on the resource.

For on-premises clients, provide network reachability to the endpoint and a DNS path through Azure DNS Private Resolver or an appropriate Azure DNS forwarder. For Azure SQL, the recommended conditional forwarding namespace is the public service zone database.windows.net, resolved through Azure; the private zone is privatelink.database.windows.net. Forwarding only the private zone can miss the initial public-name query. Use the service-specific recommended namespace.

Creating a private endpoint does not automatically disable public network access, and disabling public access does not necessarily remove public DNS records. A public DNS answer therefore does not prove that a data request succeeded. Validate the allowed private request, the blocked public request, and the requesting identity's data permissions separately.

Private Link service publishes your own supported service behind a Standard Load Balancer for consumers to connect through private endpoints. The provider's service and the consumer's endpoint are different resources. Record which side owns approval and troubleshooting.

References: Private Endpoint DNS integration and private endpoint concepts.

Service endpoints and Storage endpoint policies

A service endpoint identifies a subnet to a supported Azure service while the service retains its public endpoint address. Configure the endpoint on the subnet and the service's network access rules. This is different from giving the service a private IP. The phrase "Microsoft backbone" does not by itself mean "private endpoint."

Service endpoint policies apply to Azure Storage. They restrict the permitted Storage resources reachable through the service endpoint, reducing exfiltration to other accounts. They are not a generic allowlist for every PaaS service, and they do not grant permission to read or write data. Storage authentication and authorization remain necessary.

Choose from the requirement: a private IP and hybrid private access suggest Private Link; subnet identity with supported public service endpoints suggests service endpoints; restricting Storage destinations through that endpoint suggests a service endpoint policy. For a migration, test both the new intended path and the old path that should become unavailable.

Reference: Storage service endpoint policies.

Domain 5: NSGs, security admin rules, and flow logs

NSGs filter flows by direction, protocol, source, destination, and port. Lower priority numbers are evaluated first. When both subnet and NIC NSGs apply, traffic must pass both. Application security groups organize workload interfaces for rules; service tags represent Microsoft-maintained address groups. Neither is an FQDN application policy.

NSGs are stateful. Return traffic for an allowed connection is handled through flow state. Changing a rule does not necessarily terminate an already established session, so create a new connection to test a change. For administration, distinguish the actual management port and application purpose. Public TCP 443 might be an intended web application; it is not automatically a management exposure. Bastion can provide RDP/SSH without a public IP on the target VM.

Azure Virtual Network Manager security admin rules run before NSG rules where they apply. Allow continues to NSG evaluation; Always Allow bypasses subsequent NSG evaluation for the matching traffic; Deny terminates it. Confirm the configuration is deployed and the target is in scope. Some managed services and subnets have documented exceptions.

Use virtual network flow logs for new flow-logging designs. New NSG flow logs can no longer be created, and existing NSG flow logs retire on September 30, 2027. Plan migration and validate new records before disabling old logging. Flow records help explain network behavior but do not replace WAF, firewall, identity, or application logs.

References: NSG behavior, security admin actions, and flow-log migration.

Azure Firewall: routing and rule processing together

Azure Firewall supplies centralized network and application filtering. Firewall Manager helps govern policy across deployments. Select a SKU for the features actually required: Premium includes capabilities such as TLS inspection and IDPS. A policy cannot inspect a flow that routing sends around the firewall, so validate both forwarding directions before tuning rules.

For the ordinary rule collections, DNAT is processed before network rules, then application rules. A broad network allow for TCP 443 can terminate processing before a more restrictive application FQDN rule is reached. Giving the application collection a lower priority number does not reverse that rule-type order. Threat intelligence and IDPS have additional evaluation behavior; inspect the relevant logs when a flow is blocked despite a matching allow.

DNAT and SNAT change different address fields. Azure Firewall inbound DNAT also source-translates traffic for return-path handling, so a backend may observe the firewall address. Plan where original-client evidence is recorded instead of assuming the application sees the internet client's source directly. In a chain of proxies, trust forwarded identity headers only from the intended proxies.

References: Firewall rule processing and documented Firewall behavior.

WAF: tune application protection with evidence

WAF protects web requests at Application Gateway or Front Door. Choose the correct policy and association, rule set, custom rules, and mode. Detection is useful for observing matches before enforcement. Prevention enforces configured actions; not every matched rule means an unconditional block, because actions, exclusions, and rule evaluation affect the result.

For a legitimate request that is blocked, capture its correlation identifier, matched rule, request field, and application expectation. Prefer a narrowly scoped exclusion or justified rule adjustment after checking the request is safe. Retest that request and an attack-like request appropriate to an authorized test environment. Disabling the entire WAF to fix one false positive discards unrelated protections.

Keep control boundaries clear. WAF does not replace network routing, identity authorization, or filtering for arbitrary non-HTTP protocols. DDoS protection is not a promise that the application can handle unlimited legitimate demand. Write down which control addresses each requirement, then verify that the request actually traverses it.

Reference: Front Door WAF tuning.

Five guided labs with acceptance checks

These are learning exercises, not a record of deployments performed by Certicab. Use an isolated subscription or resource group with permitted test data. Estimate charges before creating gateways, resolvers, firewalls, or delivery services; a budget alert is not a spending cap. Record the resource names and delete chargeable resources after saving your observations. If you cannot provision a service, complete the diagram and expected-results worksheet first.

1. Prove why a default route misses a peered destination

Create two small, non-overlapping test VNets with test hosts and peering. Record the effective route to the remote host. On paper, add a default UDR to a hypothetical firewall and predict the result before changing anything. If an authorized lab appliance is available, configure the UDR and compare its logs with the effective route. Then add the destination-specific route and configure forwarding and a symmetric return path.

Acceptance check: explain which prefix wins at each stage and show evidence from the source NIC. The negative test is the initial peering route bypassing the default-only inspection design. Do not use a nonexistent next hop on a shared workload subnet; that creates a black hole, not a useful firewall test.

2. Validate private access from two client locations

Use a disposable Storage resource and an appropriate private endpoint. Integrate its private DNS zone, and test the normal service hostname from a linked Azure client. If a hybrid lab exists, repeat from an on-premises client through the configured DNS forwarder or resolver. Record the resolver and returned address in both cases. Use a test identity with only the required data permissions.

Acceptance check: authorized private requests succeed. After public access is disabled, a public-path request fails even if public DNS still returns an address. A private-path request from an identity without data permission should also fail. These three results distinguish DNS, network access, and authorization.

3. Diagnose a probe mismatch without weakening TLS

Place a test HTTP application behind Application Gateway and expose a known health path. Record the listener, backend setting, and probe association. In the isolated application, make the root path return a response outside the probe's accepted range while the health path remains healthy. Compare direct application access with backend health, then configure a probe that uses the intended host and health path.

Acceptance check: backend health recovers and normal requests succeed after the specific mismatch is corrected. For HTTPS, preserve certificate validation and record the hostname expected by the certificate. A successful request made with certificate checks disabled is not evidence that the gateway's TLS configuration is correct.

4. Observe a new NSG flow after a policy change

Start with a test service and a narrowly permitted source. Record the relevant subnet and NIC NSGs and their priorities. Change the isolated test rule to deny new traffic, then open a fresh connection from the same source. Compare this with any existing session, using timestamps to avoid confusing the two. Restore the intended rule after collecting the result.

Acceptance check: a new denied connection is consistent with the rule evaluation. Explain why an old connection may behave differently. Where available, inspect VNet flow logs for the test interval and compare with the service's logs rather than expecting one log source to explain every layer.

5. Write and test a hybrid failure matrix

For an existing authorized VPN or ExpressRoute lab, list customer device, circuit or tunnel, BGP session, learned route, gateway, and destination application as separate dependencies. Choose one reversible fault at a time, such as withdrawing a test prefix. Predict whether the tunnel remains up, which route disappears, and whether an alternate route exists before performing the change.

Acceptance check: record the failure symptom, the observation that identifies its layer, and the recovery evidence after restoring the prefix. If provisioning is impractical, use a tabletop version with a route table and topology diagram. Do not describe a theoretical failover as measured availability or throughput.

Turn each lab into a useful review note

Keep a small record with five fields: requirement, expected path, observed evidence, smallest corrective change, and retest result. Add one rejected alternative and explain why it fails the requirement. For example, changing an NSG does not fix a DNS server returning the wrong address, and replacing a regional gateway does not fix an unapproved private endpoint. This record is more useful than collecting screenshots without a hypothesis.

Frequently asked questions