AZ-900 Azure Security and Network Security Features Explained

Azure security can feel a bit overwhelming at first, honestly, because the services overlap just enough to make your head spin. Most AZ-900 learners run into the same sticking points: Defender for Cloud versus Microsoft Sentinel, NSG versus Azure Firewall versus WAF, and then the whole question of where Key Vault or Private Endpoints actually fit. The easiest way I’ve found to make it manageable is to group the services into a few practical buckets: identity, posture and monitoring, network protection, secure connectivity, and data protection. Once you start thinking in those buckets, the names actually begin to click.

Why Security Matters in Azure

At the end of the day, security in Azure is still about protecting data, systems, people, and the business itself. The big difference is that the control points move around a bit in the cloud, so you’re not always locking down the same perimeter-first model you may have used on-prem. In more traditional environments, we usually started by tightening up the network edge first, because that was the obvious place to draw a line around everything. In Azure, identity is usually the first boundary I tell people to secure, because access to resources leans heavily on sign-in, tokens, roles, and service configuration. And, honestly, a compromised identity can be far more dangerous than an open port.

For AZ-900, the big thing isn’t memorizing every little feature. It is understanding what problem each service solves. If the question is about sign-in risk, think identity. If it is about recommendations and Secure Score, think posture. If it is about subnet filtering, think NSG. If the question mentions SQL injection, WAF should be the first thing that comes to mind.

Shared Responsibility Model, put simply

The shared responsibility model means Microsoft secures the cloud, while you secure what you put in the cloud. The split varies by service model and even by service configuration.

Examples help. Take an Azure VM as an example. Microsoft handles the physical host and everything underneath the VM, which is a big help, but you’re still responsible for the guest operating system, deciding who gets admin rights, and locking down the applications running on that VM. With Azure SQL Database, Microsoft does a lot more of the heavy lifting, but you’re still the one deciding who can get to the data, whether the service should be exposed through a public endpoint, and where sensitive secrets should be stored. With Microsoft 365, Microsoft runs the platform, but you’re still responsible for the day-to-day security and governance work like adding and removing users, enforcing MFA, applying sensitivity labels, managing retention, and making sure data is handled properly.

A good exam reminder is this: “fully managed” never means “no customer responsibility.” You still own identities, permissions, data exposure, and configuration choices.

Core Principles: CIA, Defense in Depth, and Zero Trust

The CIA triad still matters in Azure:

• Confidentiality: only authorized users and systems can access data.
• Integrity: data and systems are not changed improperly.
• Availability: services remain reachable when needed.

Azure examples make this easier to remember. Confidentiality gets stronger when you’ve got controls like Microsoft Entra ID, MFA, RBAC, Key Vault, encryption, and Private Endpoints in place. Integrity is protected by things like least privilege, change control, logging that can show tampering, and being really careful with secrets. Availability is helped along by DDoS Protection, backups, monitoring, redundancy, and resilient designs like availability zones and replicated services.

Defense in depth is basically the idea that you don’t rely on just one control and hope for the best. So instead of putting all your faith in one giant security control, you stack protections across identity, network, application, compute, and data. Zero Trust is the mindset that ties it all together: verify every request, give people only the access they actually need, and assume something might already be compromised. Zero Trust is not one Azure product. It is a design model implemented through services like Entra ID, Conditional Access, managed identities, segmentation, monitoring, and policy.

Identity and Access Security

Microsoft Entra ID, formerly Azure Active Directory, is Microsoft’s cloud identity and access management service used across Azure, Microsoft 365, and many other applications. Older study material may still say Azure AD, so recognize both names. Entra ID handles identities, authentication, single sign-on, and access signals.

It helps to separate identity types:

• Users: human identities.
• Groups: collections of identities for easier assignment.
• Service principals: application identities.
• Managed identities: Azure-managed identities for workloads, so apps can authenticate without storing credentials in code.

Authentication answers “Who are you?” Authorization answers “What can you do?” In Azure, Entra ID commonly handles authentication, while Azure RBAC handles authorization for Azure resource management. That distinction matters. Entra ID is the identity provider, while Azure RBAC is the authorization system that decides what you can do with Azure resources.

RBAC assignments are scoped and inherited from broader to narrower levels, starting with management group, then subscription, then resource group, and finally the individual resource. Built-in roles like Reader, Contributor, Owner, and User Access Administrator show up a lot in exam questions. One nuance that’s absolutely worth remembering is that Azure RBAC mainly controls management plane access, while some services also use data plane permissions or their own service-specific access models.

