AZ-900 Azure Security and Network Security Features Explained

If you’re studying for Microsoft Azure Fundamentals AZ-900, Azure security can feel crowded fast. A lot of services sound similar, several work together, and exam questions often describe a problem before they name the tool. The goal is not to memorize every setting. It’s to recognize what each service does, what layer it protects, and what clue words point to the right answer.

Azure security is layered, and that’s really the key idea to hold onto. Honestly, Azure security works best when you think of it as layers all doing their own job—identity, governance, data protection, network controls, posture management, monitoring, and threat detection all build on each other. For AZ-900, the big-picture layered view matters a lot more than digging into deep configuration details, at least in my experience. If you can sort services into the right category and distinguish the common look-alike pairs, you’re in good shape.

1. Core Security Principles You Need for AZ-900

Start with the CIA triad:

• Confidentiality: keep data private from unauthorized access.
• Integrity: keep data accurate and protected from unauthorized changes.
• Availability: keep systems and data accessible when needed.

Azure security controls support those goals through preventive controls, like MFA, NSGs, and resource locks, and detective controls, like logs, alerts, Microsoft Defender for Cloud, and Microsoft Sentinel.

Shared responsibility is one of the most tested fundamentals. Microsoft secures the underlying cloud infrastructure, but customers still secure what they deploy and configure. The exact split depends on the service model and the service configuration.

Defense in depth means using multiple layers, not relying on one control. When I walk people through this in Azure, I usually split it into layers so it’s a lot easier to see what’s protecting what.

• Identity: Microsoft Entra ID, MFA, Conditional Access
• Perimeter: Azure DDoS Protection
• Network: VNets, subnets, NSGs, Azure Firewall
• Application: Application Gateway, WAF
• Compute: Defender for Cloud recommendations, VM hardening
• Data: Key Vault, encryption, private access patterns

Zero Trust is another core principle: verify explicitly, use least privilege, and assume breach. In Azure, you’ll usually see that mindset show up through MFA, Conditional Access, Privileged Identity Management, subnet and NSG segmentation, and ongoing monitoring with Azure Monitor and Sentinel.

Authentication answers “who are you?” Authorization answers “what can you do?” A useful third idea is auditing/accounting: what happened, when, and by whom. That is where logs and monitoring come in.

2. Identity and Access: Entra ID, MFA, Conditional Access, and RBAC

Identity is a critical control plane in Azure. Microsoft Entra ID (formerly Azure Active Directory) is the cloud identity service for users, groups, applications, and devices. Older study guides and some interfaces may still say “Azure AD,” so be ready for both names.

Entra ID supports sign-in features like single sign-on, MFA, and passwordless methods. It also supports application identities. One important AZ-900 concept is managed identities: an Azure resource, such as a VM or app, can get an identity in Entra ID and use it to access services like Key Vault without storing credentials in code.

Multi-Factor Authentication (MFA) adds another verification factor beyond just a password. And honestly, it’s one of the simplest, most effective ways to lower the odds of an account getting compromised.

Conditional Access evaluates signals such as user, group, location, device state, app, and risk before allowing access, requiring MFA, or blocking the request. If a question says “require MFA outside the corporate network” or “allow access only from compliant devices,” think Conditional Access.

A practical policy example at fundamentals level looks like this:

• Target: all users except emergency break-glass accounts
• Cloud app: Microsoft Azure Management
• Condition: outside trusted locations
• Grant control: require MFA

Azure RBAC is different. RBAC authorizes access to Azure Resource Manager resources, not all application or data-plane access everywhere. Its scope hierarchy is:

• Management group
• Subscription
• Resource group
• Resource

Role assignments inherit downward. So a Reader role at the subscription level applies to resource groups and resources under that subscription unless another control changes the outcome. The built-in roles you’ll see most often are Owner, Contributor, and Reader. And if those feel a bit too broad for the task, you can absolutely narrow things down with custom roles.

Important distinction: Entra ID handles identity and sign-in. Azure RBAC handles authorization for Azure management actions. Some services also have separate data-plane permissions, so don’t assume RBAC covers every possible access path the same way.

Example decision flow:

• User signs in with Entra ID
• MFA may be required
• Conditional Access evaluates the context
• RBAC determines allowed Azure management actions at the assigned scope

