Deep Dive Into The Core Security Domains Covered In AZ-700

Introduction

The AZ-700 exam is officially the Azure Network Engineer Associate certification, and security is not a side topic. It sits inside every design choice you make, from subnet layout to route control to traffic inspection. If you are responsible for security domains, threat protection, network security, compliance, assessment tools, and practical application, this certification expects you to think like an architect, not just a troubleshooter.

That matters because Azure networking is not only about connectivity. It is about identity, segmentation, inspection, encryption, and monitoring working together. A workload can be reachable and still be secure. It can also be technically functional and still violate policy, expose data, or create lateral movement risk.

This post takes a deep dive into the security domains that show up repeatedly in AZ-700 scenarios and real Azure designs. The focus is practical. You will see how Microsoft’s networking features fit together, where candidates often make mistakes, and how to reason through tradeoffs in a cloud environment.

According to Microsoft Learn, AZ-700 covers core networking skills such as connectivity, routing, security, and monitoring. That is exactly why this topic matters in production: the exam reflects the same decisions network engineers make when securing hybrid and cloud-native environments.

Azure Network Security Fundamentals

Azure network security is the set of controls that protect traffic, isolate workloads, and reduce exposure inside Microsoft Azure. It differs from traditional on-premises perimeter security because there is no single castle wall. Instead, you are securing traffic across virtual networks, subnets, private endpoints, gateways, filters, firewalls, and identity-aware policy controls.

Azure follows a shared responsibility model. Microsoft secures the underlying cloud platform, while customers configure network access, segmentation, endpoint exposure, logging, and identity-based controls. Microsoft’s shared responsibility guidance makes this distinction explicit, and it is central to AZ-700 thinking.

The main security layers in Azure networking are straightforward, but they must be combined correctly:

• Routing determines where traffic goes.
• Filtering controls which traffic is allowed.
• Segmentation limits who can talk to whom.
• Encryption protects traffic in transit.
• Monitoring detects abuse, misconfigurations, and drift.

That layered model maps well to the NIST Zero Trust approach, which treats connectivity as something to verify continuously rather than assume by network location. In practice, AZ-700 rewards candidates who can connect secure design to deployment details.

Common mistakes include using one flat virtual network for everything, leaving management ports broadly open, and forgetting that identity and policy are part of security. A secure design starts with intended access, not with “allow all and tighten later.”

Network Segmentation With Virtual Networks And Subnets

Virtual networks and subnets are the foundation of segmentation in Azure. They define the boundaries where traffic can be isolated, routed, inspected, and governed. In AZ-700, this is not abstract theory. It affects how you design for blast radius, compliance, and operational clarity.

Subnet design matters because a subnet is often the unit where you attach controls. A database subnet can be isolated from an application subnet. A management subnet can be restricted to administrators. A shared services subnet can host DNS, jump access, or inspection appliances. If everything lives in one large network, your controls become weaker and harder to reason about.

Address planning is part of security. Overlapping ranges complicate peering and hybrid connectivity. Growth planning avoids the need to renumber later, which is painful when routes, private endpoints, and firewalls already depend on those prefixes. Dedicated subnets for services such as Azure Firewall, VPN gateways, or private endpoints also help keep control points predictable.

Segmentation by environment, application tier, or business unit supports governance and compliance. For example, production and development should not share the same trust boundary. A finance workload may require tighter access and separate routing from a marketing site. This aligns well with ISO/IEC 27001 principles around controlling access and reducing unnecessary exposure.

Typical patterns include hub-and-spoke and segmented landing zones. In a hub-and-spoke model, the hub hosts shared services and security controls, while spokes host workloads with tighter isolation. In a landing zone model, each subscription or workload group gets a repeatable, policy-driven structure.

• Use separate subnets for app, data, management, and shared services.
• Plan for non-overlapping address space across on-premises and cloud.
• Segment by risk, not just by convenience.

For AZ-700, the practical question is simple: does this segmentation support secure traffic flow, or merely separate IP ranges on paper?

Traffic Filtering With Network Security Groups

Network Security Groups, or NSGs, are the primary Azure control for subnet-level and NIC-level traffic filtering. They evaluate rules in priority order and allow or deny inbound and outbound traffic based on source, destination, protocol, and port. For exam purposes, you need to understand both how they work and how they fail when designed poorly.

NSGs support a least-privilege approach when you think in allow-list terms. Instead of opening broad ranges and then trying to close them later, define only the traffic needed for the workload. If a web server only needs inbound 443 from a load balancer and outbound access to a specific backend, that is all the NSG should permit.

