AZ-900 Azure Security and Network Security Features Explained

Introduction

AZ-900 security gets confusing fast because Azure has several controls that sound similar but solve different problems. The exam is not asking you to build a full enterprise security architecture. It is mostly testing whether you can recognize the right service for the right scenario.

The best way to study this topic is to think in layers: identity, authorization, network controls, governance, monitoring, and data protection. In Azure and modern cloud security, identity is often treated as a primary security boundary for management access, but network, data, and workload boundaries still matter too. Honestly, once you start thinking about Azure security as a bunch of layers instead of a random pile of services, the names begin to make a lot more sense.

Azure Security Basics and Shared Responsibility

The CIA triad still matters in Azure. Confidentiality is about preventing unauthorized access to data. In Azure, that usually means using identity controls, encryption, private connectivity, and least-privilege access to make sure sensitive data stays exactly where it should. Integrity is about protecting data and systems from unauthorized or accidental change. In Azure, that often shows up as cryptographic protections, signed artifacts, immutability, and logs that are tough to mess with. Now, Azure Policy, RBAC, and resource locks absolutely help reduce accidental or unauthorized changes, but they’re not the same thing as cryptographic integrity controls. Availability is about keeping systems reachable and usable, supported by resilient design, redundancy, and services such as Azure DDoS protection.

Other core principles show up everywhere on the exam. Least privilege means granting only the access required. Defense in depth means using multiple layers rather than trusting one control. Zero Trust means verify explicitly, use least privilege, and assume breach.

A high-yield distinction is this: authentication answers who you are, authorization answers what you can do, and auditing/accounting records what happened. So, for example, Microsoft Entra ID verifies your identity, Azure RBAC decides whether you’re allowed to do something on a subscription or VM, and logs in Azure Monitor or Microsoft Sentinel help track down what happened afterward.

Shared responsibility is also essential. Microsoft always secures the physical datacenters, hardware, and core cloud platform. Customer responsibility varies by service model:

Exam shortcut: if the question mentions physical security, Microsoft owns it. If it mentions user access, data classification, or VM OS patching in IaaS, that is the customer’s responsibility.

Identity, Authentication, and Authorization

Microsoft Entra ID is Microsoft’s cloud identity platform. It holds users, groups, applications, and service principals inside a tenant, and it handles sign-ins for Azure, Microsoft 365, and a lot of SaaS apps too. A subscription trusts an Entra tenant for identity, which is why learners often see both services together.

Multi-Factor Authentication (MFA) adds another verification factor beyond a password. That extra step could be an authenticator app prompt, a one-time code, a FIDO2 security key, or some other supported method. MFA absolutely reduces the risk of password-only compromise, but legacy authentication and overly broad exceptions can punch holes in it faster than most people realize.

Conditional Access is a policy engine in Entra ID that evaluates sign-in conditions such as user, app, device compliance, named location, and risk. It can allow access, block access, or require controls such as MFA. It is not the same thing as RBAC. Conditional Access decides under what conditions sign-in or token issuance is allowed.

Azure RBAC is Azure’s authorization system for Azure resources. It uses role assignments at scopes including management group, subscription, resource group, and resource. A few built-in Azure RBAC roles you’ll keep seeing are Owner, Contributor, and Reader. Permissions flow from broader scopes down into narrower ones, so scope really matters more than people expect.

A more accurate identity flow is:

User or app sign-in → Entra ID authentication → Conditional Access evaluation (may require MFA or block access) → token issued → resource or app authorization through Azure RBAC or app-specific permissions

That sequence clears up a common exam trap: MFA is often a control required by Conditional Access, not a separate later stage after access is already granted.

Another common trap is Azure RBAC vs Microsoft Entra roles. Entra roles manage the directory itself. Example: Global Administrator is an Entra role. Azure RBAC roles manage Azure resources. Example: Virtual Machine Contributor or Reader is an Azure RBAC role. If the question is about resetting user passwords or managing directory settings, think Entra role. If it is about starting a VM or reading a storage account, think Azure RBAC.

Managed identities are also worth knowing. They let an Azure resource like a VM or App Service authenticate to other Azure services without stuffing credentials into code, which is exactly the kind of mess you want to avoid. Honestly, that pairs really well with Key Vault and is usually the cleaner approach.

