Free AZ-500 Practice Test Questions and Answers (2026)

Azure Active Directory (Azure AD) Identity Protection categorizes risk detections into different levels to help administrators prioritize and automate responses.

• Users with leaked credentials is considered a High risk because it indicates that a user's valid credentials (username and password) have been exposed publicly on the dark web or through a data breach. This means an attacker has the direct ability to access the account, representing a severe and immediate threat.
• Impossible travel to atypical locations is classified as a Medium risk. This detection is triggered when two sign-ins from the same user occur from geographically distant locations in a time frame that is physically impossible. While highly suspicious, it's not rated as high because factors like using VPNs or misconfigured client reporting can sometimes cause false positives.
• Sign ins from IP addresses with suspicious activity is also a Medium risk. This event is triggered when a sign-in originates from an IP address associated with malicious activity, such as botnets or traffic from anonymous proxies (like Tor). This is a strong indicator of a potential attack, but it doesn't definitively prove the specific user's account is compromised, as malicious IP addresses can be part of a shared network.

Microsoft Entra ID Protection Documentation, "What are risk detections?": This official document provides a detailed list of user and sign-in risk detections and their corresponding risk levels.

Leaked credentials is explicitly listed as a user risk detection with a Risk level of High.

Impossible travel is listed as a sign-in risk detection with a Risk level of Medium.

Malicious IP address (the specific detection for "suspicious activity") is listed as a sign-in risk detection with a Risk level of Medium.

To annotate an intermediate event for hunting suspicious traffic in Microsoft Sentinel (formerly Azure Sentinel), you first query the data (Azure Log Analytics) from the Sentinel workspace. After obtaining and selecting the relevant result, you create a bookmark and map an entity (such as the IP address) so that it becomes part of the investigation graph and can be referenced in later steps. Adding to Favorites or tagging without mapping does not provide an entity reference for the graph.

Microsoft Learn, Hunt for threats with Microsoft Sentinel: Steps for running Log Analytics queries and bookmarking results with mapped entities (Create and use bookmarks) – https://learn.microsoft.com/en-us/azure/sentinel/hunting-bookmarks

Microsoft Learn, Investigation graph in Microsoft Sentinel: Explains how mapping an entity allows navigation in the investigation graph – https://learn.microsoft.com/en-us/azure/sentinel/investigate

Microsoft Learn, Kusto query language overview: Describes running queries in Log Analytics within Sentinel – https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/

Azure Front Door is a global, scalable entry-point that uses the Microsoft global edge network to create fast, secure, and widely scalable web applications. The solution requires both protection against common web vulnerabilities and optimized routing for global traffic. Azure Front Door Premium tier meets these requirements by providing global load balancing to route traffic to the lowest latency backend. It also includes a fully managed Web Application Firewall (WAF) that protects applications from common exploits and vulnerabilities, such as SQL injection and cross-site scripting. This combination of features in a single service directly addresses all the stated needs.

A. Azure Application Gateway: This is a regional load balancer. While it includes a WAF, it cannot optimize traffic routing for users across multiple global regions as effectively as a global service.
B. Azure Content Delivery Network (CDN): A CDN is primarily designed to cache and serve static content from edge locations. It does not provide the required comprehensive WAF protection or dynamic traffic routing capabilities.
C. Azure Firewall: This is a stateful network firewall designed to protect Azure Virtual Network resources. It operates at Layers 3 and 4 and is not a Web Application Firewall (WAF) for protecting against web-based attacks.

1. Microsoft Documentation, "What is Azure Front Door?": "Azure Front Door is a global, scalable entry-point that uses the Microsoft global edge network... Azure Front Door works at Layer 7 (HTTP/S layer) ... Key features include: ... Global load balancing ... Web Application Firewall (WAF)".

2. Microsoft Documentation, "Azure Front Door tier comparison": This document explicitly lists the features of the Standard and Premium tiers. The table shows that the Premium tier includes "Full-featured Web Application Firewall (WAF)" with "Bot protection," "Managed rule sets," and "Custom rules."