If a help desk user needs limited VM management, the precise answer is not “RBAC always gives restart-only by default.” The accurate statement is that RBAC can assign an appropriate built-in or custom role at the right scope to provide narrowly scoped access.

3. Data Protection, Key Vault, Encryption, and Governance

Azure Key Vault protects sensitive material used by applications and administrators. It stores:

• Secrets: passwords, connection strings, API keys
• Keys: cryptographic keys used for encryption or signing
• Certificates: digital certificates used for TLS and trust scenarios

Key Vault is not a general user directory and not a replacement for Entra ID. It is for protecting sensitive values and cryptographic material. Access to Key Vault can be managed with Azure RBAC or, depending on how it’s set up, through vault access policies. In stronger setups, Key Vault is usually paired with managed identities so apps can retrieve secrets without hardcoding credentials anywhere.

A practical example would be a web app using a managed identity to read a database connection secret from Key Vault while it’s running. That’s a lot safer than hardcoding a password in source code or leaving it sitting in an unsecured config file.

For resilience and safety, Key Vault also supports features such as soft delete and purge protection, which help recover or protect deleted vault objects.

Encryption at rest protects stored data. A lot of Azure services encrypt data at rest by default with Microsoft-managed keys, which is a nice baseline to have. Some services also support customer-managed keys for organizations that need more control.

Encryption in transit protects data moving across networks. The modern standard is TLS; “SSL” is legacy terminology and deprecated, though people still say it casually. HTTPS uses TLS to protect web traffic.

Azure Policy is a governance and enforcement service. It does not grant user permissions. Instead, it evaluates resources against rules and can apply effects such as deny, audit, modify, or deployIfNotExists. So Policy isn’t just a suggestion engine. It can actually block noncompliant deployments when needed.

Common examples include limiting which Azure regions can be used, requiring tags, or auditing whether storage accounts allow public access.

Resource locks protect resources from accidental change. The two lock types are:

• CanNotDelete: authorized users can modify, but not delete
• ReadOnly: blocks changes and deletion

Locks can block operations even when RBAC would otherwise allow them, which is exactly why they’re so useful for protecting production resources. They don’t replace RBAC; they just add another layer of protection on top of it.

For compliance, Azure provides documentation and audit resources through the Service Trust Portal, which contains information about compliance offerings, certifications, and audit-related materials. The exam takeaway is pretty straightforward: Azure gives you the tools and evidence to support compliance, but you’re still responsible for the configuration, data handling, and internal processes.

4. Security posture, monitoring, logging, and threat detection are really about visibility—knowing what’s happening and being able to react fast.

Microsoft Defender for Cloud includes both Cloud Security Posture Management (CSPM) and workload protection capabilities. It helps you spot misconfigurations, surface recommendations, show compliance views, and add workload protection through Defender plans for supported resource types.

Secure Score is a recommendation-based score, not an absolute measure of security. It helps teams decide what to fix first based on Microsoft guidance, but a high score definitely doesn’t mean the environment is fully locked down.

Microsoft Sentinel is a cloud-native SIEM/SOAR solution built in the Azure ecosystem and commonly backed by a Log Analytics workspace. It uses data connectors, analytics rules, incidents, workbooks, hunting, and playbooks for investigation and response.

The visibility foundation underneath security operations is:

• Azure Monitor: collects metrics, logs, alerts
• Activity Log: subscription-level control-plane events
• Resource logs / diagnostic settings: service-specific logs sent to destinations such as Log Analytics
• Log Analytics: query and analyze collected log data

This is the clean mental model:

• Azure Monitor / Log Analytics = collect and analyze telemetry
• Defender for Cloud = posture and workload protection
• Sentinel = centralized security analytics, investigation, and response

A realistic workflow usually goes something like this: enable logging, review Defender recommendations, improve Secure Score, connect the right data sources into Sentinel, build analytics rules, investigate incidents, and automate response with playbooks where it actually makes sense.

5. Network fundamentals in Azure usually come down to VNets, subnets, private access, and segmentation.

Virtual Networks (VNets) provide private network boundaries in Azure. Subnets divide a VNet into smaller segments so workloads can be isolated by role, such as web, app, and data tiers.