MFA just adds another step during sign-in, but honestly, that one extra step makes life a whole lot harder for attackers. Conditional Access checks signals like who the user is, where they’re signing in from, what device they’re using, which app they’re trying to reach, and whether the sign-in looks risky, then it applies rules like requiring MFA or blocking access altogether. A classic policy example is “require MFA for administrators” or “block legacy authentication.” Conditional Access is about the conditions under which access is allowed, while RBAC is about what a person can do after access is granted.

When it comes to privileged access, least privilege is the goal every time. Even though AZ-900 doesn’t go deep into Privileged Identity Management, it’s still worth knowing the pattern: cut down standing admin rights and elevate only when you really need to.

Governance controls: RBAC, Policy, and Locks

AZ-900 often mixes security and governance, so keep these separate:

• RBAC controls who can do something.
• Azure Policy controls what is allowed or required.
• Resource locks help prevent accidental deletion or modification.

Example: RBAC can let an admin create storage accounts. Azure Policy can require approved regions or deny public IP creation. A delete lock can stop someone from removing a critical resource group by mistake. Together, these support security baselines and reduce configuration drift.

Core Azure Security Services

Microsoft Defender for Cloud is primarily a cloud security posture management service with workload protection capabilities through Defender plans. For AZ-900, remember two buckets: posture and protection. Posture includes recommendations, regulatory views, and Secure Score. Protection includes alerts for supported workloads when the relevant plans are enabled. It is not a SIEM; it is best thought of as “improve security posture and protect workloads.” Just-in-time VM access is one well-known feature because it reduces exposure of management ports.

Microsoft Sentinel is Microsoft’s cloud-native SIEM and SOAR solution. It collects data from connected sources using connectors and works with Log Analytics and related Microsoft security data pipelines. Sentinel is basically the place where you bring security data together, correlate it, create incidents, investigate what’s going on, hunt for suspicious activity, and automate response with playbooks. Defender for Cloud might tell you a VM’s misconfigured or raise a workload alert, while Sentinel helps connect that alert to broader activity happening across your environment.

Azure Monitor and Log Analytics matter here too. Activity logs, resource logs, and diagnostic settings feed visibility. One thing people miss a lot is that not every log just shows up in Sentinel automatically. Sentinel can only help once the data’s been connected and brought in, so getting the data sources hooked up first is the important part.

Azure Key Vault stores secrets, keys, and certificates. Secrets include passwords or connection strings. Keys are used for cryptographic operations and customer-managed key scenarios. Certificates help secure communications, and Key Vault can also help manage their lifecycle, which is a huge help when you’re trying to stay ahead of expiring certs. You can control access with RBAC or Key Vault access policies, and features like soft delete and purge protection help protect you from accidental deletion or someone trying to remove things they shouldn’t. The pattern I usually recommend is pairing a workload with managed identity and Key Vault, because then the app can pull what it needs without storing credentials in the code. That’s the cleanest approach in my book.

Network Security Features

VNets and subnets are the network foundation. A VNet gives you private IP space in Azure, and subnets let you break that space into smaller chunks like web, app, and database tiers. Good subnet planning makes isolation easier, keeps the rules simpler, and, honestly, makes day-to-day operations a lot less painful. VNet peering lets VNets talk to each other privately. For exam purposes, just remember that a VNet isn’t a firewall — it’s the network container.

Network Security Groups are stateful packet-filtering controls applied to subnets and/or NICs. They use priority-based allow and deny rules, and there are also default rules you’ve got to keep in mind. They can filter inbound and outbound traffic based on the source, destination, port, and protocol. Stateful means return traffic for an allowed session is automatically handled. If a question says “restrict traffic to a subnet” or “allow only HTTPS to this VM,” NSG is usually the best fit.

Azure Firewall is a managed stateful firewall service for centralized control. It supports network rules, application rules, and DNAT, and you’ll often see it in hub-and-spoke designs where teams want a central place to enforce policy. It can filter inbound, outbound, and east-west traffic at a broader level. It doesn’t replace NSGs for local subnet or NIC-level segmentation, and it’s not the same as WAF because it isn’t designed to inspect HTTP attack payloads like SQL injection patterns.

Azure Web Application Firewall is Layer 7 protection for web traffic and is typically deployed with Azure Application Gateway or Azure Front Door. It focuses on common web attacks like SQL injection and cross-site scripting, which are two of the big ones you’ll hear about constantly. It’s not a general-purpose network firewall, and it’s definitely not the same thing as DDoS Protection. If the question mentions HTTP or HTTPS attacks against a web app, that’s your clue to think WAF.

Azure DDoS Protection helps defend public-facing resources against large-scale volumetric, protocol, and resource-layer denial-of-service attacks. Azure includes basic infrastructure-level DDoS protection by default, while the stronger, enhanced capabilities depend on the DDoS offering you’ve turned on. The big thing to remember is that this is about availability, not fine-grained access control. DDoS Protection doesn’t replace NSGs, Azure Firewall, or WAF.