3. Microsoft Documentation, "What is Azure Web Application Firewall on Azure Front Door?": "Azure Web Application Firewall (WAF) on Azure Front Door provides centralized protection for your web applications. WAF defends your web services against common exploits and vulnerabilities."

4. Microsoft Documentation, "What is Azure Application Gateway?": "Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications. It's a regional service and all resources including the gateway are placed in a single virtual network." This confirms its regional scope, making it unsuitable for global traffic optimization.

URL filtering on VNet1: Azure Firewall's URL filtering is an Application Rule feature, not a Network Rule feature. Since VNet1 is associated with FW1, which uses Policy2, and Policy2 is a Premium policy, URL filtering is available. However, the statement asks about applying it to network rules, which is incorrect. URL filtering is a function of application rules, not network rules.

IDPS on VNet2: VNet2 is associated with FW2. FW2 is a Premium tier firewall. The Premium tier of Azure Firewall includes an IDPS, which can be used to monitor malicious activity. The statement is therefore true.

Encrypted traffic inspection: Azure Firewall can inspect encrypted traffic, but only if TLS inspection is enabled. For this to work, the client (VNet3 in this case) must trust the firewall's certificate authority, and the traffic must be routed to the firewall. The question implies that peering alone will cause encrypted traffic to be inspected. Peering simply allows connectivity; it doesn't automatically enable traffic routing through the firewall or TLS inspection. VNet3 has no firewall associated with it, so its traffic will not be inspected unless specifically routed and configured for TLS inspection, which isn't guaranteed by just peering.

Microsoft Azure Documentation. (2023). What is Azure Firewall Premium? Microsoft Docs. Retrieved from https://docs.microsoft.com/en-us/azure/firewall/premium-features

Specifically, the section on "TLS Inspection" and "IDPS" confirms these features are part of the Premium tier.

Microsoft Azure Documentation. (2023). Azure Firewall Rules. Microsoft Docs. Retrieved from https://docs.microsoft.com/en-us/azure/firewall/rule-processing

This document clarifies the distinction between Network rules and Application rules, with URL filtering being a function of Application rules.

Microsoft Azure Documentation. (2023). Azure Virtual Network Peering. Microsoft Docs. Retrieved from https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview

This source explains that VNet peering provides connectivity but does not automatically route traffic through a firewall. Specific user-defined routes (UDRs) are needed for this purpose.

The Microsoft Authenticator app is the only method listed that supports both number matching and the display of geographical location during a sign-in attempt. These features are part of the "additional context" available for push notifications, designed to enhance security. Number matching requires the user to type a number displayed on the sign-in screen into the app, preventing accidental approvals from MFA fatigue attacks. The geographical location, derived from the sign-in IP address, helps the user identify potentially fraudulent sign-in attempts from unexpected locations.

A. SMS sends a one-time passcode via text message and lacks the functionality for number matching or displaying geographical location.
B. A Temporary Access Pass is a time-limited passcode used for onboarding or account recovery, not a primary MFA method with these features.
D. A FIDO2 security key is a hardware-based, passwordless method that does not use an app interface to display number matching or location.

1. Microsoft Entra ID Documentation. (2023). How to use additional context in Microsoft Authenticator notifications. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/active-directory/authentication/how-to-mfa-additional-context. The section "Location" states, "The user’s location based on the IP address of the signing in device is displayed," and the section "Number matching" describes the feature.

2. Microsoft Entra ID Documentation. (2023). Authentication methods in Azure Active Directory - Microsoft Authenticator app. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-methods#microsoft-authenticator-app. This document outlines the capabilities of the Authenticator app, including "Push notification with number matching" as a primary authentication method.

The storage account allows Selected networks: only VNET3/Subnet3 and an IP range 52.233.129.0/24.

• VM1 (VNET1/Subnet1): Although the subnet has Microsoft.Storage service endpoint, it isn’t added to the storage account’s allowed VNets ⇒ denied. Azure requires the subnet to be added as a virtual network rule, which relies on a Storage service endpoint.