Rule priority is critical. Lower numbers win. A well-designed NSG usually has a small set of intentional rules, with clear names and a predictable structure. Use naming conventions that show purpose, source, destination, and port. For example, a rule named Allow-Frontend-To-API-443 is far better than Rule01. Add tags or metadata in your change process so rule intent survives staff turnover.

Common scenarios include restricting RDP or SSH to a management subnet, allowing application traffic to a database subnet, and preventing lateral movement between workloads. If a developer workstation should not talk directly to production SQL, the NSG should make that impossible. This is a core network security practice and a frequent AZ-700 test pattern.

Microsoft’s NSG documentation explains the built-in default rules and how custom rules override them. That detail matters because many candidates assume a deny-only posture when they actually have permissive defaults to account for.

A common failure pattern is rule sprawl. Teams add one-off rules until nobody knows why they exist. The fix is governance: group rules by function, review them regularly, and remove anything not tied to a documented service need.

Advanced Filtering With Application Security Groups And Service Tags

Application Security Groups simplify NSG management by grouping resources by function rather than by IP address. Instead of updating rules every time a VM gets a new private IP, you attach the workload to an ASG and reference that group in your policy. That is a major operational win when systems scale or change often.

ASGs are especially useful for app-tier architecture. You can group front-end servers, API servers, and database servers separately, then create clean rules between those groups. This reduces the chance of stale IP-based rules and makes policy easier to read during audits or incident response. It is a good example of practical application of Azure network design.

Service tags solve a different problem. They represent Azure platform services or specific ranges that Microsoft maintains, so you do not need to track every underlying IP manually. They are useful for rules involving Azure Backup, Azure Monitor, Storage, or other platform dependencies where a fixed IP list would be fragile. Microsoft Learn documents how service tags reduce rule maintenance and improve consistency.

That said, neither ASGs nor service tags replace all custom controls. ASGs do not work for everything outside your own workload grouping. Service tags are not a substitute for application-specific segmentation, and they may be too broad if you need tighter control over a subset of endpoints. If you need exact source and destination enforcement for a partner network or a regulated service, IP-based rules may still be required.

Think of the tradeoff this way:

For AZ-700, the exam often tests whether you can choose the most maintainable option without sacrificing security. The right answer is usually the one that reduces administrative overhead while preserving least privilege.

Private Access And Exposure Reduction

The principle here is simple: reduce public exposure wherever possible. In Azure, that usually means replacing internet-facing access paths with private connectivity. The most important tools are private endpoints and Private Link, which allow you to reach supported PaaS services over a private IP address in your virtual network.

A private endpoint maps a service to your VNet. Traffic stays on Microsoft’s backbone rather than traversing the public internet. That matters for security, compliance, and operational control. A storage account, database, or internal API can be reachable from approved networks without exposing a public listener.

Compare the two approaches. With a public endpoint, you must rely on firewall settings, IP allow-lists, and often additional identity checks. With private access, the service is no longer broadly reachable from the internet. That reduces attack surface and simplifies some compliance conversations, especially where policy requires minimal public exposure.

Microsoft’s Private Link overview describes the service as a way to access Azure PaaS, partner services, and your own private services securely through private endpoints. In real deployments, that often means storage, SQL, Key Vault, and internal APIs.

Typical use cases include:

• Securing storage accounts used for backups or logs.
• Protecting databases that should not accept public traffic.
• Publishing internal APIs for internal consumers only.
• Reducing dependence on static public IP allow-lists.

Private access does not eliminate the need for NSGs or monitoring. It reduces exposure, but you still need to govern who can resolve, route to, and use the endpoint. That is the distinction AZ-700 expects you to understand.

Encryption And Secure Traffic Handling

Encryption in transit is a core security requirement in Azure networks. It protects data as it crosses subnets, virtual networks, tunnels, and provider backbones. For AZ-700, you need to understand where transport encryption is enforced and where additional application-layer protection may still be necessary.

TLS is the standard for securing HTTP and many other application protocols. Enforcing TLS 1.2 or higher for web apps, APIs, and service-to-service communication reduces the risk of interception or tampering. Even when traffic stays inside Azure, encryption remains valuable because internal compromise is still a real threat.

VPN and ExpressRoute each handle encryption differently. Site-to-site VPN encrypts traffic across the internet using IPsec/IKE. ExpressRoute provides private connectivity, but encryption responsibility depends on the design. If traffic requires encryption beyond the private circuit, you may need to implement application-level TLS or additional overlay encryption. That distinction is often tested in architecture questions.