Azure Bastion provides RDP and SSH access to VMs through the Azure portal or supported client methods without exposing VM management ports directly to the internet. It is deployed into a dedicated AzureBastionSubnet. Bastion is for administrative access, not general end-user remote access. It is often paired with NSGs and Defender for Cloud JIT to reduce management exposure.

Secure Connectivity and Private Access

VPN Gateway provides encrypted connectivity over the internet. Common scenarios include site-to-site, point-to-site, and VNet-to-VNet connections, so it works well for several different hybrid and Azure-to-Azure use cases. It is the right answer when the requirement is secure hybrid connectivity using VPN tunnels.

ExpressRoute provides private connectivity to Azure through a connectivity provider. Data traffic does not traverse the public internet like an internet VPN does. It is chosen for private routing, predictable performance, and enterprise connectivity requirements. It is not simply a “faster VPN,” and it does not automatically mean encryption unless additional encryption is used.

Private Endpoint uses Azure Private Link to map a supported PaaS service to a private IP in your VNet. That means a storage account, database, or similar service can be reached privately from your VNet or connected networks. Private Endpoint is not hybrid WAN connectivity like VPN Gateway or ExpressRoute. It is private access to a service. DNS matters here: clients must resolve the service name to the private IP, often using private DNS zones.

A common confusion is service endpoints vs Private Endpoints. Service endpoints extend VNet identity to an Azure service over the Azure backbone, but the service still keeps its public endpoint. Private Endpoints place a private IP for the service in your VNet. For “private IP access to PaaS,” Private Endpoint is the better match.

How These Services Work Together

A simple three-tier design shows the layering. Admins authenticate with Entra ID, use MFA, and get permissions through RBAC. The public web tier sits behind Application Gateway or Front Door with WAF. NSGs segment web, app, and data subnets. Azure Firewall centralizes broader ingress and egress policy. A database or storage account is exposed privately through Private Endpoint. Secrets live in Key Vault and are retrieved by managed identity. Defender for Cloud highlights posture issues and workload alerts. Sentinel collects security data and supports investigation and response. That is defense in depth in a real Azure design.

Troubleshooting and verification basics

Even at the fundamentals level, it helps to know how to check whether a control is actually working:

• Conditional Access issue? Check Entra sign-in logs and policy results.
• NSG issue? Review effective security rules and confirm subnet/NIC association.
• Firewall issue? Check routing and firewall logs.
• WAF not blocking? Confirm the WAF policy is associated and in the correct mode.
• Bastion not connecting? Verify Bastion deployment, AzureBastionSubnet, VM state, and path.
• Private Endpoint not working? Check approval state, DNS resolution, and VNet linkage.
• Sentinel missing data? Check connector status, workspace, permissions, and ingestion delay.

AZ-900 Service Selection Matrix

What Microsoft Usually Tests on AZ-900

AZ-900 is mostly about service purpose and best-fit selection, not deep implementation. Focus on these high-yield distinctions:

• Defender for Cloud = recommendations, Secure Score, posture, workload protection.
• Sentinel = SIEM, SOAR, incidents, investigation, automation.
• NSG = subnet/NIC filtering.
• Azure Firewall = centralized network filtering.
• WAF = Layer 7 web protection.
• DDoS Protection = availability during large-scale attacks.
• Bastion = secure admin access to VMs.
• Key Vault = secrets, keys, certificates.
• Private Endpoint = private IP access to supported Azure services.
• RBAC = permissions; Conditional Access = access conditions.

One exam strategy that works well: identify the main problem. A web app may use NSGs, Firewall, and DDoS Protection, but if the question says SQL injection, the best answer is still WAF. A storage account may be reachable over private enterprise connectivity from on-premises, but if the requirement is a private IP endpoint inside the VNet, the answer is Private Endpoint.

Also know what not to over-study for AZ-900: exact SKUs, advanced routing design, detailed Sentinel rule authoring, deep cryptographic operations in Key Vault, or complex ExpressRoute peering design.

Conclusion

The cleanest mental model for Azure security is still the best one: identity first, then layered controls. Use Entra ID, MFA, Conditional Access, and RBAC for access. Use Defender for Cloud for posture and Microsoft Sentinel for investigation and response. Use NSGs, Azure Firewall, WAF, DDoS Protection, and Bastion for network and admin protection. Use Key Vault and Private Endpoints to protect sensitive data paths.

If you remember the problem each service solves, AZ-900 security questions become much easier. That is the real shortcut: stop memorizing names in isolation and start matching service to purpose.