AZ-700: Network Security and Visibility

A secure Azure network is not simply a collection of restrictive rules. It is a system in which legitimate traffic follows intended paths, unauthorized traffic is blocked at appropriate boundaries and operators can explain what happened when something goes wrong. The AZ-700 exam dedicates 15–20% to network security services in Microsoft’s July 2026 blueprint, while monitoring and diagnostics also appear across the core networking domain. The engineer must understand protection and visibility together.

Consider a customer portal with a web edge, an application subnet and a managed data service. There may be a WAF at the edge, network security groups on application subnets, a central Azure Firewall for selected routes and private endpoints for backend data. None of those components is sufficient alone. The overall design depends on which traffic each control sees, how decisions interact and whether the monitoring system can identify both blocked attacks and legitimate outages.

Use network security groups at the right boundaries

Network security groups use security rules to allow or deny traffic for associated subnet or network-interface contexts. Rules consider direction, protocol, source, destination, ports and priority. A design should make policy intent legible: which systems may initiate connections to which services, and why? Hundreds of nearly identical individual IP rules can become difficult to review when resources scale or addresses change.

Application security groups help express certain policies in terms of logical workload groups rather than every virtual machine’s changing IP address. This can make rules easier to maintain when compatible network interfaces join or leave an application tier. The design still needs clear ownership and testing; an ASG label does not enforce least privilege unless its associated rules reflect the actual business requirement.

The difference between explicit and implicit denies matters when investigating a blocked flow. A deny may be the expected result of the policy rather than evidence of a misconfiguration. Effective security review asks whether the denied source should have access, not whether making the packet pass would turn the dashboard green.

Understand centralized security admin rules and precedence

Azure Virtual Network Manager can apply centrally managed security admin configurations to selected network groups, providing a layer of governance above individual workload teams. Central rules and local NSGs have distinct evaluation behavior. Engineers must use the documented precedence rules for each rule action instead of assuming that an allow at one layer overrides every other control.

This creates an organizational benefit and a risk. Central policy can help prevent accidental exposure of management access across a large estate. However, a change that is safe for one group of VNets may block essential traffic for another. The rollout plan should include scope review, representative tests and a way to confirm the effective rule decision on each affected path.

Policy drift is another concern. A workload owner may believe a subnet is protected by a standard NSG, while a mis-scoped deployment applies a different rule set. Auditors and operators should compare declared security intent against effective policy, actual flows and resource ownership. Documenting exception approvals is as important as documenting baseline rules.

Put Azure Firewall where it can enforce policy

Azure Firewall is a managed, stateful network security service that can control relevant network and application traffic according to configured policies. It supports different SKUs and capabilities, so selection should reflect inspection requirements, throughput expectations and operational needs. Azure Firewall Manager can help organize policies across supported deployments, including secured hub architectures.

A hub firewall does not automatically inspect every packet from every spoke. The route path must send the relevant traffic through it, and the return path must remain viable. A user-defined route or centralized design can redirect selected flows toward an inspection service, but the team must consider asymmetric routing, service dependencies and possible bypass paths. Architecture diagrams should show packet flow, not merely a firewall icon connected to several VNets.

Rule planning should use meaningful service identity and destination context where supported, not an ever-expanding list of broad exceptions. Firewall logs then become evidence of policy decisions: allowed, denied, or sometimes not observed because the flow took a different path. A solid understanding of firewall design principles helps connect Azure policy objects with broader goals of segmentation and controlled access.

WAF and DDoS protection solve different problems

A web application firewall examines HTTP and HTTPS requests to help mitigate supported application-layer threats. In Azure, WAF policies can be associated with relevant Application Gateway or Front Door deployments. Detection and prevention modes support different operational stages: detection helps teams understand rule behavior, while prevention blocks matching requests according to configured policy. Transition to blocking should be tested against real application patterns to reduce false positives.

WAF protection is not a substitute for server-side input validation or authorization. A WAF may block common suspicious payloads while a business-logic error still allows one customer to access another customer’s record through valid requests. The remediation remains in the application. The network engineer should collaborate with developers and security teams to separate application fixes from compensating perimeter policy.

Distributed denial-of-service protection addresses resource-exhaustion traffic patterns at a different layer. Azure has platform protections and additional service options depending on the resource and protection plan. Selection should be based on exposure and expected impact, while response procedures account for operational symptoms and availability. A rate-limiting response at the web edge and a network-layer DDoS mitigation are not interchangeable. Their monitoring signals and escalation paths should be understood before an incident.

Privileged administration needs its own access design