If you handle sensitive data, application-layer encryption can be required even when the network is private. Examples include regulated healthcare data, financial records, or keys stored in a protected vault. In those cases, network trust is not enough. The application must still enforce confidentiality end to end.

From a framework perspective, OWASP Top 10 remains relevant because insecure transport and weak access patterns often show up together. An endpoint exposed without TLS is not just a protocol problem; it is a data protection problem.

Private connectivity reduces exposure. Encryption reduces the value of interception. Together, they create a stronger security posture than either control alone.

When you prepare for AZ-700, remember the difference between network-level security and end-to-end application security. Both matter, but they solve different problems.

Secure Connectivity Between On-Premises And Azure

Hybrid networking introduces several security domains at once: identity, routing, segmentation, and inspection. In Azure, the main patterns are site-to-site VPN, point-to-site VPN, and ExpressRoute. Each has different trust boundaries and operational implications.

Site-to-site VPN is common for branch offices or datacenters that need encrypted network-to-network connectivity. Point-to-site VPN is more user-centric and typically used for remote access by admins or mobile users. ExpressRoute is used when organizations want private, dedicated connectivity between on-premises and Azure without traversing the public internet. Microsoft documents these options in its networking overview.

Gateway configuration influences access control and routing. If you advertise too many routes, you increase reachability in ways that may violate segmentation policy. If you advertise too few, users cannot access required services and will look for workarounds. User authentication and authorization also matter for point-to-site connectivity, especially when admins need privileged access to management subnets only.

Route propagation and user-defined routes are where secure design becomes real. A secure hybrid topology usually limits which branch networks can reach which Azure subnets. That may mean sending management traffic through a specific path while blocking direct access to sensitive application segments. It may also mean using separate gateways or route tables for production and nonproduction.

• Use UDRs to force traffic through security controls when required.
• Isolate admin traffic from general user traffic.
• Restrict branch access to only the subnets that need it.
• Validate propagation so unintended routes do not appear.

For AZ-700, think about who connects, what they can reach, and how traffic is controlled between environments. That is the difference between simple connectivity and secure connectivity.

Perimeter Security With Azure Firewall And Related Services

Azure Firewall is the centralized inspection and policy enforcement point many Azure architectures use for north-south and east-west control. It supports network rules, application rules, threat intelligence, and logging, which makes it a strong choice when a hub network needs consistent inspection and egress control.

Network rules work at L3/L4 and are useful for IP, protocol, and port-based traffic. Application rules inspect FQDNs and HTTP/S traffic, which helps when you need to allow web destinations without opening broad network access. Threat intelligence can help identify malicious destinations, while logging gives you visibility into what was blocked or allowed. Microsoft’s Azure Firewall documentation is the best reference for feature behavior.

Use firewall policies when you want centralized governance and reusable rule sets. Use NSGs for distributed enforcement close to the workload. The strongest designs use both. NSGs limit traffic at the subnet or NIC, and Azure Firewall provides deeper inspection and centralized control at the hub. That layered defense is often the right answer in AZ-700 scenario questions.

Related services also matter. DDoS Protection helps defend public-facing resources from volumetric attacks. Web Application Firewall is more appropriate for HTTP/S application-layer threats. These services are not replacements for each other. They sit at different layers of the stack.

Common hub-and-spoke architectures centralize internet egress through Azure Firewall and send inbound traffic through inspection points before it reaches spokes. That model makes policy easier to manage and audit. It also supports more reliable logging, which matters during incident response and compliance review.

Monitoring, Logging, And Threat Detection

Security without visibility is guesswork. Monitoring is how you validate that your Azure network security controls work as intended and how you investigate suspicious behavior when they do not. AZ-700 expects you to know the tools that reveal traffic patterns, drops, and rule hits.

Start with diagnostic settings and logs. NSG flow logs show traffic flows that pass or fail through NSG rules. Azure Firewall logs show rule matches, threat intelligence hits, and network events. VPN gateway logs help diagnose connection issues and unusual tunnel activity. Network Watcher provides packet capture, connection troubleshoot, and topology visibility that are valuable during both design validation and incident response.

These logs become much more powerful when centralized. Microsoft Defender for Cloud helps identify misconfigurations and security recommendations. Microsoft Sentinel can correlate events across network, identity, endpoint, and cloud sources. Together, they turn raw telemetry into detection and response workflows.

