AZ-900 Azure Security and Network Security Features: A Beginner-Friendly Guide

Introduction

Azure security can feel wide at first because it spans identity, network controls, data protection, monitoring, and governance. But for AZ-900, honestly, you don’t need to go full engineer-brain and disappear down a rabbit hole of design details.

What you really need is a clean mental map of what each service does, when you’d use it, and how to separate the ones that sound almost the same on the exam. If you can look at a requirement and classify it as identity, traffic filtering, private connectivity, threat detection, or governance, you are in good shape.

This guide keeps that exam-first approach, but it also fixes a few common accuracy gaps. Honestly, the big thing I want to clean up here is the pairings that throw people off the most — RBAC vs. Conditional Access, Service Endpoints vs. Private Endpoints, and Defender for Cloud vs. Microsoft Sentinel. Those are the ones I’ve seen trip up learners again and again.

It also uses current naming such as Microsoft Entra ID, while noting that older materials may still say Azure AD.

Core Security Principles and Shared Responsibility

The core principles still matter: confidentiality, integrity, and availability. In Azure terms, confidentiality is basically about keeping the wrong people out of a storage account, integrity is about making sure data doesn’t get changed by someone who shouldn’t touch it, and availability is about keeping a public app up and running even when something ugly is going on.

Defense in depth means layering controls across physical, identity, perimeter, network, compute, application, and data layers. Zero Trust means verify explicitly, use least privilege, and assume breach. Least privilege means users, admins, and applications get only the access they need. In cloud environments, identity becomes especially important, but that is a modern security principle, not something unique to Azure.

The shared responsibility model is heavily tested. Microsoft handles the underlying cloud infrastructure, but you’re still responsible for securing everything you put on top of it — your identities, your data, your apps, and the way you configure access.

In IaaS, you still manage the guest OS, patching, identities, and many network settings. In PaaS, Microsoft manages more of the platform, but you still secure app configuration, data, and access. In SaaS, the provider secures the application platform and infrastructure, while you still manage user access, tenant settings, data governance, and sharing.

Quick exam shortcut: if the question talks about patching a VM operating system, that’s the customer’s responsibility, not Microsoft’s.

Identity and Access Security

Microsoft Entra ID is Microsoft’s cloud identity platform. Older content may still call it Azure Active Directory or Azure AD, so be ready for both names. Entra ID stores and manages users, groups, and applications, which is exactly why so many access decisions start there. In cloud security, identity is often the first checkpoint, not the last one.

It’s also where sign-in controls like MFA and Conditional Access come into play.

A useful distinction is this: authentication proves who you are, while authorization determines what you can do. A user might sign in to the Azure portal just fine and still not be able to create a VM if they only have Reader access.

Azure RBAC handles authorization for Azure resources. It works at scopes including management group, subscription, resource group, and resource. Common built-in roles include Reader, Contributor, Owner, and User Access Administrator. That’s different from Microsoft Entra directory roles, which deal with directory administration rather than direct Azure resource actions.

Conditional Access is an Entra ID policy engine. It evaluates signals such as user, group, application, location, device state, and risk, then enforces controls such as require MFA, block access, or require a compliant device. It does not grant Azure resource permissions. That part is RBAC’s job, not Conditional Access’s.

MFA adds another verification factor and is one of the highest-value controls you can enable. A typical scenario is letting someone sign in only if they complete MFA when they’re outside a trusted location or the sign-in risk is higher than normal.

A related concept worth knowing is managed identities. A managed identity lets an Azure resource authenticate to supported services without having to store credentials in code, and that’s a huge security win in real projects.

For example, an App Service can use a managed identity to pull a secret from Key Vault instead of leaving a password hanging around in a config file where it really doesn’t belong. For AZ-900, the big takeaway is simple: don’t embed credentials in code if you can avoid it.

Protecting Secrets and Data