Remote administration paths create concentrated risk. Allowing management ports from broad internet ranges may be convenient but exposes a sensitive control surface. Azure Bastion can provide controlled access to supported virtual machines without giving each machine a public management endpoint. Its requirements, deployment topology and relevant role permissions should be considered alongside the organization’s identity and device-management controls.

A strong administration model also restricts who can change network rules, who can operate the firewall and who may approve exceptions. Privileged operations should be attributable and reviewed. Operators need reliable emergency access, but break-glass procedures should not become permanent backdoors that bypass normal governance.

Network controls and identity controls must be assessed together. Reaching a management service is not the same as being authenticated to it; successful authentication is not proof the account should administer all resources behind it. Test plans should include allowed and denied administrative flows, including from remote-work and disaster-recovery locations where relevant.

Design telemetry for the questions operators ask

Visibility begins with a clear question: Why was a connection denied? Which route did it take? Did a backend go unhealthy? Is traffic volume anomalous, or did an application rollout change its normal behavior? Different tools answer different parts of that picture. Azure Network Watcher provides network diagnostics such as connection troubleshooting and packet capture within supported scenarios. Azure Monitor adds metrics, logs and alerting across services.

Virtual network flow logs help record relevant network flow information and support traffic analytics. They can reveal source and destination information, protocol, ports and allow/deny behavior, but they do not replace application transaction traces or provide the full content of every exchange. A NetFlow-based traffic analysis model supplies a useful general framework for interpreting conversations and traffic patterns, while Azure’s actual flow-log schema and coverage should guide implementation.

Telemetry needs retention, access control and costs appropriate to the environment. High-volume logs that nobody reviews may create expense without usable detection. Overly narrow logging may fail to preserve evidence when an incident happens. Teams should define who uses each signal, how quickly it must be available, what decisions it supports and when it may be safely deleted.

Plan now for the flow-logging transition

Azure’s legacy network security group flow logs are being retired on September 30, 2027, and creation of new NSG flow logs is no longer supported. Microsoft recommends virtual network flow logs for new deployments and migration of existing NSG logging. This is a concrete example of why a security design must distinguish a currently functioning configuration from a service feature suitable for new builds.

The transition is not merely a checkbox replacement. Teams should inventory which networks produce the existing logs, what storage and analytics pipelines consume them, and whether dashboards or alerts depend on a particular schema. Enable and verify the replacement before removing the old collection path. Otherwise the organization may create a period of invisible traffic precisely while performing a security improvement.

For exam preparation, the key distinction is the currently recommended technology versus historical artifacts still visible in older tutorials. Use Microsoft Network Watcher and the virtual network flow-logging model in new designs, while understanding the reason legacy NSG flow logs may appear in existing estates. That awareness helps candidates avoid selecting retired creation workflows in scenario questions.

Investigate failures without weakening security by default

A connectivity incident can be caused by the wrong DNS answer, unexpected effective route, firewall deny, NSG rule, unsupported endpoint path or backend application failure. The diagnosis should begin with a specific flow: source, destination, protocol, port and time. Then inspect the controls in the order traffic encounters them. Opening broad firewall rules without locating the failure may create new exposure and fail to fix the original issue.

A blocked packet can be evidence of healthy security. Suppose a web server tries to connect directly to a management interface that should only be accessed from an administration subnet. The correct result is denial even if a developer reports that the connection fails. The fix may be to correct the workflow rather than to authorize the path. Technical troubleshooting must be informed by the policy’s intended behavior.

Where permitted traffic does fail, compare effective routes and security rules with diagnostic results. Check whether the client reaches the correct private endpoint or an unintended public address. Correlate logs from the edge, firewall, workload and application if necessary. The aim is a reproducible explanation that supports the smallest safe change, followed by tests proving both the desired success and continuing unauthorized denial.

Turn security signals into governed improvements

Metrics should inform decisions rather than become decoration. The number of blocked requests is not a universal measure of safety; it can change with attacker traffic, customer behavior and rule tuning. More useful indicators might include unreviewed high-risk rule exceptions, critical flows without monitoring, unresolved policy drift or the time needed to diagnose an outage. Each measure should have a definition, owner and response threshold.

Microsoft Defender for Cloud can provide network-related recommendations and analysis that help teams prioritize exposure. Its score and findings are inputs to risk decisions, not automatic substitutes for business context. A production service facing sensitive records may deserve attention even if the overall environment appears well configured. Conversely, a generic recommendation may need a documented exception when architectural constraints make the standard control inappropriate.

AZ-700 rewards a network engineer who can reconcile availability and protection. Select the correct enforcement layer, prove that the intended path works, verify that the unwanted path does not and maintain enough evidence to explain both. The goal is an Azure network that administrators can operate securely even as architectures and product capabilities evolve.