Sign in Subscribe

AZ-900 Azure Security and Network Security Features Explained

AZ-900 Azure Security and Network Security Features Explained

Why Azure Security Matters for AZ-900

For AZ-900, security is mostly about recognizing which Azure service fits which problem. You are not expected to design a full enterprise security architecture or memorize deep configuration steps. You are expected to know the difference between identity, permissions, governance, network protection, secrets management, posture management, and incident detection.

Honestly, the easiest way I’ve found to study this stuff is to think in layers. I usually tell learners to start with identity first, then move through access, governance, network security, secrets, data protection, and finally monitoring. Once you start thinking about Azure that way, it stops feeling like a random jumble of services and starts making a lot more sense. Honestly, a lot of Azure services sound pretty similar when you first come across them, and that’s usually where beginners get stuck. Sure, they all support security, but each one handles a different part of the puzzle. That’s why I really like side-by-side comparisons. That distinction is exactly where many exam questions live.

Shared Responsibility Model: What Microsoft Handles vs What You’re Still Responsible For

The shared responsibility model basically means Microsoft takes care of the cloud underneath everything, but you’re still on the hook for what you put into it, how you configure it, and who can get to it. That split is really important, and I’d definitely recommend keeping it in the back of your mind for AZ-900. Microsoft handles the physical datacenters, the hardware, the host layer, and the cloud fabric itself. In other words, they’re looking after the building, the racks, and the platform running underneath your workload. You, on the other hand, still have to protect your data, identities, endpoints, access permissions, and the security settings on your Azure resources. That’s the part a lot of people underestimate when they first move to cloud.

The split changes by service type:

  • IaaS: You manage the most. Take Azure Virtual Machines as an example. Microsoft secures the physical host and the platform, but you’re still responsible for the guest operating system, access controls, application settings, data, and network protections like NSGs and firewalls. So anyway, the VM is not a “set it and forget it” service. Azure can help you coordinate patching with things like Azure Update Manager or automatic guest patching, which is handy, honestly. But that doesn’t move the responsibility away from you — you still need to know what’s being patched, when it’s happening, and whether it actually worked.
  • PaaS: Microsoft manages more of the platform. Even in PaaS, you’re still responsible for identities, app settings, secrets, data, and whether the service is exposed publicly or not. Microsoft runs more of the platform, sure, but you still make the security decisions that matter. For example, if you’re using Azure SQL Database or Azure App Service, you’re not patching the underlying operating system yourself, which is a nice relief, honestly. But you’re still deciding who can connect, whether public access should stay on, and where your secrets should live. And yeah, that’s a common exam trap.
  • SaaS: Microsoft manages most of the application stack, but you still manage users, data governance, tenant settings, and access policies.

Exam clue: Cloud does not mean Microsoft handles all security. In almost every model, the customer still owns identity, data, and configuration choices.

Core Security Principles You Should Recognize

Three ideas appear repeatedly in Azure security questions:

  • CIA triad: confidentiality, integrity, and availability
  • Defense in depth: multiple layers instead of one control
  • Zero Trust: verify explicitly, use least privilege, assume breach

In Azure, confidentiality is protected through identity controls, encryption, and good secret management. Integrity is supported by governance, logging, controlled changes, and limited permissions. Availability is supported by resilient design, monitoring, and services such as DDoS protection. Zero Trust matters especially because identity is a major security boundary in cloud environments.

Identity, Authentication, and Authorization

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft’s cloud identity service. It manages users, groups, applications, and sign-in. It also supports identity-related authorization scenarios for directory and app access, but for AZ-900 the key distinction is this: Entra ID is the identity provider, while Azure RBAC is the main authorization system for Azure resource management.

Authentication answers who are you? Authorization answers what can you do? Signing in to the Azure portal is authentication. Being allowed to read or modify a subscription is authorization.

It also helps to know that an Azure environment is tied to an Entra tenant, which is the identity boundary for users, groups, and applications. Subscriptions trust that tenant for identity. So a user signs in through Entra ID, and then RBAC role assignments decide what Azure resources they can actually access.

MFA, Conditional Access, and managed identities come up all the time, and they’re easy to mix up if you’re not paying close attention.

Multi-factor authentication (MFA) adds an extra verification step beyond just a password. If an exam question says users must provide an additional verification method, that’s your cue to think MFA right away. That’s the kind of wording Microsoft loves to use.

