Azure Infrastructure Security

Picture a single request arriving from the public internet and travelling all the way to a password your application needs. That request crosses the network in layers, the network and transport layers (3 and 4) that move packets and the application layer (7) that carries the web content, and it may end at a virtual machine (VM), a server you rent in Azure. Azure places a distinct security control at each of those layers, and this page seats seven of them along that one request path so you can name which control belongs where and pick the right one for a given threat.

The order runs outward-in. Azure DDoS Protection^[1] meets the raw traffic at the edge and scrubs volumetric floods. Azure Firewall^[2] filters the perimeter for every network at once. A Web Application Firewall^[3] reads the web request itself for exploits. Virtual networks and subnets^[4] carve the environment into isolated segments. A network security group^[5] (NSG) allows or denies traffic right at a subnet or a network interface (NIC). Azure Bastion^[6] is how an administrator reaches a VM without ever exposing it. And Azure Key Vault^[7] is the guarded store the secret finally rests in.

This is defense in depth expressed as products: each layer is independent insurance, so getting past one still leaves the next. It maps onto the Microsoft Zero Trust model, whose assume breach principle motivates the segmentation and least-privilege network access this page is built on, and whose infrastructure and networks pillars these controls serve. The sections that follow walk the path one stop at a time, then close on the boundaries the exam turns on.

Your application's front door faces the public internet, and three different kinds of attack can arrive there: a flood that simply drowns your bandwidth, traffic from an address Microsoft already knows is malicious, and a crafted web request that tries to trick your code. Three Azure services, which Microsoft groups as the network security category, answer these in turn.

Azure DDoS Protection: absorbing floods at layers 3 and 4

A distributed denial-of-service (DDoS) attack tries to overwhelm your resources so genuine users cannot get through, and it comes in three shapes^[1]: volumetric attacks that flood the network with bandwidth-consuming traffic, protocol attacks that exhaust server resources by abusing weaknesses in layer 3 and 4 protocols, and resource (application) layer attacks aimed at the web application itself. Azure DDoS Protection^[8] monitors traffic around the clock and mitigates at layer 3 (network) and layer 4 (transport), which covers the volumetric and protocol shapes. It has two paid tiers: DDoS Network Protection guards an entire virtual network, and DDoS IP Protection is a pay-per-protected-IP model with the same core engine but without the value-added extras (rapid-response support, cost protection, and WAF discounts). Every Azure service already gets a free, default infrastructure-level DDoS protection, but its threshold is tuned high and it gives no telemetry or alerting, so a flood the platform shrugs off can still sink one application. Because DDoS Protection stops at layer 4, application-layer floods such as HTTP floods are handed to a WAF.

Azure Firewall: one stateful policy across every network

Azure Firewall^[9] is a managed, cloud-based network security service that you typically deploy on a central hub virtual network so all your other VNets and on-premises networks route through it, giving one place to control traffic across subscriptions. It is stateful, meaning it tracks the state of active connections and judges traffic in context. Its rules work at both the network level (allow or deny by IP address, port, and protocol) and the application level (control access by fully qualified domain name, or FQDN, over HTTP/S), and its threat-intelligence filtering can alert on or deny traffic to and from IP addresses and domains that Microsoft's feed flags as malicious. It also performs source and destination network address translation (SNAT and DNAT). Azure Firewall is offered in Basic, Standard, and Premium tiers, where Premium adds a signature-based intrusion detection and prevention system (IDPS).

Web Application Firewall: guarding the web request at layer 7

Where Azure Firewall watches the network and can allow or block whole domains, a Web Application Firewall (WAF)^[3] reads inside the web request itself, giving centralized protection for web applications against common exploits at layer 7. This is why Azure Firewall reaching into layer 7 does not make a WAF redundant: the firewall's application awareness means FQDN and protocol control, not the OWASP exploit inspection a WAF performs. A WAF applies the Open Web Application Security Project (OWASP) core rule set to block classics such as SQL injection, cross-site scripting (XSS), and the HTTP floods that DDoS Protection cannot see, and it lets you patch a newly found vulnerability in one place instead of on every app. Azure WAF is delivered through Azure Application Gateway^[10] for a regional web app, Azure Front Door for a globally distributed one, and Azure CDN for content delivery. The exam boundary is crisp: DDoS Protection for network-layer floods, a WAF for application-layer web exploits, and the two together for defense in depth.

A firewall at the perimeter does nothing to stop an attacker who is already inside from moving sideways. Segmentation is the answer: divide the network into compartments so a breach in one cannot spread to the rest, which is the Zero Trust assume breach principle applied to network design.

Virtual networks, subnets, and peering

An Azure virtual network (VNet)^[4] is the fundamental building block of your private network in Azure and the isolation boundary: by default no traffic flows across VNets or inbound from outside, so any communication must be explicitly provisioned. Within a VNet you create subnets, smaller segments that let you separate workloads with different needs, for example web servers in one subnet and database servers in another, each with its own controls. When two VNets genuinely must talk, VNet peering^[11] connects them so their resources communicate as if on one network, over the private Azure backbone rather than the public internet, and global VNet peering does this across regions. Each boundary between segments is a place to inspect and filter traffic.

Network security groups filter within a VNet

