13.3 Network Security Optimization Design

Exam AZ-305: Designing Microsoft Azure Infrastructure Solutions Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Orientation

1.1 AZ-305 Current Exam Facts & Format 1.2 Candidate Profile, Prerequisites & the AZ-104 Requirement 1.3 Skills Outline, Domain Weights & How to Use This Guide

2 Chapter 2: Logging, Monitoring & Diagnostics Design

2.1 Logging Solution Design 2.2 Log Routing Design 2.3 Azure Monitor Metrics & Alerting Design 2.4 Application Insights & Diagnostic Monitoring Design

3 Chapter 3: Authentication & Authorization Design

3.1 Authentication Solution Design 3.2 Identity Management Design 3.3 Authorization for Azure Resources 3.4 Authorization for On-Premises Resources 3.5 Secrets, Certificates & Key Management Design

4 Chapter 4: Governance, Compliance & Identity Governance Design

4.1 Management Group & Subscription Hierarchy Design 4.2 Resource Group Organization & Tagging Strategy Design 4.3 Compliance Management Design 4.4 Identity Governance Design

5 Chapter 5: Relational Data Storage Design

5.1 Relational Data Storage Selection 5.2 Database Service & Compute Tier Design 5.3 Database Scalability Design 5.4 Relational Data Protection Design

6 Chapter 6: Semi-Structured & Unstructured Data Storage Design

6.1 Semi-Structured Data Storage Design 6.2 Unstructured Data Storage Design 6.3 Storage Tier & Cost-Performance Trade-off Design 6.4 Unstructured Data Protection & Durability Design

7 Chapter 7: Data Integration & Analytics Design

7.1 Data Integration Pipeline Design 7.2 Event-Based & Real-Time Data Integration Design 7.3 Data Analytics Platform Design

8 Chapter 8: Backup & Disaster Recovery Design

8.1 Recovery Objectives Design: Calculating and Meeting RTO/RPO 8.2 Azure Site Recovery Architecture for Hybrid Workloads 8.3 Compute Backup & Recovery Design 8.4 Database Backup & Recovery Design 8.5 Unstructured Data Backup & Recovery Design

9 Chapter 9: High Availability Design

9.1 Compute High Availability: Availability Sets & Availability Zones 9.2 Compute High Availability: Load Balancing & VM Scale Set Design 9.3 Relational Data High Availability Design 9.4 Semi-Structured & Unstructured Data High Availability Design

10 Chapter 10: Compute Solution Design

10.1 Compute Requirements Analysis & Virtual Machine-Based Solution Design 10.2 Container-Based Solution Design (AKS, Container Apps, Azure Container Instances) 10.3 Serverless-Based Solution Design (Azure Functions, Logic Apps) 10.4 Batch Processing Solution Design (Azure Batch, HPC Workloads)

11 Chapter 11: Application Architecture Design

11.1 Messaging Architecture Design (Service Bus, Queue Storage) 11.2 Event-Driven Architecture Design (Event Grid, Event Hub) 11.3 API Integration & Application Caching Design (API Management, Azure Cache for Redis, CDN) 11.4 Application Configuration Management & Automated Deployment Design (App Configuration, DevOps Pipelines, Deployment Slots)

12 Chapter 12: Migration Design

12.1 Migration Assessment: Cloud Adoption Framework & On-Premises Evaluation 12.2 IaaS & PaaS Workload Migration Design 12.3 Database Migration Design (Data Migration Service, Database Migration Assistant) 12.4 Unstructured Data Migration Design (AzCopy, Data Box, Storage Migration Service)

13 Chapter 13: Network Solution Design

13.1 Internet Connectivity Design 13.2 Hybrid Connectivity Design 13.3 Network Security Optimization Design 13.4 Network Performance Optimization & Load-Balancing/Routing Design

14 Chapter 14: Final Review, Exam Strategy & Career Path

14.1 Cross-Domain Scenario Practice: Combining Identity, Data, Continuity & Infrastructure Decisions 14.2 Common AZ-305 Decision Traps 14.3 Final Study Plan & Practice Assessment Strategy 14.4 After AZ-305: Retake Policy, Renewal & Career Path

13.3 Network Security Optimization Design

Key Takeaways Explain This Topic AI

NSGs are stateful, free, Layer 3/4 allow/deny filters at the subnet or NIC level with priorities 100-4096 (lower number = higher priority) and five default rules that cannot be deleted, only overridden.

Azure Firewall is a centralized, stateful Layer 3-7 service supporting FQDN filtering, threat intelligence, and DNAT; Premium SKU adds IDPS, TLS inspection, and URL filtering that Standard SKU lacks.

Azure DDoS Protection has two paid tiers: IP Protection (per-IP billing, no cost protection or rapid response) and Network Protection (per-100-IPs billing, adds cost protection, rapid response, and WAF discount) — infrastructure-level protection is always free and automatic.

Private Endpoints bring a PaaS resource's private IP directly into your VNet and eliminate the public endpoint entirely; Service Endpoints keep the resource's public IP but restrict access to it from selected VNet subnets.

Layered design — NSG for basic segmentation, Azure Firewall for centralized egress/FQDN control, Private Endpoints for PaaS isolation, DDoS Network Protection for volumetric attacks — is the standard AZ-305 answer for a zero-trust or regulated workload.

Last updated: July 2026

Why This Topic Matters