Conditional Access is a policy engine in Microsoft Entra that evaluates sign-in conditions and can allow access, block access, or require controls such as MFA. Those conditions can include the user or group, the application they’re using, their location, the device state, and in some environments even sign-in risk or user risk. So it’s not just “username and password” anymore. Risk-based scenarios depend on appropriate Entra licensing and Identity Protection capabilities, so not every Conditional Access feature exists in every license tier.

Managed identities are one of the most practical Azure security features to understand. They let Azure resources authenticate to other services without storing credentials in code or configuration files. This is commonly used with Key Vault. Instead of saving a password in an app setting, the app can use its managed identity to request the secret securely.

Exam pattern:

  • Need sign-in and identity? Microsoft Entra ID
  • Need an extra verification step? MFA
  • Need policy-based sign-in controls? Conditional Access
  • Need an Azure resource to authenticate without stored credentials? Managed identity

AAzure RBAC is basically about who’s allowed to do what.

Azure Role-Based Access Control (RBAC) controls permissions to Azure resources. Role assignments can be applied at four main scopes: management group, subscription, resource group, and resource. Permissions assigned at a higher scope are inherited by lower scopes.

Common built-in roles include:

  • Reader: view resources
  • Contributor: create and manage resources, but not grant access
  • Owner: full management access, including access delegation

Least privilege matters here. Many real-world mistakes come from assigning Contributor or Owner too broadly when Reader or a narrower role would be enough.

RBAC is not the same as Azure Policy. RBAC controls who can perform actions. Policy controls what is allowed to be deployed or configured.

A useful practical distinction is management plane vs data plane. Azure RBAC is mainly used for management-plane access to Azure resources, although some services also use it for data-plane access too. For AZ-900, the big thing to remember is that RBAC is about permission to manage resources. So if an exam question is about managing Azure resources, RBAC is usually the answer. Not always, of course, but more often than not, that’s the direction you want to go.

Governance Controls: Policy and Locks

Azure Policy enforces organizational standards. It can deny, audit, append, modify, or deployIfNotExists depending on the policy effect. Policies can be grouped into initiatives and assigned at management group, subscription, resource group, or resource scope.

Typical examples include requiring tags, restricting allowed regions, auditing unencrypted resources, or denying public IP creation for sensitive workloads. Policy is governance, not permission management.

Resource locks protect important resources from management-plane changes:

  • CanNotDelete: allows reads and modifications but blocks deletion
  • ReadOnly: blocks modifications and deletions

Locks are not a permission model, but they can override what RBAC would otherwise allow for protected management operations. They are designed to protect against mistakes and unauthorized change at the control plane, not to replace identity and access controls.

Defender for Cloud, Secure Score, and Sentinel

Microsoft Defender for Cloud provides cloud security posture management (CSPM) and, when Defender plans are enabled, cloud workload protection capabilities. It is not just “awareness.” It helps assess security posture, surface recommendations, improve configuration, and provide threat protection for supported Azure, hybrid, and some multicloud resources.

One key concept is Secure Score. Secure Score is a number in Defender for Cloud that gives you a quick sense of how closely your environment lines up with Microsoft’s security recommendations. I’ve seen teams use it as a fast way to tell whether their security posture is getting better or starting to slip. If a question mentions recommendations, posture improvement, or secure score, think Defender for Cloud.

Microsoft Sentinel is a cloud-native SIEM and SOAR solution. It pulls in data from different sources, analyzes it, creates incidents, supports investigation and hunting, and can even automate some responses with playbooks. That’s a lot of capability, but for fundamentals you only need the big picture. At the fundamentals level, just remember this: Sentinel is for security analytics and incident response, and it commonly works with Azure Monitor and Log Analytics data underneath. You don’t need to get lost in the plumbing for AZ-900.

Key Vault, Encryption, and Data Protection

Azure Key Vault stores and manages sensitive material:

  • Secrets: passwords, tokens, connection strings
  • Keys: cryptographic keys
  • Certificates: digital certificates

Key Vault access can be controlled through Azure RBAC or legacy Key Vault access policies, depending on configuration. For AZ-900, the main idea is really simple: if the question is about securely storing credentials, keys, or certificates, think Key Vault. That’s the service I’d reach for first in an exam scenario.

Best practice is to combine Key Vault with managed identities so applications can retrieve secrets without embedding credentials in code. Important protection features include soft delete and purge protection, which help recover or protect deleted vault content.

Azure security also includes encryption at rest and encryption in transit. Many Azure services support encryption at rest by default using Microsoft-managed keys, and some services support customer-managed keys for additional control. Encryption in transit usually means using something like TLS to protect data while it’s traveling across the network. Basically, it helps keep traffic private while it moves from one place to another.