• VM2 (VNET2/Subnet2): No service endpoint. Without endpoints, traffic to Azure services uses the VM’s public IPv4 as source; the storage firewall IP rule (52.233.129.0/24) matches 52.233.129.82 ⇒ allowed.

• VM3 (VNET3/Subnet3): Subnet is added, but its endpoint is Microsoft.KeyVault (not Microsoft.Storage). A Storage virtual network rule works only when the subnet has a Storage service endpoint ⇒ denied. Also, where a service endpoint is used, IP rules don’t apply.

Microsoft Learn — Create a virtual network rule for Azure Storage (shows enabling Microsoft.Storage endpoint on the subnet to use VNet rules; includes command examples).

Microsoft Learn

Microsoft Learn — Azure virtual network service endpoints overview (before endpoints, service traffic from a VNet uses public IP; with endpoints it switches to private IP).

Microsoft Learn

Microsoft Learn — Azure Storage firewall rules (with a service endpoint, traffic uses private IP and IP rules no longer have effect)

To deploy Azure Disk Encryption, you first need a secure repository for the encryption keys, so you must create an Azure key vault. Before the encryption extension can use this vault, you must configure access policies (specifically enabling the EnabledForDiskEncryption setting) to grant the Azure platform permission to retrieve and back up secrets to that vault. Finally, you apply the encryption configuration to the virtual machine by running the Set-AzureRmVmDiskEncryptionExtension cmdlet (or its Az module equivalent), which triggers the BitLocker encryption process inside the guest OS.

Microsoft Learn: Create and configure a key vault for Azure Disk Encryption

Reference: "You can create a key vault... Enable the key vault for disk encryption... You must enable the key vault for disk encryption to allow Azure Disk Encryption to retrieve secrets."

Link: https://learn.microsoft.com/en-us/azure/virtual-machines/windows/disk-encryption-key-vault

Microsoft Learn: Enable Azure Disk Encryption for Windows VMs

Reference: "Enable encryption using the Set-AzVMDiskEncryptionExtension cmdlet... requires the Key Vault created in previous steps."

Link: https://learn.microsoft.com/en-us/azure/virtual-machines/windows/disk-encryption-windows

Azure Key Vault provides a specific, configurable feature named "rotation policy" for both keys and secrets. For keys, the rotation policy automates the generation of a new key version at a scheduled time or after a specific duration. For secrets, the rotation policy integrates with Azure Event Grid and automation services (like Azure Functions or Logic Apps) to manage the lifecycle of credentials such as database connection strings. While certificates have automated renewal capabilities, this is configured within the certificate's "Issuance Policy" through "Lifetime Actions," which is a distinct mechanism from the feature explicitly named "rotation policy" that applies to keys and secrets.

A. Key1 Only: This is incorrect because secrets also support a configurable rotation policy.
B. Cert1 only: This is incorrect. Certificates use an "Issuance Policy" for renewal, not a "rotation policy," and both keys and secrets support rotation policies.
D. Key1 and Cert1 only: This is incorrect because the feature for certificates is named "Issuance Policy," not "rotation policy," and secrets do support rotation.
E. Secret1 and Cert1 only: This is incorrect because keys support a rotation policy, and the feature for certificates is named differently.
F. Key1, Secret1, and Cert1: This is incorrect because the specific "rotation policy" feature, by name and implementation, applies to keys and secrets, not certificates.

1. Microsoft Documentation - Configure key auto-rotation in Azure Key Vault: "Azure Key Vault automates the rotation of keys in a key vault. When you configure a key rotation policy, you can customize the rotation frequency." (Section: "Key rotation policy")

2. Microsoft Documentation - Configure secret auto-rotation in Azure Key Vault: "Azure Key Vault automates the rotation of secrets for databases or services that use a username and password for authentication... You can set a rotation policy on a secret to schedule rotation..." (Section: "Secret rotation policy")