"Recommend a solution to optimize network security" is official Domain 4 bullet #47. Because Domain 4 (Infrastructure) is worth 30-35% — the single largest slice of the exam — and network security spans nearly every workload scenario, this topic recurs across the exam in disguise: identity questions reference Private Endpoints, data-storage questions reference Service Endpoints, and business-continuity questions reference Azure Firewall's role in DR failover traffic. Mastering the layered security stack pays off across multiple domains, not just this one section.

Network Security Groups (NSGs)

A Network Security Group is a free, stateful Layer 3/4 packet filter applied to a subnet or a network interface (NIC) . Key exam facts:

Rules are evaluated in priority order, lowest number first (range 100-4096 ); the first matching rule wins and evaluation stops.

Every NSG ships with default rules (e.g., allow VNet-to-VNet, allow Azure Load Balancer probes, deny all other inbound) that cannot be deleted — only overridden by adding a custom rule with a lower (higher-priority) number.

Rules can target service tags (e.g., Internet , VirtualNetwork , Storage , AzureCloud ) instead of literal IP ranges, and application security groups (ASGs) to group VMs logically (e.g., "WebTier") rather than by IP address, so rules survive VM scale-out without editing.

NSGs are stateless about protocol semantics — they filter on IP/port/protocol only, with no awareness of HTTP headers, FQDNs, or application payloads.

Azure Firewall

Azure Firewall is a fully managed, centralized, stateful Layer 3-7 network security service, typically deployed once in a hub VNet or Virtual WAN Secure Hub to protect all spoke traffic.

• Capability Standard SKU Premium SKU
• Stateful L3-L4 filtering, DNAT, SNAT Yes Yes
• FQDN filtering (application rules) Yes Yes
• Threat intelligence-based filtering Yes Yes
• TLS inspection No Yes
• IDPS (Intrusion Detection and Prevention System) No Yes
• URL filtering (vs. FQDN-only) No Yes

Choose Premium whenever the scenario calls out regulated industries, deep-packet inspection, or protection against known-vulnerability exploitation (IDPS) — Standard is sufficient for basic FQDN/network filtering and DNAT scenarios.

NSG vs. Azure Firewall

• Dimension NSG Azure Firewall
• Layer 3/4 3-7 (Premium adds deep inspection)
• Scope Per subnet/NIC Centralized, typically one per hub
• Cost Free Paid, hourly + data processed
• FQDN filtering No Yes
• Threat intelligence No Yes
• Typical use Micro-segmentation between tiers Centralized egress control, DNAT, hybrid perimeter

Most production designs use both : NSGs for east-west micro-segmentation between subnets/tiers, and Azure Firewall for centralized north-south (internet/on-premises) egress control — not one instead of the other.

Azure DDoS Protection

Azure's infrastructure-level DDoS protection is free and automatic for every public IP in Azure — no configuration needed. Beyond that baseline, two paid tiers add adaptive, application-aware protection:

• Feature DDoS IP Protection DDoS Network Protection
• Active traffic monitoring, L3/L4 automatic mitigation Yes Yes
• Mitigation policies tuned to your application Yes Yes
• Protects Public IP Basic-tier resources No Yes
• DDoS Rapid Response support No Yes
• Cost protection (credits for attack-driven scale-out) No Yes
• WAF discount No Yes
• Billing model Per protected IP Per 100 protected IPs

Guidance: fewer than ~15 public IPs to protect → IP Protection is more cost-effective ; more than ~15 → Network Protection wins on cost and adds cost protection plus a 15-minute-SLA rapid response team. Network Protection also carries the overall 99.99% availability SLA .

Private Endpoints vs. Service Endpoints

A Private Endpoint provisions a private IP address from your VNet that maps directly to a specific PaaS resource instance (a specific storage account, SQL server, Key Vault) using Azure Private Link . Traffic never leaves the Microsoft backbone, and — critically — the public endpoint can be disabled entirely , fully removing the resource from internet reachability.

A Service Endpoint extends your VNet's identity to the Azure backbone for a service (e.g., Microsoft.Storage ), letting you restrict the PaaS resource's firewall to allow only traffic from specific VNet/subnets — but the resource keeps its public IP address and DNS name ; traffic is optimized and restricted by source, not made private.

The deciding question: must the public endpoint disappear entirely? If yes (zero-trust, regulatory mandate, or the earlier Front Door Premium Private Link scenario), use Private Endpoint . If a simpler, no-cost VNet-scoped restriction is sufficient and the resource can retain a public DNS name, Service Endpoint is the lighter-weight, cheaper choice.

Exam Scenario

A healthcare company stores PHI in Azure SQL Database and Blob Storage and must satisfy an auditor's requirement that these resources have no public network path whatsoever , that all traffic between application tiers is segmented, and that the environment is protected against both volumetric DDoS attacks and known CVE-based exploitation attempts from a compromised on-premises partner network. The design: Private Endpoints for SQL Database and Blob Storage (eliminating public endpoints), NSGs on each subnet enforcing tier-to-tier segmentation (web → app → data only), a hub-deployed Azure Firewall Premium (IDPS enabled) inspecting all traffic between the on-premises partner connection and the workload, and DDoS Network Protection enabled on the VNet (justified because the environment has well over 15 public-facing IPs across its App Service and Front Door tier, and the auditor requires the cost-protection guarantee).