This chapter covers Zero Trust Architecture in Azure, a foundational security model that underpins all modern identity and access management. For the AZ-500 exam, Zero Trust principles appear in roughly 15-20% of questions, especially those related to identity, access policies, and network security. You will learn the core components—verify explicitly, least privilege, assume breach—and how Azure services like Azure AD Conditional Access, Azure Policy, and network micro-segmentation implement them. This is not a theoretical overview; we will dive into the specific mechanisms, default values, and configuration commands you need to know to pass the exam.
Jump to a section
Imagine a VIP club that used to have a single bouncer at the front door who checked IDs and then let everyone inside roam freely. After a few incidents where guests who passed the front check started causing trouble backstage, the club changed its policy. Now, every single door inside the club has its own bouncer. To enter any room—the bar, the dance floor, the VIP lounge, or even the bathroom—you must present a valid, time-limited pass that is checked against a central security system. The bouncer also verifies your identity using a biometric scan and checks that you are not on any watchlist. Even if you came in through the main entrance, you cannot access the manager's office unless you have explicit authorization. The club also logs every attempt to open any door, and if someone tries to enter a room without permission, an alarm triggers and security is alerted immediately. This is exactly how Zero Trust works: trust is never assumed based on location (inside the network); every access request is fully authenticated, authorized, and encrypted, regardless of where it originates or where it's going.
What is Zero Trust Architecture and Why Does It Exist?
Zero Trust Architecture (ZTA) is a security model that eliminates implicit trust in any user, device, or network segment. Traditional perimeter-based security assumed that anything inside the corporate network was trustworthy. This led to lateral movement attacks where a single compromised endpoint could lead to a full breach. Zero Trust flips this: no entity is trusted by default, regardless of its location. The model is defined by three core principles from NIST SP 800-207:
Verify explicitly: Always authenticate and authorize based on all available data points (user identity, device health, location, behavior).
Least privilege: Grant only the minimum necessary access for the minimum time needed.
Assume breach: Design the network and policies as if a breach has already occurred, segmenting access and monitoring continuously.
Microsoft's Zero Trust deployment model maps these principles to six pillars: Identities, Devices, Applications, Data, Infrastructure, and Network. On the AZ-500 exam, you will be tested on how Azure services implement each pillar.
How Azure Implements Zero Trust: The Mechanism
Azure achieves Zero Trust through a combination of identity-driven policies, network micro-segmentation, and continuous monitoring. The key enabler is Azure Active Directory (Azure AD) as the central policy decision point (PDP) and policy enforcement point (PEP). When a user requests access to a resource, the following steps occur at the protocol level:
Authentication: The user presents credentials to Azure AD. Azure AD validates the identity and checks for risk signals (e.g., impossible travel, anonymous IP). If MFA is required by Conditional Access policy, Azure AD prompts for additional verification.
Authorization: After authentication, Azure AD evaluates Conditional Access policies. These policies consider user/group membership, device compliance (via Intune), location (IP range), application sensitivity, and sign-in risk. If the policy allows access, Azure AD issues a token (JWT) with claims that include the user's roles and permissions.
Resource access: The user presents the token to the resource (e.g., an Azure App Service, Storage Account, or API). The resource validates the token and enforces any additional authorization (e.g., Azure RBAC roles assigned to the user).
Network segmentation: Even if the user has a valid token, network-level policies (Azure Firewall, NSGs, ASGs) enforce micro-segmentation. For example, a VM in a backend subnet may only accept traffic from a specific application subnet, not from the user's client directly.
Continuous monitoring: Azure AD Identity Protection and Microsoft Defender for Cloud monitor for anomalous behavior after access is granted. If risk is detected, policies can force re-authentication or terminate sessions.
Key Components, Defaults, and Timers
Azure AD Conditional Access: The primary tool for implementing "verify explicitly." Default values: - Session controls: Use app-enforced restrictions, Conditional Access App Control, and sign-in frequency (default: 90 days for persistent browser sessions, but configurable per policy). - Grant controls: Require MFA, require device to be marked compliant, require approved client app, or require password change. Multiple controls can be combined with AND/OR. - Conditions: Sign-in risk (low, medium, high), user risk, device platforms, locations (named locations or MFA trusted IPs), client apps, and filter for devices.
Azure Policy: Enforces least privilege at the resource level. Default: - Effect: Deny (default) or Audit. Deny prevents creation of non-compliant resources. - Policy definitions: Built-in policies like "Allowed locations" or "Require SQL Server encryption." Custom policies use JSON.
Azure RBAC: Implements least privilege for management plane. Default: - Owner: Full access (least privileged is Contributor). - Custom roles: Define specific actions (e.g., only read VMs). - Deny assignments: Explicitly block actions even if a role allows them (e.g., block creation of public IPs).
Network micro-segmentation: - Network Security Groups (NSGs): Stateful, default allow inbound from virtual network and load balancer, default deny all other inbound. Outbound default allow all. Default rules cannot be deleted but have lower priority than custom rules. - Application Security Groups (ASGs): Group VMs by application role (e.g., web, app, data). NSG rules reference ASGs instead of IP addresses. - Azure Firewall: Stateful, with threat intelligence-based filtering enabled by default (alert mode). Default allow outbound to Azure services.
Azure AD Identity Protection: Default user risk policy: off. Sign-in risk policy: off. Recommended settings: enable for high risk.
Configuration and Verification Commands
To configure Zero Trust policies, you use Azure CLI, PowerShell, or the portal. Key commands:
Conditional Access policy via Azure CLI:
az rest --method post --uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" --body '{
"displayName": "Require MFA for admins",
"state": "enabled",
"conditions": {
"users": { "includeUsers": ["admin-group-id"] },
"applications": { "includeApplications": ["All"] }
},
"grantControls": { "builtInControls": ["mfa"] }
}'Azure Policy assignment:
az policy assignment create --name "deny-public-ip" --policy "built-in-policy-definition-id" --scope "/subscriptions/sub-id/resourceGroups/myRG" --params '{"effect":{"value":"Deny"}}'NSG rule creation:
$nsg = Get-AzNetworkSecurityGroup -Name "myNSG" -ResourceGroupName "myRG"
$rule = New-AzNetworkSecurityRuleConfig -Name "AllowHTTP" -Protocol Tcp -Direction Inbound -Priority 100 -SourceAddressPrefix "VirtualNetwork" -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 80 -Access Allow
$nsg.SecurityRules.Add($rule)
Set-AzNetworkSecurityGroup -NetworkSecurityGroup $nsgVerification:
- Use az ad conditional-access policy list to list policies.
- Use Get-AzPolicyAssignment to check policy assignments.
- Use Get-AzNetworkSecurityGroup -Name myNSG | Get-AzNetworkSecurityRuleConfig to view rules.
- Use az monitor activity-log list to review policy enforcement logs.
Interaction with Related Technologies
Zero Trust in Azure does not operate in isolation. It integrates with: - Microsoft Defender for Cloud: Provides continuous assessment of workloads against Zero Trust benchmarks (e.g., CIS, NIST). Alerts on misconfigurations like open management ports. - Azure Sentinel: Aggregates logs from Azure AD, Azure Firewall, and Defender for Cloud to detect attack patterns. Uses UEBA to identify anomalous behavior. - Azure AD Application Proxy: Enables Zero Trust access to on-premises apps without VPN. Users authenticate via Azure AD, and traffic is proxied through the service. - Microsoft Intune: Enforces device compliance. Only managed devices with compliant health (encryption, patching) are granted access. - Azure Bastion: Provides secure RDP/SSH access to VMs without exposing public IPs. Uses Azure AD authentication and RBAC.
On the exam, expect questions that combine these services. For example, a scenario where a user's device is not compliant with Intune policies, so Conditional Access blocks access to an app, and the solution requires enrolling the device in Intune.
Identify and classify resources
Begin by cataloging all data, applications, and infrastructure in your Azure environment. Use Azure Resource Graph to query resources across subscriptions. Classify data sensitivity using Azure Purview or manual tagging. For each resource, determine the required security controls (encryption, access restrictions). This step is critical because Zero Trust policies are resource-centric. Without a clear inventory, you cannot define appropriate access policies. In the exam, you may be asked to recommend a solution for a company that lacks visibility into its cloud assets. The correct answer is to use Azure Resource Graph and Purview for discovery and classification.
Define access policies with Conditional Access
Based on resource classification, create Conditional Access policies in Azure AD. Each policy specifies who (users/groups), what (applications), and under which conditions (device compliance, location, risk) access is allowed. Use the report-only mode initially to test policies without blocking users. For example, a policy might require MFA for all admins accessing the Azure portal from outside the corporate network. The exam often tests the difference between 'report-only' and 'enabled' modes, and the fact that report-only logs results but does not enforce. Also remember that Conditional Access policies apply to cloud apps; for on-prem apps, you need Azure AD Application Proxy.
Implement least privilege with Azure RBAC
Assign the minimum permissions needed for each user or service principal. Use built-in roles (Reader, Contributor, Owner) as starting points, but create custom roles for fine-grained control. For example, a custom role that allows only restarting VMs. Use Azure AD Privileged Identity Management (PIM) to provide just-in-time (JIT) access to elevated roles. PIM requires approval for activation and sets a maximum duration (default 8 hours). The exam loves to test that PIM is the solution for 'permanent access' issues. Also remember that deny assignments (e.g., via Azure Blueprints or management groups) override role assignments, which is a common trap.
Segment network with micro-perimeters
Design virtual networks (VNets) with subnets for different tiers (web, app, data). Use NSGs and ASGs to restrict traffic between tiers. For example, allow inbound HTTP only to the web subnet, and allow the web subnet to communicate only with the app subnet on port 443. Use Azure Firewall for centralized egress filtering and threat intelligence. In production, you might also use VNet service endpoints or Private Link to access Azure PaaS services privately. The exam often asks about the difference between NSGs (stateful, per subnet/NIC) and Azure Firewall (stateful, centralized). A common wrong answer is to use NSGs for all traffic; the correct approach is to use Azure Firewall for outbound and inter-VNet traffic at scale.
Monitor and respond continuously
Enable logging for all components: Azure AD sign-in logs, NSG flow logs, Azure Firewall logs, and Azure Policy compliance data. Stream these to Azure Sentinel or a SIEM. Set up alerts for anomalous activities, such as multiple failed sign-ins (Azure AD Identity Protection) or outbound traffic to known malicious IPs (Azure Firewall threat intelligence). Use automated responses like Azure Logic Apps to trigger remediation (e.g., block user, isolate VM). The exam emphasizes that monitoring is a continuous process, not a one-time setup. A common question: 'What should you enable to detect brute force attacks on Azure AD?' Answer: Azure AD Identity Protection sign-in risk policy with medium risk threshold.
Enterprise Scenario 1: Financial Services Company Migrating to Azure
A large bank is moving its trading applications to Azure. The security team mandates Zero Trust because of strict regulatory requirements (PCI-DSS, SOX). They deploy Azure AD Conditional Access to require MFA and compliant devices for all traders accessing the trading app. They use Azure Policy to deny creation of resources outside approved regions (e.g., only US East and West). Network segmentation is achieved with multiple VNets: one for web servers, one for application servers, and one for databases. NSGs allow only necessary ports between tiers. Azure Firewall is used to inspect all outbound traffic and block known malicious IPs. Azure Sentinel ingests logs from all sources and uses UEBA to detect insider threats. The biggest challenge was integrating on-premises Active Directory with Azure AD using Azure AD Connect, and ensuring that all legacy apps were either migrated to use Azure AD or proxied via Azure AD Application Proxy. Misconfiguration of Conditional Access policies initially blocked legitimate traders because they were using personal devices that were not enrolled in Intune. The fix was to create a policy that requires device compliance only for high-risk transactions, not all access.
Enterprise Scenario 2: Healthcare Provider with Hybrid Environment
A hospital network uses a mix of on-premises and Azure resources. Patient data is stored in Azure SQL Database, and doctors access it via a web app. Zero Trust is required for HIPAA compliance. They use Azure AD B2B for external partners (insurance companies) and Conditional Access to block access from untrusted locations. Azure RBAC is used to grant doctors read-only access to patient records, while nurses have write access. Azure Policy enforces encryption at rest for all SQL databases. Network-wise, they use Azure Bastion for secure RDP access to management VMs, eliminating the need for public IPs. They also use Private Link to connect on-premises networks to Azure SQL Database privately. A common issue was that some doctors were using outdated browsers that did not support modern authentication, causing access failures. The solution was to require the use of the Microsoft Edge browser or the Microsoft Authenticator app for MFA.
Scenario 3: E-commerce Company Scaling Globally
An e-commerce company with millions of users uses Azure for its website and backend services. They implement Zero Trust to protect customer payment data (PCI-DSS). They use Azure Front Door as a global load balancer with WAF policies to block SQL injection and XSS. Conditional Access policies are used to protect the admin portal, requiring MFA and device compliance. For the public-facing site, they use Azure AD B2C for customer identity, which supports social logins. Azure Policy ensures that all storage accounts have HTTPS enforced. Network micro-segmentation is achieved with AKS network policies for containerized microservices. The biggest performance consideration was latency: requiring MFA for every admin action slowed down operations. They used PIM to allow JIT elevation for critical tasks. Misconfiguration of NSG rules accidentally allowed SSH from the internet to a jump box, which was quickly remediated by enabling just-in-time VM access in Defender for Cloud.
What AZ-500 Tests on Zero Trust
The AZ-500 exam covers Zero Trust under objective 1.4 (Identity Access) and also appears in sections on network security and security operations. Specifically, you need to know: - Azure AD Conditional Access policies: How to configure, the difference between 'grant' and 'session' controls, and the use of 'report-only' mode. - Azure AD Identity Protection: User risk and sign-in risk policies, risk levels (low, medium, high), and how they integrate with Conditional Access. - Azure Policy: Effects (Deny, Audit, Append, etc.), initiative vs. policy definition, and how to enforce compliance. - Azure RBAC: Built-in roles, custom roles, deny assignments, and PIM. - Network security: NSGs, ASGs, Azure Firewall, and JIT VM access.
Common Wrong Answers and Why Candidates Choose Them
Using Azure Policy to block user access: Candidates often confuse Azure Policy (which controls resource configuration) with Conditional Access (which controls user access). The correct answer is that Azure Policy cannot block a user from signing in; it can only prevent creation of non-compliant resources.
Placing all VMs in the same subnet with NSGs: Some think that NSGs are sufficient for segmentation. The exam expects you to use separate subnets for different tiers, with NSGs on each subnet. A single subnet with NSGs is less secure because lateral movement within the subnet is allowed.
Using MFA only for external users: The principle of 'verify explicitly' applies to all users, including admins. The exam will present a scenario where only external users have MFA, and you must identify that internal admins also need MFA.
Assuming on-premises network is trusted: Zero Trust assumes no implicit trust, even for on-premises networks. A common trap is to allow all traffic from on-premises without authentication.
Specific Numbers and Terms on the Exam
Default Conditional Access sign-in frequency: 90 days for persistent browser sessions (configurable).
PIM activation maximum duration: 8 hours (configurable up to 24 hours).
NSG default inbound rules: AllowVNetInBound (priority 65000), AllowAzureLoadBalancerInBound (65001), DenyAllInbound (65500).
Azure Firewall threat intelligence mode: Alert (default) or Deny.
Azure AD Identity Protection risk levels: Low, Medium, High. The exam asks which level triggers a policy.
Edge Cases and Exceptions
Guest users: Conditional Access policies apply to guest users (B2B) but you must ensure external identities are covered.
Service principals: Conditional Access cannot directly target service principals; use Azure AD app roles and RBAC instead.
Break-glass accounts: These emergency admin accounts should be excluded from Conditional Access policies to prevent lockout, but they must be monitored closely.
Device compliance: Conditional Access requires devices to be registered in Azure AD and compliant with Intune policies. For unmanaged devices, you can require MFA only.
How to Eliminate Wrong Answers
On the exam, read the scenario carefully. If the question asks about 'blocking a user from accessing a resource,' the solution involves Conditional Access or RBAC, not Azure Policy. If the question mentions 'preventing creation of unencrypted storage accounts,' use Azure Policy with Deny effect. If the question says 'reduce lateral movement,' think network segmentation with NSGs and separate subnets. For 'temporary elevated access,' think PIM. For 'continuous monitoring,' think Sentinel or Defender for Cloud. Always map the requirement to the correct Azure service.
Zero Trust is based on three principles: verify explicitly, least privilege, assume breach.
Azure AD Conditional Access is the primary tool for 'verify explicitly' and can require MFA, compliant device, or approved app.
Azure Policy enforces resource compliance (e.g., encryption, location) using effects like Deny and Audit.
Azure RBAC with PIM implements least privilege for management access; PIM provides just-in-time elevation.
Network segmentation uses NSGs (stateful, per subnet/NIC) and Azure Firewall (centralized, with threat intelligence).
Azure AD Identity Protection detects risky sign-ins and users; policies can automatically block or require MFA.
Default Conditional Access sign-in frequency is 90 days for persistent browser sessions.
NSG default inbound rules: AllowVNetInBound (65000), AllowAzureLoadBalancerInBound (65001), DenyAllInbound (65500).
Azure Firewall threat intelligence mode defaults to Alert; can be changed to Deny.
Break-glass accounts should be excluded from Conditional Access policies to prevent lockout.
Azure AD Application Proxy enables Zero Trust access to on-premises apps without VPN.
Azure Bastion provides secure RDP/SSH to VMs without public IPs, using Azure AD authentication.
These come up on the exam all the time. Here's how to tell them apart.
Conditional Access
Controls user access to applications and actions
Evaluates user, device, location, and risk signals
Uses grant controls (require MFA, compliant device) and session controls
Applies at the Azure AD tenant level
Can block sign-in or require additional verification
Azure Policy
Controls resource configuration and compliance
Evaluates resource properties (e.g., encryption, region)
Uses effects like Deny, Audit, Append, DeployIfNotExists
Applies at management group, subscription, or resource group scope
Can prevent creation of non-compliant resources or remediate existing ones
NSG
Stateful packet filtering at subnet or NIC level
No logging by default (must enable flow logs)
No threat intelligence
No centralized management (per subnet/NIC)
Free (no additional cost)
Azure Firewall
Stateful inspection with application (FQDN) and network rules
Built-in logging and analytics
Threat intelligence-based filtering (alert or deny)
Centralized policy management across VNets
Paid service (hourly + data processing)
Azure AD Identity Protection
Focuses on identity-based risks (sign-in and user risk)
Automatically detects risky sign-ins and compromised users
Integrates with Conditional Access for automated remediation
Uses machine learning to calculate risk scores
No custom analytics rules
Microsoft Sentinel
SIEM/SOAR for all security logs (network, app, infrastructure)
Allows custom analytics rules and threat hunting
Can integrate with Identity Protection but covers more data sources
Uses UEBA for behavioral analytics
Requires manual configuration of data connectors
Mistake
Zero Trust means no one is trusted, so you need to block all traffic.
Correct
Zero Trust does not block all traffic; it requires explicit verification for every access request. The goal is to allow access after thorough authentication and authorization, not to block everything.
Mistake
Once a user passes Conditional Access, they can access all resources.
Correct
Conditional Access grants access to specific applications or actions. Additional policies (RBAC, network rules) may restrict what the user can do within that app. Access is not universal.
Mistake
Azure Policy is used to control user access to resources.
Correct
Azure Policy controls resource configuration (e.g., enforce encryption), not user access. User access is controlled by Azure RBAC and Conditional Access.
Mistake
NSGs provide the same level of segmentation as separate VNets.
Correct
NSGs filter traffic within a VNet but cannot prevent traffic between VNets unless you use VNet peering with route tables or Azure Firewall. Separate VNets provide stronger isolation.
Mistake
MFA is only required for external users.
Correct
Zero Trust requires MFA for all users, especially administrators. Internal users should also be subject to MFA policies based on risk.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Conditional Access controls user access to applications and actions based on identity, device, location, and risk. It can require MFA, block sign-in, or enforce session controls. Azure Policy controls the configuration of Azure resources, such as requiring encryption or restricting regions. It can prevent creation of non-compliant resources or audit existing ones. In short, Conditional Access is about 'who can access,' while Azure Policy is about 'how resources are configured.' On the exam, if the question is about a user being blocked from an app, think Conditional Access; if it's about a storage account not being encrypted, think Azure Policy.
Zero Trust can extend to on-premises resources using Azure AD Application Proxy, which publishes on-premises web apps to the internet without a VPN. Users authenticate via Azure AD, and traffic is proxied through the service. Additionally, you can use Azure AD Domain Services or Azure AD Connect to sync identities and enforce Conditional Access policies on on-premises apps that support modern authentication. For non-web apps, you might use Azure AD joined devices with VPN but still require device compliance and MFA. The key is that trust is never assumed based on network location.
NSGs have default inbound rules: AllowVNetInBound (priority 65000) allows traffic within the virtual network, AllowAzureLoadBalancerInBound (65001) allows Azure load balancer health probes, and DenyAllInbound (65500) denies all other inbound traffic. Outbound default rules: AllowVNetOutBound (65000) allows outbound traffic to virtual network, AllowInternetOutBound (65001) allows outbound traffic to the internet, and DenyAllOutBound (65500) denies all other outbound. These default rules cannot be deleted but can be overridden by custom rules with lower priority numbers.
JIT access is implemented using Azure AD Privileged Identity Management (PIM) for management plane roles (e.g., Contributor, Owner). You configure eligibility, activation requirements (approval, MFA), and maximum duration (default 8 hours). Users activate the role when needed, and the access expires automatically. For VM access, you can use just-in-time VM access in Microsoft Defender for Cloud, which opens RDP/SSH ports via NSG rules only when requested and for a limited time. On the exam, remember that PIM is for Azure AD roles and Azure resource roles; JIT VM access is for network-level access to VMs.
User risk represents the probability that a user's identity has been compromised, based on signals like leaked credentials or suspicious activity associated with the user account. Sign-in risk represents the probability that a specific sign-in attempt is not authorized, based on signals like anonymous IP addresses, impossible travel, or unfamiliar sign-in properties. Both can be used in Conditional Access policies to require MFA or block access. Policies can be set to trigger at low, medium, or high risk levels. The default recommendation is to enable user risk policy for high risk and sign-in risk policy for medium and above.
Azure Firewall enforces Zero Trust by inspecting all traffic (inbound, outbound, and inter-VNet) with stateful filtering and application (FQDN) rules. It can deny traffic to known malicious IPs using threat intelligence feeds (alert or deny mode). It also integrates with Azure Monitor and Sentinel for logging and alerting. By centralizing firewall policies, you can enforce consistent rules across all VNets, ensuring that only explicitly allowed traffic flows. This supports the 'assume breach' principle by limiting lateral movement and preventing data exfiltration.
Azure AD B2B (business-to-business) enables you to invite external users (partners, vendors) to access your Azure resources. In a Zero Trust model, B2B users are treated the same as internal users: they must authenticate via Azure AD, and Conditional Access policies apply to them as well (e.g., require MFA, compliant device). You can also use cross-tenant access settings to control inbound and outbound trust. B2B is essential for implementing least privilege and explicit verification for external collaboration.
You've just covered Zero Trust Architecture in Azure — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?