Network Security in Azure: The Decision Framework

Azure networking starts with a virtual network (VNet), which is your private network in Azure. Inside a VNet, you create subnets to separate workloads such as web, application, data, and management layers. Segmentation reduces unnecessary communication paths and helps you apply least privilege at the network level. In practice, that means workloads only talk where they actually need to.

A simple three-tier pattern might use:

  • Web subnet for internet-facing application entry
  • App subnet for business logic
  • Data subnet for databases or private services
  • Management path for administrators through Bastion instead of public RDP or SSH

The most important distinction is this: NSGs are stateful Layer 3/4 filters, Azure Firewall is centralized stateful network/application filtering, and WAF protects HTTP/HTTPS traffic at Layer 7.

NSGs, Azure Firewall, WAF, and DDoS Protection can sound pretty similar at first, but each one solves a different problem.

Network Security Groups (NSGs) use rule-based, stateful 5-tuple filtering: source, source port, destination, destination port, and protocol. They can be associated with a subnet or NIC. They have default inbound and outbound rules, and custom rules are evaluated by priority. If a question is about allowing HTTPS to a web subnet or blocking direct access to a database subnet, NSG is usually the right call. This is one of the clearest exam-style patterns.

Azure Firewall is a managed, centralized firewall service used for broader traffic control. It supports network rules, application rules, and DNAT, and it’s often used for centralized inbound and outbound filtering in hub-and-spoke designs. For AZ-900, you don’t need the design details — just know it’s the centralized firewall option. Compared with NSGs, Azure Firewall is more centralized and policy-driven. That difference matters a lot when you’re deciding which service the question is pointing to.

Web Application Firewall (WAF) in Azure is not a generic standalone firewall product. It is a feature of services such as Azure Application Gateway and Azure Front Door. WAF checks web traffic for common Layer 7 attacks like SQL injection and cross-site scripting. That’s why it’s especially useful when you’ve got a web app exposed to the internet. If the question is about protecting a web app from common web exploits, choose WAF rather than Azure Firewall.

Azure DDoS protection focuses on availability. Azure includes baseline DDoS infrastructure protection by default, while enhanced DDoS protection capabilities are available through DDoS protection offerings. This is about absorbing and mitigating attack floods, not replacing firewalls or WAF.

Bastion, VPN Gateway, ExpressRoute, and Private Access

Azure Bastion provides secure RDP/SSH access to virtual machines over TLS through Azure-managed access without requiring public IP addresses on the VMs. It is for administration, not network-to-network connectivity. A related concept is Just-In-Time VM access in Defender for Cloud, which helps reduce exposure of management ports by opening them only when needed.

VPN Gateway provides encrypted connectivity over the internet and supports site-to-site, point-to-site, and VNet-to-VNet scenarios. ExpressRoute provides private dedicated connectivity to Azure. It is private connectivity, not simply “a faster VPN,” and unlike VPN, privacy does not automatically mean internet-style encryption by default.

Private Link enables private access to supported Azure services. A private endpoint is a network interface in your VNet with a private IP address that privately maps to a specific Azure service. Traffic stays on Microsoft’s backbone rather than traversing the public internet.

A very common exam confusion is private endpoints vs service endpoints. Service endpoints extend a VNet identity to an Azure service over the Azure backbone but still access the service’s public endpoint. Private endpoints give the service a private access path through a private IP in your VNet. If the question emphasizes private IP-based access and reduced public exposure, choose Private Endpoint.

Azure Monitor, Logs, and Security Visibility

Azure Monitor is the broader monitoring platform for metrics, logs, and alerts. Activity Log helps track subscription-level control-plane events such as resource creation or deletion. Diagnostic settings send platform logs and metrics from Azure resources to destinations such as Log Analytics workspaces. Log Analytics provides the workspace and query layer used by many monitoring and security solutions.

At a fundamentals level, think of the relationship like this:

  • Azure Monitor: platform monitoring and telemetry
  • Defender for Cloud: posture management and protection recommendations
  • Sentinel: security analytics, incidents, and response

Practical Walkthrough: Securing a Three-Tier Azure App

Imagine a web app in Azure. Internet users first hit Azure Front Door or Application Gateway with WAF enabled in front of the web tier. DDoS protection helps preserve availability. The web, app, and data layers sit in different subnets. NSGs restrict allowed traffic between those tiers. Azure Firewall provides centralized filtering where broader control is needed.