Governance, Secrets, and Security Operations

Azure Policy is for compliance and configuration governance. It does not simply “allow or deny users”; that is RBAC’s job. Policy evaluates resources against rules and can use effects such as deny, audit, append, modify, and deployIfNotExists. Policies can be grouped into initiatives for broader standards. Good AZ-900 examples include restricting regions, requiring tags, denying public IP creation, or enforcing secure transfer settings.

Resource locks help prevent accidental management-plane changes. Azure supports two lock types: CanNotDelete and ReadOnly. They’re great for stopping accidental deletion or changes to the resource, but they don’t actually protect the data sitting inside it.

Azure Key Vault stores secrets, keys, and certificates. Depending on how it’s set up, access can be controlled with Azure RBAC or with Key Vault access policies. Soft delete and purge protection are important for recovery and anti-tampering. For fundamentals, the big idea is simple: keep secrets out of code and use managed identities where possible.

Microsoft Defender for Cloud is not just a misconfiguration checker. It provides cloud security posture management, recommendations, secure score, regulatory compliance views, and workload protection capabilities depending on enabled plans. If the exam mentions recommendations, secure score, or improving posture, Defender for Cloud is a strong candidate.

Microsoft Sentinel is a cloud-native SIEM and SOAR platform. It brings data in from configured connectors, runs analytics rules, creates incidents, helps with investigation through workbooks, and can even automate response with playbooks. One thing people miss: it doesn’t magically collect every log by default, so you still have to set up the connectors and data collection.

A useful distinction:

Network Security Features

A virtual network (VNet) is your private network boundary in Azure. You divide it into subnets for segmentation. If a workload doesn’t need to be exposed to the internet, I’d seriously question why it needs a public IP at all. And remember, a lot of Azure PaaS services can still have public endpoints even if your VM itself doesn’t.

Network Security Groups (NSGs) provide stateful Layer 3/4 filtering using 5-tuple rules. You can apply them at the subnet level or directly to a NIC, depending on where you want the traffic filtering to happen. Rules are processed by priority, and Azure includes default rules. NSGs are not application-aware web firewalls. Application Security Groups (ASGs) can simplify NSG targeting by grouping VMs logically.

Azure Firewall is a centralized, managed, stateful firewall service that supports network rules, application rules, NAT rules, logging, and threat intelligence filtering. It is commonly used in hub-and-spoke designs for centralized egress or ingress control. Unlike NSGs, Azure Firewall often depends on routing through user-defined routes (UDRs) so traffic actually passes through it.

Web Application Firewall (WAF) protects HTTP/HTTPS only and is delivered with services such as Application Gateway WAF and Azure Front Door WAF. It helps block Layer 7 attacks like SQL injection and cross-site scripting by using managed rule sets based on widely used web security standards. If the question mentions web requests, HTTP, or application-layer attacks, think WAF rather than NSG.

Azure DDoS protection is about availability during volumetric or protocol attacks. Azure provides basic platform-level DDoS protection by default, while DDoS Network Protection adds enhanced capabilities for VNets, telemetry, and attack mitigation features. DDoS Protection works alongside WAF—it doesn’t replace it.

Azure Bastion provides browser-based RDP/SSH access to VMs without requiring public IPs on those VMs. Bastion is deployed into the VNet in a dedicated AzureBastionSubnet. It secures the management path, but the VM still requires valid OS credentials, SSH keys, or other configured authentication.

Private Connectivity, Service Endpoints, DNS, and Hybrid Access

This is a major exam topic because the names are easy to mix up. Private Link is the underlying Azure private connectivity technology. A Private Endpoint is the actual network interface with a private IP address placed in your VNet for a supported Azure service. The exam often teaches them together, but they are not identical terms.

With a private endpoint, clients connect to a private IP in the VNet rather than to the service’s public endpoint from the client side. That usually reduces exposure, but it also introduces a DNS requirement. In many designs, you use Azure Private DNS zones so the service name resolves to the private endpoint address. If a private endpoint is created but the app still resolves the public name, the likely issue is DNS.