Azure Key Vault stores secrets, keys, and certificates. Secrets are sensitive strings like passwords or connection strings. Keys are used to perform cryptographic operations, like encrypting or decrypting data. Certificates help prove identity and support encrypted communication between systems. Key Vault centralizes these items so they are not hardcoded into applications, scripts, or repositories.

Key Vault is strongest when combined with proper access control. Access should be limited through Entra ID, RBAC or vault access policies as applicable, and ideally managed identities for applications. A very common pattern is that an app authenticates with a managed identity, pulls a database secret from Key Vault, and never stores that secret in code.

Azure also protects data with encryption at rest and encryption in transit. Many Azure services encrypt stored data by default using Microsoft-managed keys, and some also support customer-managed keys when the service or compliance requirement calls for that.

For data in transit, TLS protects web and API traffic. At AZ-900 level, know the difference: at rest means stored data; in transit means moving data.

Azure Network Security Foundations

A virtual network (VNet) is Azure’s private network boundary, and a subnet is a smaller segment within it. Segmentation matters because you usually don’t want your web servers, app servers, and databases all sitting inside the same trust boundary. That’s just asking for unnecessary exposure. A simple design might put the web tier, app tier, and database tier into separate subnets.

North-south traffic moves in and out of the environment, such as internet users reaching a web app. East-west traffic moves laterally inside the environment, such as traffic between subnets. That distinction helps you choose the right controls: WAF and DDoS usually matter more for north-south exposure, while NSGs and segmentation matter a lot for east-west traffic.

Also separate the generic idea of a private endpoint from the Azure feature named Private Endpoint. A public endpoint is reachable over the internet, and that’s perfectly fine for some workloads — just definitely not all of them.

Azure Private Endpoint is a specific Private Link feature that gives a supported service a private IP in your VNet.

Controlling Traffic: NSGs, ASGs, and Azure Firewall

Network Security Groups (NSGs) provide distributed, stateful Layer 3/Layer 4 filtering for subnets and network interfaces. NSGs contain inbound and outbound rules, are processed by priority, and include default rules. A basic example is allowing HTTPS inbound to a web subnet while denying direct RDP from the internet.

Application Security Groups (ASGs) simplify NSG rule management by grouping VMs logically. Instead of creating rules for many IP addresses, you can create groups such as WebServers and AppServers, then write NSG rules between those groups.

Azure Firewall is a centralized managed firewall service. Compared with NSGs, it supports broader centralized control including network rules, application rules, and DNAT/SNAT scenarios. It’s commonly used for controlled outbound internet access and centralized filtering across multiple workloads. NSGs and Azure Firewall aren’t replacements for each other — in real environments, they’re often used together.

Protecting Internet-Facing Applications

Azure Web Application Firewall (WAF) protects HTTP/HTTPS workloads at Layer 7 from threats such as SQL injection and cross-site scripting. In Azure, WAF is commonly used with Application Gateway and Azure Front Door. If the problem is malicious web requests, WAF is the likely answer.

Azure DDoS Protection focuses on availability for internet-facing resources. Azure includes a baseline level of DDoS protection by default, while DDoS Network Protection adds enhanced mitigation, telemetry, and additional capabilities for supported resources. It goes beyond simple volumetric floods and also helps with protocol and resource-layer attacks, which is why it’s an availability-focused control.

If the problem is keeping a service online during a traffic attack, DDoS Protection is usually the thing to think about.

Exam trap: WAF isn’t a general-purpose network firewall, and Azure Firewall is not the best answer for SQL injection.

Secure Administration and Private Connectivity

Azure Bastion provides secure RDP/SSH access to VMs without exposing public IP addresses on those VMs. Browser-based portal access is the common exam scenario, and Bastion deployment requires a dedicated AzureBastionSubnet. If a question asks how to administer a VM securely without opening management ports to the internet, Bastion is the best fit.