Segmentation limits blast radius. The point is simple: if one subnet gets compromised, the attacker shouldn’t automatically be able to roam everywhere else.

VNet peering connects VNets privately over the Azure backbone. That’s useful when separate networks need low-latency communication and you don’t want to stick a VPN gateway in the middle.

Private Link is the Azure capability for private access to supported services. A Private Endpoint is the actual network interface with a private IP address placed in your VNet for that connection. This is a common exam confusion point. The service itself is still a PaaS service; the consumer reaches it through the private endpoint in the VNet.

Service Endpoints are different. They allow supported Azure services to recognize traffic from selected VNets/subnets and can be used with service firewall rules, but the service still uses its public endpoint. Service Endpoints do not place a private IP for the service into your VNet.

That leads to the exam-safe comparison:

• Private Endpoint: private IP in your VNet, stronger reduction of public exposure, requires DNS planning
• Service Endpoint: secures access from selected subnets to a public service endpoint, simpler in some cases, but public endpoint still exists

Private Endpoints also introduce a real operational dependency: DNS resolution must point the service name to the private IP, or connectivity can fail even when the endpoint itself is configured correctly.

6. Network Protection Services by Layer

This is where AZ-900 questions often try to trip people up.

Network Security Groups (NSGs) are stateful packet filters that use 5-tuple rules for inbound and outbound traffic at the subnet or NIC level. They evaluate rules by priority and also include default rules. If the exam says “control traffic to a subnet or VM NIC,” think NSG.

Azure Firewall is a managed, stateful, centralized firewall service. It supports network rules, application rules, DNAT, threat intelligence-based filtering, and centralized policy management. If a question mentions broad centralized filtering, outbound control, or FQDN-based rules, Azure Firewall is usually the big clue you’re looking for.

Application Gateway is a Layer 7 load balancer for HTTP/HTTPS with features like host-based routing, path-based routing, and TLS termination. Azure Load Balancer, by contrast, is Layer 4 and handles TCP/UDP traffic. If the question mentions web-aware routing, Application Gateway is the better fit.

Web Application Firewall (WAF) protects web applications from HTTP/HTTPS threats using managed and custom rules. In Azure, WAF is commonly used with Application Gateway and Azure Front Door. And just to be clear, it’s not the same thing as Azure Firewall.

Azure DDoS Protection focuses on availability by mitigating volumetric and protocol attacks against public IP resources in VNets. Azure provides basic DDoS infrastructure protection by default, and DDoS Network Protection adds enhanced mitigation, telemetry, and certain cost-protection benefits for eligible attack-related charges. It works alongside WAF and Azure Firewall, and it doesn’t take the place of either one.

Azure Bastion provides secure RDP/SSH connectivity to VMs over TLS through the Azure portal or supported client experience without exposing public IPs on the target VMs. It requires a dedicated AzureBastionSubnet. If the problem is “admins need VM access without opening port 3389 or 22 to the internet,” Bastion is the answer.

7. Once you get into hybrid connectivity, one of the big comparisons you’ll run into is VPN Gateway versus ExpressRoute.

VPN Gateway provides encrypted connectivity using IPsec/IKE over the public internet. It supports scenarios like site-to-site, point-to-site, and VNet-to-VNet connectivity.

ExpressRoute provides private dedicated connectivity to Microsoft cloud services without traversing the public internet in the normal way. It commonly offers more predictable performance, but private does not automatically mean encrypted. If encryption is required, it must be layered separately.

Exam shortcut:

• Encrypted tunnel over the internet = VPN Gateway
• Private dedicated circuit = ExpressRoute
• Private access to a PaaS service from a VNet = Private Endpoint
• Secure browser-based admin access to VMs = Bastion

8. Common Comparisons and Wrong-Answer Traps

Entra ID vs Azure RBAC
Entra ID is identity and sign-in. RBAC is authorization for Azure Resource Manager resources.

Azure Policy vs RBAC
Policy enforces or audits resource compliance. RBAC grants permissions to users, groups, or identities.

NSG vs Azure Firewall
NSG = local subnet/NIC filtering. Azure Firewall = centralized managed filtering and policy.