3. Microsoft Documentation - Tutorial: Configure certificate auto-rotation in Key Vault: "To configure certificate auto-rotation... 3. Select the Issuance Policy tab... 4. Set the Lifetime Action Type to Automatically renew at a given percentage lifetime." (Section: "Create a certificate in Key Vault") This reference demonstrates that certificate lifecycle management uses an "Issuance Policy" and "Lifetime Actions," distinguishing it from the "rotation policy" of keys and secrets.

To enable and use Azure AD Privileged Identity Management (PIM), a user with the Global Administrator role must perform a sequence of onboarding steps.

1. Consent to PIM: The first action is to grant PIM the necessary permissions to manage directory roles. This is a one-time consent action for the entire Azure AD tenant.
2. Verify your identity by using multi-factor authentication (MFA): Because consenting to and configuring PIM is a highly privileged operation, the administrator must first verify their identity using MFA. This ensures the user is who they claim to be before proceeding.
3. Sign up PIM for Azure AD roles: After consent is given and the administrator's identity is verified, the final step is to explicitly enable, or "sign up," the PIM service to begin managing Azure AD roles.

The other options, Discover privileged roles and Discover resources, are actions performed after PIM has been successfully set up and configured.

Microsoft Learn: In the official documentation for deploying PIM, the sequence is clearly outlined. The article states, "The first step is to consent to PIM... To consent to PIM, you'll be required to verify your identity with multi-factor authentication (MFA)... After you've consented to PIM, you can sign up PIM to manage Azure AD roles." This directly supports the provided order of operations.

Source: Microsoft Entra documentation, "Deploy Privileged Identity Management (PIM)", section: "Onboard PIM".

Microsoft Learn: The getting started guide also confirms this sequence by explaining that the initial user (a Global Administrator) must first consent and will be prompted for MFA. The ability to manage roles comes after these initial onboarding and verification steps are completed.

Source: Microsoft Entra documentation, "Start using Privileged Identity Management", section: "Prerequisites".

Microsoft Entra Permissions Management specifically identifies certain Microsoft Entra roles as "highly privileged" for reporting on the Azure AD insights tab. According to official documentation, these roles are Global Administrator, Privileged Role Administrator, and Security Administrator. In the given scenario: Admin1 holds the Global Administrator role. Admin2 holds the Security Administrator role. Admin3 holds the Privileged Role Administrator role. The User Administrator role, held by Admin4, is not classified as a highly privileged role in this context. Therefore, only Admin1, Admin2, and Admin3 will be listed.

A. This option is incorrect because it omits the Security Administrator (Admin2) and Privileged Role Administrator (Admin3) roles, which are also considered highly privileged.
B. This option is incorrect because it omits the Global Administrator (Admin1) role, which is a highly privileged role.
C. This option is incorrect as it omits two highly privileged roles (Admin1, Admin3) and incorrectly includes the User Administrator (Admin4) role.
E. This option is incorrect as it omits the Global Administrator (Admin1) role and incorrectly includes the User Administrator (Admin4) role.
F. This option is incorrect because the User Administrator (Admin4) role is not considered a highly privileged role by Microsoft Entra Permissions Management for this insight.

1. Microsoft Learn. (2023). View key statistics and data about your authorization system in Permissions Management. Under the section "The Azure AD insights tab," the "Highly privileged roles" tile description explicitly states: "Permissions Management considers the following roles to be highly privileged: Global administrator, Privileged role administrator, and Security administrator." This directly supports that Admin1, Admin2, and Admin3 are the correct accounts.

The requirement is for the application to access all user calendars and create appointments. This indicates the app needs to operate without a signed-in user context, often as a background service or daemon. This scenario requires Application permissions, which grant the app its own permissions to access data across the organization. The Microsoft.Graph Calendars.ReadWrite permission provides the exact level of access needed to read calendars and create appointments. This adheres to the principle of least privilege by not granting broader permissions like full mailbox access.

A: Delegated permissions require a user to be signed in and only grant the app access to the resources of that specific user, not all users. C: Granting admin consent is an action performed after a permission is added. It does not, by itself, add the necessary API permission to the app registration. D: The Calendars.ReadWrite.Shared permission is a delegated permission that only allows access to calendars that have been explicitly shared with the signed-in user.