For hybrid connectivity, VPN Gateway creates encrypted connectivity over the public internet. It supports scenarios such as site-to-site and point-to-site access. ExpressRoute provides private dedicated connectivity to Azure through a connectivity provider and is often chosen for enterprise hybrid networking with more predictable performance and isolation.

Service Endpoints and Private Endpoints are a frequent exam comparison. A Service Endpoint extends the VNet identity to a supported Azure service and keeps traffic on the Azure backbone, but the target service still uses its public endpoint. A Private Endpoint uses Azure Private Link to map the service to a private IP in your VNet, which reduces public exposure more directly.

Private Endpoints also depend on correct DNS resolution. In real deployments, name resolution has to send clients to the private IP, or traffic may still try to go to the public endpoint — and that’s where people usually get confused.

For AZ-900, the big distinction is this: a Service Endpoint improves access to a public service endpoint from selected VNets, while a Private Endpoint brings the service privately into your network space.

Monitoring, Threat Detection, and Governance

Microsoft Defender for Cloud helps with Cloud Security Posture Management (CSPM), recommendations, and optional workload protections through Defender plans. Its Secure Score shows how well your environment aligns with recommended security practices. Secure Score is a posture indicator, not a crystal ball for predicting a breach.

Microsoft Sentinel is a SIEM/SOAR platform. It pulls in logs and signals from Azure, Microsoft 365, on-premises systems, and third-party sources, then uses analytics to detect threats, create incidents, and automate response through playbooks.

A simple memory aid I like is this: Defender for Cloud improves posture, while Sentinel monitors and responds.

On the governance side, Azure Policy enforces standards. Common effects include deny, audit, append, modify, and deployIfNotExists. Typical examples include requiring tags, restricting allowed regions, or blocking public IP creation.

Policy is about guardrails, not permissions.

Resource locks prevent accidental change. The two key types are CanNotDelete and ReadOnly. Locks don’t replace RBAC, though they do add a useful extra layer.

A user might have permission to delete a resource, but a lock can still prevent that deletion.

A final governance correction: Azure Blueprints should not be treated as the primary current recommendation. It has been retired or deprecated in favor of approaches built around Azure Policy, ARM/Bicep, and related repeatable deployment methods such as template specs.

Exam-Focused Scenarios and Pitfalls

Need read-only access to resources? RBAC.
Need MFA or compliant-device requirements at sign-in? Conditional Access.
Need to store app secrets securely? Key Vault.
Need an app to access Key Vault without stored credentials? Managed identity.
Need to filter traffic at a subnet? NSG.
Need centralized firewall control? Azure Firewall.
Need to protect a web app from malicious HTTP requests? WAF.
Need to keep an internet-facing service available during a traffic attack? DDoS Protection.
Need private IP-based access to Storage or SQL? Private Endpoint.
Need encrypted hybrid connectivity over the internet? VPN Gateway.
Need dedicated private hybrid connectivity? ExpressRoute.
Need secure VM admin without public RDP/SSH? Bastion.

Common pitfalls are predictable. If a user can sign in but cannot manage a VM, think RBAC, not authentication. If sign-in is blocked despite the right password, think Conditional Access or MFA. If a storage account is still using a public endpoint, a Service Endpoint did not make it private. If a public web app is under HTTP attack, WAF is the better answer than Azure Firewall.

Conclusion

The best way to study Azure security for AZ-900 is to group the services by the problem they solve. Entra ID, MFA, and Conditional Access handle sign-in and identity controls. RBAC handles Azure resource authorization. Key Vault and encryption protect secrets and data. NSGs, Azure Firewall, WAF, DDoS Protection, Bastion, Private Endpoints, VPN Gateway, and ExpressRoute cover different network and connectivity needs. Defender for Cloud, Sentinel, Azure Policy, and resource locks improve posture, visibility, and governance.

If you keep the purpose of each service straight in your head, most AZ-900 security questions get a whole lot easier. That’s the real exam skill right there: figure out the problem first, then match it to the right Azure control.