The security domain accounts for 25–30% of AZ-305 exam questions. NSG vs. Azure Firewall, Private Link vs. Service Endpoint, TDE vs. Always Encrypted vs. Dynamic Data Masking — this guide cuts through the confusion around network and application security services that trip up candidates most often.
---
Controlling Traffic with NSG and Azure Firewall
NSG operates as a Layer 4 filter at the subnet and NIC level. You define inbound and outbound rules based on source/destination IP, port, and protocol. Rules are evaluated in ascending priority order — the lower the number, the higher the precedence. Default rules automatically allow intra-VNet communication and outbound internet traffic while blocking all other inbound traffic.
ASG lets you reference role-group names instead of IP addresses inside NSG rules. Once you define a group called "WebServers," you can add or replace servers without ever touching the NSG rules themselves.
Azure Firewall is a fully managed Layer 3–7 firewall. Where NSG is a packet filter scoped to a subnet or NIC, Azure Firewall sits in a VNet hub and provides centralized control over traffic across an entire subscription or region. It includes FQDN filtering (allow/block specific domains), automatic blocking via threat intelligence, TLS inspection, and built-in IDPS (Intrusion Detection and Prevention System).
Azure Firewall Policy supports a parent-child hierarchy. When you already have existing policies deployed across multiple regions, you can create a single parent policy containing shared rules and configure existing policies to inherit from it — parent rules then propagate automatically to all child policies. Each policy can have at most one parent.
Network Watcher IP Flow Verify instantly simulates whether NSG will allow or deny a packet to a given destination IP and port. Because no real packets are sent, you get an immediate answer without generating production traffic. Traffic Analytics, by contrast, is an aggregation-based tool built on NSG Flow Logs, meaning results carry a delay of several minutes to tens of minutes — not suitable for real-time troubleshooting.
!NSG versus Azure Firewall
Protecting PaaS with Private Link and Private Endpoint
PaaS services such as Azure Storage, SQL Database, and Key Vault expose public endpoints accessible from the internet by default. There are two approaches to pulling that access path entirely inside your VNet.
Service Endpoint optimizes the route from your VNet to Azure PaaS services through the Microsoft backbone network. Traffic no longer traverses the public internet, but the PaaS service's public DNS name still resolves to a public IP address — the service itself retains its public endpoint.
Private Endpoint assigns a private IP address from inside your VNet directly to a PaaS service. When applied to storage, name resolution flows through a Private DNS Zone and returns a private IP. Disabling public network access makes the service completely unreachable from the internet. Whenever "completely block public internet access" is the requirement, Private Endpoint is the standard answer.
Azure Bastion is a fully managed service that lets you RDP/SSH into a VM from the Azure Portal web browser without assigning a public IP to the VM. Any time you see the phrase "securely connect to a VM without a public IP," select Azure Bastion.
---
Defending Applications with WAF and DDoS Protection
WAF detects and blocks OWASP Top 10 attacks — SQL Injection, XSS, CSRF, and more — at the HTTP/HTTPS layer. In Azure, WAF can be deployed in two places.
Application Gateway WAF is ideal for protecting a single app in a single region. Because each app needs its own gateway, centrally managing multiple apps becomes operationally heavy.
Azure Front Door WAF Policy protects multiple apps simultaneously with a single WAF policy applied at global edge nodes. One policy update propagates instantly to every connected endpoint. When the requirement is "centralized WAF for multiple apps with minimal operational overhead," Azure Front Door WAF Policy is the correct choice.
DDoS Protection Standard automatically safeguards public IPs inside your VNet and adds adaptive tuning, real-time attack analytics, and SLA guarantees. When the requirement specifies defense against volumetric attacks, choose DDoS Protection Standard.
---
Key Vault and Data Encryption
Key Vault manages three object types: keys, secrets, and certificates. API keys, passwords, and connection strings go into Secrets; RSA/EC cryptographic key pairs used for encryption operations go into Keys; X.509 certificates go into Certificates. The strongest TDE protector is an RSA-HSM 4096-bit key — keys generated inside the HSM are never exported.
Transparent Data Encryption (TDE) encrypts Azure SQL data files and backups at the disk level. A DBA can still query plaintext, so TDE alone falls short when the requirement is to block privileged insiders from reading sensitive data.
Always Encrypted moves encryption and decryption responsibility to the client driver at the column level. The database engine always sees only ciphertext, so no one on the server side — including DBAs — can read plaintext values. The Column Master Key (CMK) is stored in Key Vault, and two encryption modes are available: Deterministic (supports equality comparisons) and Randomized (stronger, but no search support).
Dynamic Data Masking (DDM) applies masking to query results without encrypting underlying data. Users with the UNMASK permission see original values; users without it see masked values. Configuration requires no schema or code changes and can be done directly in the Azure Portal.
Key Vault Soft Delete preserves deleted items in a recoverable state for a default retention period of 90 days. Enabling Purge Protection alongside Soft Delete prevents permanent deletion even during the retention window. Key Vault backups can only be restored within the same Azure geography — restoring a Korea Central (Asia Pacific) backup to West Europe (Europe) is blocked by geography constraints.
---
Service Comparison Table
| Service | Layer | Scope | Primary Use Case | Cost Model | |---------|-------|-------|-----------------|------------| | NSG | Layer 4 | Subnet / NIC | Port and IP-based traffic filtering | Free (rule count-based) | | ASG | Layer 4 | VM group | Manage NSG rules by role group instead of IP | Free | | Azure Firewall | Layer 3–7 | VNet hub / region | Centralized FQDN and threat intelligence filtering | Hourly + data processed | | WAF (App GW) | Layer 7 | Single-region app | OWASP Top 10 defense (regional) | Gateway hourly + rule processing | | WAF (Front Door) | Layer 7 | Global multi-app | Centralized OWASP Top 10 defense | Policy + request count | | DDoS Protection Standard | Layer 3–4 | VNet public IPs | Volumetric DDoS defense | Monthly + overages | | Azure Bastion | Layer 7 | VM management channel | RDP/SSH without public IP | Hourly + data | | Private Endpoint | Network layer | PaaS service | Full PaaS isolation via private IP | Private Endpoint hourly | | Service Endpoint | Network layer | PaaS service | Route optimization via backbone | Free |
---
Decision Criteria That Frequently Confuse Exam Candidates
Scenario 1: Completely Block Internet Access to a PaaS Service
When the requirement is to block all public internet access to a storage account and allow access only from inside a VNet, the correct answer is the combination of Private Endpoint plus disabling public network access. Service Endpoint optimizes the route but the public DNS name still resolves to a public IP, so it does not provide complete isolation.
Scenario 2: VM Accesses Key Vault Without Storing Credentials in Code
The requirement to have a VM access Key Vault without storing credentials in code is the signature scenario for Managed Identity. Enable a system-assigned Managed Identity on the VM, grant it secret-read permissions on Key Vault, and the application automatically obtains a token from IMDS (). A service principal requires manual management of secrets or certificates, adding operational overhead.
Scenario 3: Column Encryption Where Even DBAs Cannot Read Plaintext
When the requirement states that all users — including server-side administrators — must be unable to read plaintext in specific columns, Always Encrypted is the only answer. TDE is disk-level encryption so DBAs can still query plaintext, and Dynamic Data Masking exposes original values to privileged users.
Scenario 4: Mask Query Results Without Changing Code or Schema
Showing only certain columns to unprivileged users without modifying any schema or code is a textbook Dynamic Data Masking use case. Always Encrypted requires changes to the client driver and storage format, making it overkill for this scenario.
Scenario 5: Centrally Manage Common Rules Across Multi-Region Firewall Policies
Centrally managing shared rules while keeping existing policies intact is solved by adding a single parent Azure Firewall Policy. Set the existing policies as children that inherit from the parent, and any rule added to the parent automatically applies to all children.
---
Practical Implementation Tips
Evaluate Managed Identity first: whenever a VM, App Service, or AKS workload needs to access Key Vault or Storage, reach for Managed Identity before anything else. Azure SDK's fetches tokens automatically through IMDS, minimizing code changes. Enable Key Vault Soft Delete and Purge Protection by default: Soft Delete alone still allows an administrator to permanently delete items within the retention window. In compliance environments, always activate Purge Protection alongside Soft Delete. Make IP Flow Verify your first diagnostic tool: when NSG rules have grown complex and you need to instantly know whether a particular packet is being blocked, IP Flow Verify is the fastest option. Traffic Analytics has aggregation l