Consider a real scenario: an admin reports that an app is unreachable from one subnet but not another. Flow logs can show whether the traffic was denied by NSG, routed incorrectly, or blocked by firewall policy. Connection troubleshoot can validate the path. Firewall logs can confirm whether the request even reached the inspection layer.

Continuous monitoring is not optional. Security posture changes as rules are added, routes are updated, and workloads move. Without routine validation, a secure design can drift into an insecure one.

• Review denied traffic for signs of probing or misconfiguration.
• Check for overly broad allow rules.
• Correlate firewall, NSG, and gateway logs before changing policy.
• Use alerts for unexpected changes in exposure.

This is where assessment tools matter in practice. They do not just tell you what is broken. They confirm whether your design still matches the security intent.

Identity-Aware And Policy-Driven Network Security

Azure network security is not only about packets. It is also about who can create, modify, and bypass controls. Role-based access control defines which users and groups can manage virtual networks, firewalls, gateways, and related resources. Separate duties matter because the person who deploys workloads should not automatically be the person who approves network policy changes.

For scalable governance, Azure Policy is a major tool. It can require private endpoints, restrict public IP creation, or enforce approved resource locations and configurations. That makes security repeatable across subscriptions and teams. Microsoft Learn documents how policy evaluates compliance and can deny or audit deployments based on your rules.

Management groups and subscription-level controls extend that governance across the enterprise. Instead of manually reviewing every workload, you set standards once and enforce them across aligned business units or environments. That approach supports compliance goals and reduces configuration drift.

Identity-aware networking is also a practical defense against accidental exposure. If developers cannot create public endpoints in production, they cannot accidentally expose a database to the internet. If only a small admin group can alter firewall policies, unauthorized changes are less likely.

Many compliance frameworks reward this kind of structure. AICPA SOC reporting guidance and NIST NICE both emphasize role clarity, accountability, and repeatable controls. That is exactly what Azure Policy and RBAC deliver when used well.

Common AZ-700 Security Scenarios And Exam Focus Areas

AZ-700 security questions usually test decisions, not definitions. You may be asked to secure access to a PaaS service, route traffic through a firewall, isolate workload tiers, or support hybrid users without exposing the wrong subnet. The best approach is to map each requirement to the right control layer.

One common decision is NSG versus Azure Firewall. Choose NSGs for distributed, subnet-level filtering close to the workload. Choose Azure Firewall when the scenario requires centralized inspection, FQDN filtering, or consistent egress policy. Another frequent decision is private endpoint versus service endpoint. Private endpoints reduce exposure further by giving the service a private IP in your VNet, while service endpoints extend identity-based access to a public service path. The exam often wants you to identify which option better matches the security goal.

Expect questions about admin access, partner connectivity, and application isolation. If only administrators need remote access, point-to-site VPN with tight route control may be the right answer. If a partner must reach only one app, segmentation plus selective routing and filtering may be required. If a database must never be internet-visible, the correct answer is usually private access combined with restrictive policy.

Common mistakes include:

• Misconfigured routes that bypass inspection.
• Overly permissive allow rules “just to get it working.”
• Assuming service tags are always specific enough.
• Forgetting that security groups do not replace private access.
• Ignoring logging when the scenario clearly requires validation.

A practical mental model helps under exam pressure: start with exposure, then routing, then filtering, then inspection, then monitoring. If you answer questions in that order, you are less likely to miss the real security requirement hidden in the wording.

When AZ-700 asks for a secure design, the right answer usually reduces exposure first, then controls movement, then improves visibility.

Conclusion

The security domains covered in AZ-700 are not isolated topics. They work together. Segmentation sets boundaries. NSGs and ASGs control traffic inside those boundaries. Private access reduces exposure. Encryption protects data in transit. Firewalls add centralized inspection. Monitoring proves that the design still works after deployment.

That layered approach is what real Azure network security looks like. It is intentional, governed, and built around the idea that no single control is enough on its own. If you understand how routing, filtering, identity, inspection, and logging connect, you will be much better prepared for the exam and for production design work.

Studying for AZ-700 should include the platform features and the architecture patterns that connect them. Read the official Microsoft documentation, compare design options, and practice tracing how traffic moves from source to destination. That habit will help you answer scenario questions faster and with more confidence.

If you want structured learning support for your team, Vision Training Systems can help you build practical Azure networking knowledge that transfers directly into the job. The goal is not just passing the exam. It is designing secure Azure environments that reduce exposure, control movement, and increase visibility.

That is the real takeaway. Secure Azure networking is not one setting or one tool. It is a design discipline.