Admins do not use public RDP/SSH. They connect through Azure Bastion. The application authenticates with a managed identity and retrieves secrets from Key Vault. The database or storage account uses a private endpoint so traffic stays private. Microsoft Entra ID handles user identity, Conditional Access can require MFA, and RBAC controls admin permissions. Azure Policy enforces rules such as approved regions or required tags. Defender for Cloud shows posture recommendations and secure score, while Sentinel analyzes events and incidents.

Troubleshooting Security and Access Problems — or, as I like to think of it, figuring out which layer is actually causing the headache.

If something fails in Azure, I usually tell people to work through the layers in order. Start with identity, then permissions, then policy, then network, and only after that start assuming the application itself is broken.

  • User can sign in but cannot access a resource: check RBAC role assignment and scope inheritance first. Authentication may be working while authorization is missing.
  • Sign-in is blocked unexpectedly: check Conditional Access policies, MFA requirements, trusted locations, or device compliance conditions.
  • Deployment is denied: check Azure Policy assignments and effects such as deny.
  • Critical resource cannot be edited or deleted: check for a ReadOnly or CanNotDelete lock.
  • VM is unreachable: check NSG rules, routing, firewall path, Bastion configuration, and whether public management access was intentionally removed.
  • App cannot reach a private service: check private endpoint DNS resolution and whether the app is using the correct private name resolution path.
  • App cannot retrieve a secret: check managed identity configuration and Key Vault authorization.

A good security operations example is the difference between Defender for Cloud and Sentinel: Defender for Cloud might recommend enabling Just-In-Time VM access or closing public exposure, while Sentinel might later correlate suspicious sign-in or network events into an incident for investigation.

Most Common AZ-900 Security Traps

Entra ID vs RBAC: Entra ID proves identity; RBAC grants Azure resource permissions.

RBAC vs Policy: RBAC controls access; Policy enforces standards.

Policy vs Locks: Policy governs deployment and compliance; locks protect existing resources from management-plane changes.

NSG vs Azure Firewall vs WAF: NSG filters subnet/NIC traffic, Azure Firewall centralizes filtering, WAF protects web apps from Layer 7 attacks.

Defender for Cloud vs Sentinel: Defender for Cloud is posture and protection; Sentinel is SIEM/SOAR and incident response.

Bastion vs VPN Gateway: Bastion is for secure VM administration; VPN Gateway is for encrypted connectivity between users or networks and Azure.

Private Endpoint vs ExpressRoute: Private Endpoint gives private access to a specific service; ExpressRoute provides private connectivity to Azure more broadly.

Key Vault vs Entra ID: Key Vault stores secrets and keys; Entra ID manages sign-in and identity.

What AZ-900 Expects You to Know

You should know: service purpose, high-level distinctions, common scenarios, and which Azure tool fits which requirement.

You are usually not expected to know: advanced rule syntax, deep implementation detail, or full enterprise architecture design.

Use category-based memorization:

  • Identity: Entra ID, MFA, Conditional Access, managed identities
  • Permissions and governance: RBAC, Policy, locks
  • Network: NSG, Azure Firewall, WAF, DDoS, Bastion, VPN Gateway, ExpressRoute, Private Endpoint
  • Secrets and protection: Key Vault, encryption
  • Monitoring and response: Azure Monitor, Defender for Cloud, Sentinel

Last-Minute AZ-900 Security Cram Sheet

If you see sign-in, directory, user identity → Microsoft Entra ID

If you see permissions, role, scope → Azure RBAC

If you see require MFA, block by location, device condition → Conditional Access

If you see required tags, allowed regions, deny deployment → Azure Policy

If you see prevent deletion or make read-only → Resource lock

If you see store password, key, certificate securely → Key Vault

If you see recommendations, secure score, posture → Defender for Cloud

If you see SIEM, incident investigation, analytics, playbooks → Sentinel

If you see subnet or NIC traffic filtering → NSG

If you see centralized traffic filtering → Azure Firewall

If you see SQL injection, XSS, web attacks → WAF

If you see availability during traffic flood → DDoS protection

If you see secure VM access without public RDP/SSH → Bastion

If you see encrypted tunnel over the internet → VPN Gateway

If you see private dedicated connectivity → ExpressRoute

If you see private IP access to Azure PaaS service → Private Endpoint / Private Link

The best AZ-900 mindset is simple: group services by purpose, not by product name. Once you can separate identity, permissions, governance, network controls, secrets, and monitoring, Azure security becomes much easier to recognize on the exam and in real-world conversations.