Service Endpoints are different. They extend VNet identity to supported Azure services over the Azure backbone while the service still uses its public endpoint. They are valid for securing PaaS access, but if the scenario specifically requires a private IP-based connection and minimized public exposure, Private Endpoint is usually the better answer.

Azure DNS is Azure’s DNS hosting service, while Azure Private DNS zones are especially relevant for private endpoint name resolution. Do not blur those two ideas on the exam.

For hybrid connectivity, VPN Gateway provides encrypted connectivity over the public internet. ExpressRoute provides private dedicated connectivity to Azure and is often chosen for predictable connectivity, reliability, or regulatory requirements. Important nuance: ExpressRoute is private, but it is not inherently encrypted by default. Private does not automatically mean encrypted.

Real-World Recognition Scenarios

User can sign in to Azure but cannot stop a VM means authentication succeeded, but authorization is missing. Think Azure RBAC.

Sign-in is blocked from an untrusted country or requires a compliant device points to Conditional Access.

A website is vulnerable to SQL injection points to WAF, not NSG or DDoS protection.

A public-facing app is being flooded with traffic and availability is suffering points to DDoS protection.

An internal app must reach Azure Storage using a private IP and no public exposure from the client side points to Private Endpoint/Private Link, plus likely Private DNS.

An admin needs RDP/SSH to a VM without exposing a public IP points to Azure Bastion. If the scenario also mentions reducing open management ports, Bastion is a strong answer.

An organization wants to restrict deployments to approved regions and require tags points to Azure Policy.

A company wants recommendations, secure score improvement, and cloud posture visibility points to Microsoft Defender for Cloud.

A SOC team wants centralized analytics, incidents, hunting, and automation points to Microsoft Sentinel.

Troubleshooting and Exam Tips

AZ-900 questions love hiding the answer inside the symptom, so you’ve got to read them carefully. Use this quick map:

• Who are you? → Microsoft Entra ID
• Prove it with another factor → MFA
• Under what conditions may you sign in? → Conditional Access
• What can you do after sign-in? → Azure RBAC
• What configurations are allowed? → Azure Policy
• Prevent accidental deletion/change → Resource lock
• Store secrets, keys, certificates → Key Vault
• Centralized network filtering → Azure Firewall
• Subnet/NIC packet filtering → NSG
• HTTP/HTTPS attack protection → WAF
• Volumetric flood protection → DDoS
• Private IP access to PaaS → Private Endpoint
• Centralized security analytics and incidents → Microsoft Sentinel
• Posture, recommendations, secure score → Defender for Cloud

High-risk confusion pairs:

• Entra ID vs Azure RBAC: identity/authentication vs resource authorization
• Entra roles vs Azure RBAC roles: directory admin vs Azure resource permissions
• MFA vs Conditional Access: verification method vs policy engine
• NSG vs Azure Firewall: local L3/L4 filtering vs centralized managed firewall
• WAF vs DDoS: web app Layer 7 protection vs availability during flood attacks
• Private Endpoint vs Service Endpoint: private IP connectivity vs restricted access to a public endpoint
• Defender for Cloud vs Sentinel: posture/recommendations/protection vs SIEM/SOAR investigation and response
• Azure Policy vs RBAC: allowed configuration vs allowed actions

From an operations standpoint, keep a few common gotchas in mind: RBAC changes can take time to propagate, private endpoint issues are often DNS-related, NSGs don’t route traffic, and Sentinel can only analyze the data you actually ingest. And one last thing: AZ-900 content does evolve, so it’s definitely worth checking the current official skills outline before exam day.

Conclusion

The easiest way to win this AZ-900 topic is to stop treating Azure security as a product list and start treating it as a decision map. Entra ID, MFA, Conditional Access, and RBAC handle identity and access. Policy, locks, and Key Vault handle governance and protection of sensitive material. NSGs, Azure Firewall, WAF, DDoS protection, Bastion, Private Endpoint, Service Endpoints, VPN Gateway, and ExpressRoute handle network exposure and connectivity. Defender for Cloud and Microsoft Sentinel handle posture, detection, and operations.

If you remember the problem each service solves, the exam becomes much easier: sign-in, permission, policy, filtering, web protection, availability, private connectivity, or investigation. That is the pattern behind most AZ-900 security questions.