The filter that sits closest to a resource is the network security group (NSG)^[5]. It holds inbound and outbound security rules that allow or deny traffic to and from Azure resources, evaluated in priority order (lower numbers first, and once a rule matches, evaluation stops) using five pieces of information: source, source port, destination, destination port, and protocol. That is the five-tuple. You attach one NSG to a subnet or to a network interface (NIC); the same NSG can be reused on many subnets and NICs. Azure adds default rules you cannot delete (though you can override them with a higher-priority rule) whose net effect is to allow traffic within the VNet and from the Azure load balancer while denying all other inbound traffic from the internet. Application security groups (ASGs) let you write those rules against named groups of VMs, such as WebServers or DbServers, instead of tracking IP addresses by hand.

Firewall filters across, an NSG filters within

This is the single most confused pair on the page, and Microsoft draws the line by scope. A network security group provides distributed traffic filtering to limit traffic to resources within a VNet, at the subnet or NIC. Azure Firewall^[5] is a centralized, fully stateful firewall-as-a-service that protects across different VNets and subscriptions and adds FQDN and threat-intelligence filtering an NSG has no concept of. They are complementary, not alternatives: the figure shows Azure Firewall in a central hub filtering across peered spoke VNets, while each spoke keeps its own NSGs guarding traffic within, at each subnet. Use both for defense in depth.

To administer a VM you eventually need Remote Desktop Protocol (RDP) or Secure Shell (SSH) onto it, and the traditional way, opening those management ports to the internet, hands attackers exactly the target they scan for: a reachable machine with an open RDP or SSH port becomes the foothold for reaching everything else.

Azure Bastion^[6] removes that exposure. It is a fully platform-managed service you provision inside your virtual network, and it brokers RDP and SSH sessions to your VMs straight from the Azure portal over Transport Layer Security (TLS) on port 443. Because the session rides in through Bastion, the VM needs no public IP address, no agent, and no special client, and its RDP or SSH ports never face the internet, which also takes the VM off the map for port scanners. Bastion is deployed per virtual network (and serves peered VNets too), not per VM or per subscription, so once it is in place every VM in that network is reachable this way. The figure traces the path: an administrator opens a session from a browser in the Azure portal, the request reaches Azure Bastion^[12] over TLS 443, and Bastion connects onward to the target VM using a private IP.

Two misreadings to avoid. Bastion is not a VPN: it does not extend your on-premises network into Azure, it brokers a single portal-based session. And it is not a jump-box VM that you stand up and patch yourself; it is a managed platform-as-a-service (PaaS) that Azure keeps hardened and current, including against zero-day exploits.

Once code needs a database password or an API key, the worst place to keep it is in the code. Azure Key Vault^[7] is the managed store that centralizes these secrets so applications fetch them at runtime instead, which shrinks the chance of a credential leaking into source control.

Key Vault handles three kinds of protected material, and the exam expects you to recognize all three: secrets (passwords, connection strings, API keys, and other arbitrary values), keys (the cryptographic keys used to encrypt data), and certificates (public and private TLS/SSL certificates it can provision and renew). Access is a two-step gate: authentication, which proves who the caller is, is always handled by Microsoft Entra ID^[13], and authorization, which decides what they may do, is handled by Azure role-based access control (RBAC) or a Key Vault access policy. Key Vault logs every access for monitoring, and it is designed so that Microsoft cannot see or extract your data. It comes in two tiers: Standard protects keys in software, while Premium stores them in a hardware security module (HSM), tamper-resistant hardware the keys never leave, for stricter compliance needs.

The trap to sidestep is treating Key Vault as an identity store. It holds an application's secrets, keys, and certificates, not user accounts or sign-in credentials; those live in Microsoft Entra ID, which Key Vault itself leans on to authenticate its own callers. By granting each application access to only the specific secrets it needs, Key Vault serves the Zero Trust principle of least privilege access and limits the blast radius if a credential is ever exposed.

SC-900 questions on this domain almost always turn on telling two similar controls apart. These are the lines that decide the answer.

The boundaries that get tested

• DDoS Protection versus WAF. A network-layer or transport-layer flood (volumetric or protocol, layers 3 and 4) points to Azure DDoS Protection; a web exploit or application-layer flood (SQL injection, cross-site scripting, HTTP flood, layer 7) points to a Web Application Firewall. If the stem mentions the OWASP top 10, the answer is WAF.
• Azure Firewall versus NSG. Central control across many VNets and subscriptions, with FQDN or threat-intelligence filtering, means Azure Firewall. A simple allow or deny on the five-tuple at one subnet or network interface means a network security group. A stem that says filtering across virtual networks is signalling Firewall; within a virtual network is signalling NSG.
• DDoS Network Protection versus IP Protection. Whole-VNet coverage is Network Protection; billing per protected public IP is IP Protection. The free default infrastructure-level protection is not a substitute, because it gives no telemetry, alerting, or tuned thresholds.
• Azure Bastion. Any stem about reaching a VM with RDP or SSH but without a public IP or an open management port is Bastion. It is not a VPN and not a self-managed jump box.
• Key Vault. Storing an application's secrets, keys, or certificates is Key Vault. Storing user identities or sign-in credentials is Microsoft Entra ID, not Key Vault.

Where this domain goes next

These controls protect the infrastructure; the rest of the domain watches over it. Microsoft Defender for Cloud and secure-score management assess and harden the posture of these resources, Microsoft Sentinel collects their signals for security information and event management (SIEM) and response, and Microsoft Defender XDR extends threat protection across endpoints, identities, email, and apps.