Azure Firewall vs WAF
Firewall = broader network/application traffic control. WAF = HTTP/HTTPS web attack protection.

WAF vs DDoS Protection
WAF stops malicious web requests. DDoS Protection helps keep public services available during flooding attacks.

Private Endpoint vs Service Endpoint
Private Endpoint gives a private IP in your VNet. Service Endpoint still uses the service’s public endpoint.

Application Gateway vs Load Balancer
Application Gateway is Layer 7 for web traffic. Load Balancer is Layer 4 for TCP/UDP.

VPN Gateway vs ExpressRoute
VPN Gateway uses encrypted internet tunnels. ExpressRoute uses private dedicated connectivity.

Defender for Cloud vs Sentinel
Defender for Cloud focuses on posture and workload protection. Sentinel focuses on SIEM/SOAR, investigation, and response.

Resource locks vs RBAC
RBAC controls who is allowed. Locks can still block delete or change operations even for authorized users.

9. Practical Mini-Scenarios and Troubleshooting Clues

Need to protect a web app from SQL injection and XSS? Use WAF.

Need centralized outbound filtering and policy across networks? Use Azure Firewall.

Need to allow HTTPS but block internet RDP to a VM subnet? Use an NSG with carefully prioritized inbound rules.

Need a storage account reachable only through a private IP? Use a Private Endpoint and verify DNS resolution.

Need to prevent accidental deletion of a production resource group? Use a CanNotDelete resource lock.

Need to restrict deployments to approved regions? Use Azure Policy.

Need secure VM administration without public IPs? Use Azure Bastion.

Need to investigate suspicious activity from multiple data sources? Use Microsoft Sentinel.

Need security recommendations and posture improvement steps? Use Defender for Cloud and review Secure Score.

Quick troubleshooting patterns:

• User cannot sign in: check Entra sign-in logs, MFA method, and Conditional Access results.
• Deployment is blocked: check Azure Policy compliance and deny effects.
• VM traffic is blocked: check NSG priorities, subnet/NIC association, and route path.
• App cannot reach Key Vault: check managed identity permissions, Key Vault network restrictions, and private endpoint/DNS settings.
• Sentinel shows no expected alerts: check connectors, analytics rules, and workspace ingestion.

10. AZ-900 Exam Strategy and Final Cram Sheet

When you read a question, look for trigger words:

• “Who are you?” = authentication
• “What can you do?” = authorization
• “subnet” or “NIC” = NSG
• “centralized filtering” = Azure Firewall
• “SQL injection” or “XSS” = WAF
• “private IP to PaaS” = Private Endpoint
• “encrypted tunnel over internet” = VPN Gateway
• “private dedicated circuit” = ExpressRoute
• “recommendations” or “Secure Score” = Defender for Cloud
• “SIEM/SOAR” or “incidents” = Sentinel
• “prevent accidental deletion” = resource lock
• “require approved region/tag/configuration” = Azure Policy

Final must-know facts:

• Microsoft Entra ID manages identities; Azure RBAC manages Azure resource permissions.
• RBAC scope can be management group, subscription, resource group, or resource.
• Conditional Access uses context; MFA adds verification.
• Managed identities help apps access services without stored credentials.
• Key Vault stores secrets, keys, and certificates.
• TLS is the standard for encryption in transit; SSL is deprecated.
• Azure Policy can deny or audit noncompliant resources.
• Resource locks come in CanNotDelete and ReadOnly.
• Defender for Cloud is CSPM plus workload protection.
• Secure Score is recommendation-based, not a guarantee.
• Sentinel is SIEM/SOAR built around Azure logging and analytics.
• Private Endpoint gives a private IP in your VNet; Service Endpoint does not.
• NSGs are stateful and filter traffic at subnet or NIC level.
• Azure Firewall is centralized and managed; WAF is for web exploits.
• Application Gateway is Layer 7; Load Balancer is Layer 4.
• DDoS Protection helps protect public IP resources in VNets from availability attacks.
• Bastion is for secure VM admin access, not site-to-site connectivity.
• ExpressRoute is private, but not automatically encrypted.

If you can clearly explain those distinctions in plain English, you’re thinking the right way for AZ-900. That’s the real skill: matching the requirement to the right Azure security service without getting distracted by similar names.