1. Microsoft Graph permissions reference

Calendar permissions: Microsoft Learn. Under the "Calendar" section

the Application permission Calendars.ReadWrite is described as: "Allows the app to create

read

update

and delete events in all calendars without a signed-in user." This directly matches the scenario. The Delegated permission

in contrast

is scoped to the signed-in user's calendars.

Source: Microsoft Learn

"Microsoft Graph permissions reference"

Section: "Calendar permissions".

2. Permissions and consent in the Microsoft identity platform: Microsoft Learn. This document clarifies the distinction between permission types. It states

"For app-only access

the app acts on its own with no user signed in... App-only access is used in scenarios such as automation and backup." The need to access "all user calendars" fits this app-only access model

which uses Application permissions.

Source: Microsoft Learn

"Permissions and consent in the Microsoft identity platform"

Section: "Permission types".

MDM Security Baseline profiles are a feature of Microsoft Intune used to apply recommended security configurations. For a device to receive these profiles, it must be enrolled in and managed by Intune. VM1 is the only eligible device. It runs Windows 10, which is the target operating system for these baselines, and it is Azure AD joined. Joining a Windows 10 device to Azure AD is a primary method for enrolling it into Intune for management. The other virtual machines do not meet the necessary prerequisites to be managed by Intune in this manner.

B. VM1, VM2, and VM3 only: VM2 runs Windows Server, which is not a supported client OS for Intune security baselines. VM3 is not Azure AD joined and thus not enrolled in Intune.
C. VM1 and VM3 only: VM3 is not Azure AD joined, which is a prerequisite for Intune enrollment and management in this context.
D. VM1, VM2, VM3, and VM4: VM2 (Windows Server) and VM4 (Ubuntu) run unsupported operating systems for this feature. VM3 is not enrolled in Intune.

1. Microsoft Learn, Intune Documentation. "Use security baselines to configure Windows devices in Intune". Under the "Prerequisites" section, it is specified that security baselines apply to devices running "Windows 10 version 1809 and later" and "Windows 11". This explicitly excludes Windows Server (VM2) and Ubuntu (VM4).

2. Microsoft Learn, Intune Documentation. "What is device enrollment in Intune?". This document states, "To manage devices in Intune, devices must first be enrolled in the Intune service." This establishes the fundamental requirement for enrollment.

3. Microsoft Learn, Intune Documentation. "Azure AD join for Windows devices". This document explains that "When a Windows device is Azure AD joined, it establishes a trust with Azure AD and is enrolled in Intune." This confirms that VM1, being Azure AD joined, is enrolled and manageable, while VM3, which is not, is not enrolled.

Here’s the breakdown of permissions for each user regarding the virtual machine, VM1:

• User1: Is assigned Role1, which is scoped to the management group MG1. This role applies to all resources under MG1, including VM1. Although Role1 grants broad virtual machine permissions (*/\*), it also includes a notActions entry that explicitly denies the delete action. In Azure RBAC, a deny permission always overrides an allow permission. Therefore, User1 cannot delete VM1.
• User2: Is assigned both Role1 (at the MG1 scope) and Role2 (at the RG1 scope). While Role2 allows all virtual machine actions, Role1's explicit denial of the delete action still applies to User2. The deny (notActions) from Role1 takes precedence over the allow (actions) from Role2. Consequently, User2 cannot delete VM1.
• User3: Is assigned only Role2, which is scoped to the resource group RG1. Role2 grants all virtual machine actions (Microsoft.Compute/virtualMachines/*) and has no notActions to restrict permissions. Since User3 has no assignments that deny deletion, User3 can delete VM1.

Microsoft Learn. (n.d.). Understand how Azure RBAC determines if a user has access to a resource. Retrieved from https://learn.microsoft.com/en-us/azure/role-based-access-control/overview-access-control#how-azure-rbac-determines-if-a-user-has-access-to-a-resource

Reference details: The section "Access evaluation" explains that Azure first checks for any deny assignments, and if one exists for the action, access is blocked, even if a role assignment grants access.

Microsoft Learn. (n.d.). Understand Azure role definitions. Retrieved from https://learn.microsoft.com/en-us/azure/role-based-access-control/role-definitions#notactions

Reference details: The "NotActions" section states, "NotActions specify the management operations that are excluded from the allowed Actions. An effective permission is computed by subtracting the NotActions operations from the Actions operations."

Microsoft Learn. (n.d.). What is Azure role-based access control (Azure RBAC)?. Retrieved from https://learn.microsoft.com/en-us/azure/role-based-access-control/overview#scope

Reference details: The "Scope" section describes how permissions are inherited from parent scopes. "When you assign a role at a parent scope, those permissions are inherited by the child scopes." This confirms that Role1 assigned at MG1 applies to VM1.

The proposed solution, using federation with Active Directory Federation Services (AD FS), does not meet all the stated goals. While federation enforces on-premises Active Directory password policies and user logon limitations (like logon hours) by validating credentials directly against on-premises domain controllers, it fails the requirement to reduce the number of necessary servers. Implementing AD FS requires a significant infrastructure footprint, including dedicated AD FS servers for the federation service and Web Application Proxy (WAP) servers in a perimeter network. This increases, rather than reduces, the number of servers required for the integration.

A. Yes: This is incorrect because the solution explicitly contradicts the requirement to reduce the server footprint. AD FS federation is the most infrastructure-intensive sign-in option available with Azure AD Connect.

1. Microsoft Learn | Azure Active Directory Documentation. "Choose the right authentication method for your Azure Active Directory hybrid identity solution." In the comparison table

Federation (AD FS) is shown to require an "On-premises federation farm

" which is described as having a "more significant infrastructure footprint" compared to other methods. This directly conflicts with the goal of reducing servers.

Source: Microsoft Learn

"Choose the right authentication method for your Azure Active Directory hybrid identity solution"

Section: "Comparing the methods".

2. Microsoft Learn | Azure Active Directory Documentation. "What is federation with Azure AD?". This document outlines the architecture for federation

which includes deploying a federation farm (AD FS) and proxies (Web Application Proxy).

Source: Microsoft Learn

"What is federation with Azure AD?"

Section: "Why use federation?".

3. Microsoft Learn | Azure Active Directory Documentation. "Azure AD Pass-through Authentication: Quickstart". This document describes Pass-through Authentication (PTA)

an alternative that meets the policy enforcement goals with a much smaller footprint. It states

"PTA needs just one or more lightweight agents installed on existing servers." This highlights that other solutions exist which better meet the goal of minimizing server infrastructure compared to AD FS.

Source: Microsoft Learn

"Azure AD Pass-through Authentication: Quickstart"

Section: "Azure AD Pass-through Authentication benefits".

First, create an app registration to establish the application's identity in Azure AD. Second, add an application permission (e.g., Directory.Read.All). Application permissions are required because the app runs as a background service (daemon) without a signed-in user; "Delegated permissions" are only for apps acting on behalf of a user. Finally, grant permissions (Grant Admin Consent). Unlike some delegated permissions, Application permissions always require an administrator to explicitly grant consent for the application to use them.

Microsoft Learn: Scenario: Daemon application that calls web APIs

Reference: "A daemon application can run as a background service on a server... uses the client credentials grant flow... In this scenario, the application is not acting on behalf of a user, but on its own behalf... Application permissions."

Link: https://learn.microsoft.com/en-us/entra/identity-platform/scenario-daemon-overview

Microsoft Learn: Permissions and consent in the Microsoft identity platform

Reference: "Application permissions: Used by apps that run without a signed-in user present, for example, apps that run as background services or daemons." "Administrator consent is required for any application permissions."

Link: https://learn.microsoft.com/en-us/entra/identity-platform/permissions-consent-overview

Microsoft Learn: Quickstart: Register an application with the Microsoft identity platform

Reference: "To register an application... Select App registrations... New registration." (This confirms the first step).

Link: https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app

Azure Security Center (now part of Microsoft Defender for Cloud) leverages Azure Policy to enforce security configurations. To deploy a security policy, you must first define the scope of its assignment. While policies can be assigned to individual subscriptions, the best practice for managing policies across an organization is to use management groups. Creating a management group allows you to apply policies, access controls, and compliance settings to a collection of subscriptions efficiently. Therefore, the foundational step, especially for a structured deployment of a new policy like "SecPol1," is to create the management group that will serve as the target scope for the policy assignment.

A. Enable Azure Defender: Azure Defender (now Microsoft Defender for Cloud plans) provides advanced threat protection. Basic security policy management is available in the free tier and does not require enabling paid plans first.
C. Create an initiative: An initiative (or policy set) is a definition of a collection of policies. While you might need to create a custom initiative, you cannot assign or "deploy" it without first having a scope (like a management group or subscription) to assign it to.
D. Configure continuous export: Continuous export is a feature for streaming security alerts and recommendations to external tools like a SIEM. It is unrelated to deploying or assigning security policies.

1. Microsoft Learn, "Organize your resources with Azure management groups": "If your organization has many subscriptions, you may need a way to efficiently manage access, policies, and compliance for those subscriptions. Azure management groups provide a level of scope above subscriptions... You can apply governance conditions like policies... at the management group level." This document establishes that management groups are the primary tool for organizing subscriptions to apply policies.

2. Microsoft Learn, "What is Azure Policy?": Under the "Assignment" section, it states, "An assignment is a policy definition or initiative that has been assigned to a specific scope. This scope could range from a management group to a resource group." This confirms that a scope, such as a management group, is a prerequisite for policy assignment (deployment).

3. Microsoft Learn, "Security policy and compliance": "Defender for Cloud uses Azure Policy to set policies and to check for compliance... To apply a security policy to a group of resources, you can assign the policy to a management group, a subscription, or a resource group." This highlights that the assignment process, which is the deployment of the policy, requires a target scope, and management groups are a primary option for this.

The first question asks what happens to the alert from 05:11 PM when its status is changed to Dismissed. As shown in the image, the alert view is filtered by Active, Resolved, In Progress statuses. A Dismissed alert does not fall into any of these categories. Therefore, changing its status to dismissed would make it disappear from the current view.

The second question asks what status the alert from 12:44 PM can be changed to. The image shows that this alert is currently Resolved. While an alert's status is automatically set to Resolved when a related security recommendation is addressed, it can be manually changed to Active, In Progress, or Dismissed by a user. This is a common function in alert management systems like Microsoft Defender for Cloud, allowing for re-investigation or different types of manual closure.

Microsoft, "Manage and respond to security alerts in Microsoft Defender for Cloud," Microsoft Learn Documentation, Section 1: "Change the status of an alert" (2023). This document outlines the status management of alerts, including "Active," "In Progress," "Resolved," and "Dismissed," and explains how dismissed alerts are handled.

Microsoft, "Security alerts from Microsoft Defender for Cloud," Microsoft Learn Documentation, Section: "Alert types and severity" (2024). This provides context on how alerts are categorized by status and how filters affect their visibility in the console.

Fagbohun, O.A., et al. "A survey of security information and event management (SIEM) systems." International Journal of Computer Networks and Applications, vol. 10, no. 5, pp. 101-112 (2023). This provides an academic perspective on alert management and status filtering in SIEM systems, which aligns with Defender for Cloud’s functionality.

“Direct onboarding” for on-premises or other-cloud machines lets you add computers to Microsoft Defender for Cloud without first enabling Azure Arc. According to Microsoft’s product documentation, this preview feature supports only Windows Server 2012 R2 and Windows Server 2016. No current Linux distribution, Windows client OS, Windows Server 2019, or Windows Server 2022 is accepted. In the table, Server3 is the only host that runs a supported operating system (Windows Server 2012 R2). Therefore, when you enable direct onboarding, Defender for Cloud can onboard only Server3.

A. Server1’s OS isn’t in the supported list, so it can’t be onboarded.
B. Server2 is a Linux server; Linux isn’t yet supported for direct onboarding.
D. Server1 fails the OS prerequisite; only Server3 qualifies.
E. Linux (Server2) is unsupported; only Server3 qualifies.
F. Server1 and Server2 both fail prerequisites; only Server3 is onboarded.

1. Microsoft Defender for Cloud – “Directly connect your machines to Defender for Cloud (preview)”

Prerequisites → Supported operating systems: Windows Server 2012 R2

Windows Server 2016. https://learn.microsoft.com/azure/defender-for-cloud/quickstart-onboard-machines-directly

2. Microsoft Defender for Servers – “Onboard non-Azure machines (preview)”

section “Supported OS versions”. https://learn.microsoft.com/azure/defender-for-cloud/defender-for-servers-introduction

(Both links are official Microsoft documentation; section headings cited contain the specific OS requirements that justify the answer.)

A Conditional Access policy is structured around assignments (who the policy applies to) and access controls.

1. Conditions: This section defines the signals that trigger the policy. To restrict access based on the device's operating system, you would configure the Device platforms setting under Conditions. This allows you to include or exclude specific platforms like Windows, macOS, iOS, and Android. Therefore, to only allow access from Windows, the Conditions setting is used.
2. Grant: This section defines the access controls that are enforced once the conditions are met. To ensure a device meets organizational standards for security and configuration, you use the Grant control "Require device to be marked as compliant". This control checks the device's compliance status (managed by a solution like Microsoft Intune) before granting access.

Microsoft Learn | Conditional Access: Conditions: This official documentation details the various conditions available in a Conditional Access policy. Under the "Device platforms" section, it states, "Conditional Access identifies the device platform by using information provided by the device... By default, a Conditional Access policy applies to all device platforms." This confirms that filtering by device type (like Windows) is handled within the Conditions settings.

Microsoft Learn | Conditional Access: Grant: This document explains the available grant controls. It explicitly lists "Require device to be marked as compliant" as a grant control. The document states, "This control requires the device used to access the cloud app is marked as compliant by a mobile device management (MDM) solution like Microsoft Intune." This verifies that enforcing compliance is a Grant control.

Both Application Security Groups (ASGs) and Azure Bastion are networking resources within Azure.

• Role1 (Application Security Groups): ASGs are used to group virtual machines and define network security policies based on those groups. All management operations for ASGs, such as creating, deleting, or modifying them, are permissions within the Microsoft.Network resource provider. For example, the permission to create an ASG is Microsoft.Network/applicationSecurityGroups/write.
• Role2 (Azure Bastion): Azure Bastion is a platform-managed service that provides secure and seamless RDP/SSH connectivity to virtual machines directly in the Azure portal. Since Bastion is fundamentally a networking service that facilitates secure connections to resources within a virtual network, its management also falls under the Microsoft.Network resource provider. For instance, creating a Bastion host requires the Microsoft.Network/bastionHosts/write permission.

Therefore, Microsoft.Network is the correct resource provider for both custom roles.

Microsoft Official Documentation (Microsoft Learn): "Azure resource providers and types." This document lists the resource types managed by each resource provider. Under the Microsoft.Network provider, you can find applicationSecurityGroups and bastionHosts, confirming that both are managed by this provider.

Microsoft Official Documentation (Microsoft Learn): "Application security groups." In the Permissions section, it states that ASGs are a resource within Microsoft.Network. For example, the built-in Network Contributor role, which can manage ASGs, has its permissions defined under Microsoft.Network/*.

Microsoft Official Documentation (Microsoft Learn): "Working with a custom role." In the tutorial for creating custom roles, examples for networking resources consistently use the Microsoft.Network provider for permissions related to virtual networks, subnets, and associated services like Azure Bastion. The necessary actions for managing Bastion, such as Microsoft.Network/bastionHosts/read, clearly fall under this provider.