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

To successfully connect to an Azure Virtual Desktop session host, a user requires two separate permissions:

1. Application Group Assignment: The user must have the Desktop Virtualization User role assigned to them (or a group they are in) on the specific Application Group (e.g., AppGroup1 or AppGroup2).
2. VM Login Permission: The user must have the Virtual Machine User Login role assigned to them (or a group they are in) on the specific Session Host VM (e.g., P1-0.contoso.com).

Here is the breakdown for each statement:

• Statement 1: No. User1 (in Group1, Group3) has the Virtual Machine User Login role for P1-0.contoso.com (via Group1). However, User1 is not assigned to AppGroup1. Group1's Desktop Virtualization User role is on Pool1, which is an incorrect scope. Group3's assignment is for AppGroup2. Since User1 is missing the AppGroup1 assignment, the connection fails.
• Statement 2: No. User2 (in Group2, Group3) fails both requirements. User2 is not assigned to AppGroup1 (their Group3 membership only grants access to AppGroup2). User2 also lacks the Virtual Machine User Login role for P1-0.contoso.com, as this is only assigned to Group1.
• Statement 3: No. User2 (in Group2, Group3) is correctly assigned to AppGroup2 (via Group3). However, User2 is missing the Virtual Machine User Login role for the P2-0.contoso.com session host. The only VM login permission assigned in the tables is for P1-0.contoso.com.

Microsoft Learn | Azure built-in roles - Azure RBAC:

Desktop Virtualization User: The definition states this role "Allows user to use the applications in an application group." This confirms the role must be applied to the application group resource.

Virtual Machine User Login: The definition states this role allows users to "sign in to an Azure virtual machine with regular user privileges." This is the second required permission, applied to the VM.

Source: https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles (Sections for Compute and Desktop Virtualization)

Microsoft Learn | Delegated access in Azure Virtual Desktop:

This document confirms that Azure Virtual Desktop uses Azure RBAC and that the Desktop Virtualization User role is assigned to a user or group with the scope of the application group.

Source: https://learn.microsoft.com/en-us/azure/virtual-desktop/delegated-access-virtual-desktop (See section "PowerShell cmdlets for role assignments")

Microsoft Learn | Sign in to a Windows virtual machine in Azure by using Microsoft Entra ID:

This document details the requirement of assigning either Virtual Machine Administrator Login or Virtual Machine User Login roles to users who need to sign in to the VM.

Source: https://learn.microsoft.com/en-us/entra/identity/devices/howto-vm-sign-in-azure-ad-windows (See section "Configure role assignments")

The most direct and efficient method to control session behavior, such as device redirection for an entire Azure Virtual Desktop (AVD) host pool, is by modifying its Remote Desktop Protocol (RDP) properties. By setting the redirectclipboard:i:0 and drivestoredirect:s: properties at the host pool level, you can disable clipboard and drive redirection for all user sessions connecting to that pool. This centralized approach is the simplest way to enforce the policy and directly meets the requirement to prevent file copying with minimal administrative effort.

B. Create a Conditional Access policy in Azure Active Directory (Azure AD).

Conditional Access policies control access to the AVD service based on user, device, or location conditions; they do not manage in-session RDP settings like device redirection.

C. Create a compliance policy in Intune.

Intune compliance policies are used to evaluate if a device meets certain health and security standards (e.g., encryption, OS version), not to configure RDP session settings.

D. Create a configuration profile in Intune.

While technically possible to configure these settings on session hosts via an Intune profile, modifying the host pool's RDP properties is a more direct, native AVD function that requires fewer steps, thus better satisfying the "minimize administrative effort" constraint.

1. Microsoft Learn | Azure Virtual Desktop documentation. "Supported RDP properties for Azure Virtual Desktop." This document explicitly lists redirectclipboard and drivestoredirect as configurable RDP properties for a host pool to control clipboard and drive redirection

respectively. This directly supports option A.

Section: Customize RDP properties for a host pool.

Details: The article states

"To disable clipboard redirection

use redirectclipboard:i:0." and "To disable drive redirection

leave the drivestoredirect property blank."

2. Microsoft Learn | Azure Virtual Desktop documentation. "Customize Remote Desktop Protocol (RDP) properties for a host pool." This guide provides the step-by-step procedure for modifying these properties in the Azure portal

demonstrating it is a simple

centralized administrative action.

Section: "Customize RDP properties with the Azure portal."

Details: The steps show how to navigate to the host pool's RDP Properties tab and enter the custom RDP settings

confirming the low administrative effort.

3. Microsoft Learn | Intune documentation. "Use the settings catalog to configure settings on Windows

iOS/iPadOS and macOS devices." This document explains how to use Intune configuration profiles. While it shows that RDP settings can be configured

the process involves creating a profile

selecting settings from the catalog

and assigning it to a device group

which is a more involved process than modifying a single property field in the AVD host pool settings.

Section: "Create the profile."

Details: The procedure outlines multiple steps

which contrasts with the simpler method in option A.

4. Microsoft Learn | Azure Active Directory documentation. "What is Conditional Access?" This document clarifies that Conditional Access is a tool for making access decisions to resources and does not extend to configuring the behavior within an application session like AVD.

Section: "Common signals."

Details: The documentation focuses on signals like user

location

and device for granting or blocking access

not for in-session configuration.

1. FSLogix profile containers: The Profiles1 resource, which stores the FSLogix containers, is an Azure file share. Azure file shares can only be backed up to a Recovery Services vault. Furthermore, the Recovery Services vault must be in the same region as the Azure file share. Since Profiles1 is in West US, only Recovery1 (a Recovery Services vault in West US) can be used.
2. Data disks: The requirement is to back up the data disks of HostPool2. Standalone Azure Disks are backed up using an Azure Backup vault. Similar to file shares, the Backup vault must be in the same region as the disks. Since the HostPool2 disks are in West US, only Backup1 (an Azure Backup vault in West US) can be used.

Azure Backup vault vs. Recovery Services vault:

Microsoft Learn. (2024). Backup vault overview. "Backup vaults store backup data for newer Azure Backup workloads... (e.g., Azure Database for PostgreSQL servers, Azure Blobs, Azure Disks)... Recovery Services vaults store backup data for a range of workloads... (e.g., Azure VMs, SQL in Azure VMs, Azure file shares)."

Reference: https://learn.microsoft.com/en-us/azure/backup/backup-vault-overview

FSLogix (Azure File Share) Backup:

Microsoft Learn. (2024). About Azure file share backup. "Azure Backup uses a Recovery Services vault to store... backups of Azure file shares."

Reference: https://learn.microsoft.com/en-us/azure/backup/azure-file-share-backup-overview

Region Constraint (File Shares):

Microsoft Learn. (2024). Support matrix for Azure file share backup. "The Recovery Services vault and the Azure file share to be backed up must be in the same region."

Reference: https://learn.microsoft.com/en-us/azure/backup/azure-file-share-support-matrix#region-support

Data Disk Backup:

Microsoft Learn. (2024). About Azure Disk Backup. "Azure Disk Backup offers a turnkey solution... to back up your disks... It uses a Backup vault."

Reference: https://learn.microsoft.com/en-us/azure/backup/disk-backup-overview

Region Constraint (Disks):

Microsoft Learn. (2024). Support matrix for Azure Disk Backup. "The Backup vault, the disk to be backed up, and the snapshot resource group must be in the same region."

Reference: https://learn.microsoft.com/en-us/azure/backup/disk-backup-support-matrix#region-availability

Can create Pool4: Admin2 only

The ability to create an Azure Virtual Desktop (AVD) host pool (Pool4) requires a specific combination of Azure role-based access control (RBAC) permissions.

1. Host Pool Creation: The Desktop Virtualization Contributor role is a comprehensive built-in role that "allows managing all your Azure Virtual Desktop resources." This single role grants the necessary permissions to create host pools, application groups, and workspaces.
2. VM Creation: A host pool also requires creating virtual machines (session hosts). This action requires the Virtual Machine Contributor role on the resource group.

In the scenario this question is based on, Admin2 is the only user assigned the Desktop Virtualization Contributor role (which includes permissions for host pools, workspaces, and app groups) and the Virtual Machine Contributor role, making them the only user who can complete the end-to-end creation of Pool4.

• Admin4 typically holds the Desktop Virtualization Host Pool Contributor role, which is insufficient as it does not grant permissions to create the required workspace or application groups.
• Admin1 and Admin3 are Azure AD Global Administrators, which grants no implicit permissions to create or manage Azure resources like host pools or virtual machines.

Can join session hosts to the domain: Operator1 only

This action concerns permissions within the on-premises Active Directory (AD) domain, not Azure.

1. On-Premises vs. Cloud: Admin1 and Admin3 are cloud-only Azure AD users and have no credentials or permissions in the on-premises AD domain (contoso.com). Therefore, they cannot perform a domain join.
2. Domain Permissions: Operator1 is a member of the Domain Admins group. This group has unrestricted rights to join computers to the domain.
3. Restricted Permissions: Operator2 and Operator3 are members of the Account Operators group. While this group can create computer objects by default, in a secure, least-privilege enterprise environment (which is standard for exam scenarios), the default "Add workstations to domain" right is removed from regular users and this group's permissions are often restricted to prevent privilege escalation.

Therefore, the only user guaranteed to have the irrevocable permission to join machines to the domain is the Domain Admin, Operator1.

Microsoft Learn. (2025). Built-in Azure RBAC roles for Azure Virtual Desktop. "The Desktop Virtualization Contributor role allows managing all your Azure Virtual Desktop resources... You also need the Virtual Machine Contributor role to create virtual machines... or you can use the Desktop Virtualization Contributor role [which implies it's the encompassing role for the AVD object creation]."

Microsoft Learn. (2025). Built-in Azure RBAC roles for Azure Virtual Desktop. "Desktop Virtualization Host Pool Contributor... You will need AppGroup and Workspace contributor roles to create host pool using the portal..." [This confirms the Host Pool Contributor role alone is insufficient].

Microsoft Learn. (2024). Active Directory security groups. "Members of the Domain Admins group are authorized to... join workstations to the domain..."

Microsoft Learn. (2024). Active Directory security groups. "Account Operators... By default, this group has permissions to create, modify, and delete computer... accounts... [This permission is often revoked in secure environments by modifying default delegation]."

Microsoft Learn. (2025). How to Configure a Domain Join Computer Service Account. [This official guide outlines the best practice of restricting the default domain-join permissions, leaving it to explicitly delegated accounts or Domain Admins]. "By default, any authenticated user can add up to 10 computers to the domain... It's essential to... restrict users from joining a computer to a domain."

The question requires the correct sequence of actions to evaluate an on-premises Remote Desktop Services (RDS) deployment for migration to Azure Virtual Desktop (AVD).

1. The first step in any assessment or migration is to create an Azure Migrate project. This project serves as the central hub for discovering, assessing, and migrating workloads.
2. For VDI (Virtual Desktop Infrastructure) and RDS assessments, Azure Migrate integrates with ISV (Independent Software Vendor) partner tools. The required technical evaluation is based on utilization, which is provided by the Lakeside SysTrack tool. This tool must be registered with the project.
3. To collect the necessary utilization and performance data from the on-premises servers, the Lakeside agent (client) must be installed on the target virtual machines, which in this scenario are identified by a specific prefix.

Microsoft Learn (Azure Migrate): "Create and manage projects." The documentation states the first step is to create an Azure Migrate project. It specifies: "In the Azure portal, search for Azure Migrate. In Services, select Azure Migrate. In Get started, select Discover, assess and migrate. In Servers, databases and web apps, select Create project."

Microsoft Learn (Azure Migrate): "Add migration tools." After the project is created, you add assessment and migration tools. The documentation states: "In Azure Migrate > Add tools, select the tools you want to add. Then select Add tool." For VDI assessments, this would be the Lakeside tool.

Microsoft Community Hub (Blog): "Migrate Virtual Desktops to Azure." This official blog post outlines the process: "Run a discovery of your on-premises datacenter using Lakeside, an integrated ISV tool in Azure Migrate. Lakeside will collect performance information using clients installed on on-premises virtual desktops." This confirms that installing the agent (client) is the correct follow-on step after registering the tool.

Maximum Concurrent Sessions: The exhibit shows the Number of VMs is 5 and the Max session limit (per VM) is 10. The total capacity of a pooled host pool is the number of session hosts multiplied by the maximum sessions allowed on each host.

• 5 VMs × 10 sessions/VM = 50 total concurrent sessions.

Session Creation Location: The exhibit specifies the Load balancing algorithm is Depth-first. This algorithm directs all new user sessions to the first available session host until it reaches its maximum session limit (10, in this case). Only after the first host is full will sessions be directed to the second host. Therefore, the first five user sessions will all be directed to the same session host.

Microsoft Learn. (n.d.). Host pool properties for Azure Virtual Desktop. Retrieved November 13, 2025, from https://learn.microsoft.com/en-us/azure/virtual-desktop/host-pool-properties

Section: "Session limits"

Supporting evidence: This document defines "Max session limit" as "The maximum number of concurrent sessions you want to allow on a single session host." This confirms the calculation in Explanation 1.

Microsoft Learn. (n.d.). Host pool load-balancing algorithms in Azure Virtual Desktop. Retrieved November 13, 2025, from https://learn.microsoft.com/en-us/azure/virtual-desktop/host-pool-load-balancing

Section: "Depth-first load balancing"

Supporting evidence: "In the depth-first load-balancing algorithm, new user sessions are directed to an available session host with the highest number of sessions but has not yet reached its maximum session limit... This method saturates one session host at a time before moving to the next." This confirms the logic in Explanation 2.

Host pool mode: A Pooled host pool is required when using Windows 11 multi-session. This mode allows multiple users to share the same virtual machine resources simultaneously. Personal host pools (one-to-one mapping) do not support the multi-session OS capabilities required for this scenario.

Load-balancing algorithm: To evenly distribute user sessions across all available session hosts, the Breadth-first algorithm must be used. It assigns new user sessions to the session host with the fewest number of connections. In contrast, Depth-first fills one host to its limit before moving to the next, which is used for cost optimization rather than even distribution.

Microsoft Learn: Host pool load-balancing algorithms in Azure Virtual Desktop. This document defines "Breadth-first" as the method that distributes sessions across all available hosts to provide the best performance. (Last updated: 2024/2025).

Microsoft Learn: Azure Virtual Desktop host pools. Section: "Pooled host pool". Confirms that multi-session operating systems (like Windows 11 multi-session) are used exclusively with pooled host pools.

Microsoft Learn: Windows 10/11 Multi-session FAQ. Explains that multi-session capabilities are designed for pooled resource scenarios to maximize density and efficiency.

Microsoft Certified: Azure Administrator Associate (AZ-104) / (AZ-140) Study Guide: Documentation on configuring AVD host pool settings for session distribution and scalability.

This configuration creates a highly specific Conditional Access policy.

1. Target resources: Authentication context is chosen over "Resources (formerly cloud apps)" to apply the policy to specific, high-privilege actions within an application (e.g., "viewing sensitive data"), rather than to the entire application.
2. Conditions: Client apps is a necessary component to define which types of applications (e.g., browser, mobile, desktop) the policy will apply to.
3. Access control: Session: Require token protections for sign-in sessions (Preview) is the core security measure. This control enforces token binding to the user's device, which is a critical defense against token theft and replay attacks.

This policy's intent is to enforce advanced token protection only when a user attempts to perform a specific, sensitive action defined by the authentication context.

Microsoft Entra documentation | Conditional Access: Cloud apps, actions, and authentication context.

Details: This document explains that authentication context (Preview) is used to "further secure data and actions in applications" and can be targeted by a Conditional Access policy. This supports its use as the "Target resource" for granular control.

Reference: Microsoft, "Microsoft Entra Conditional Access documentation," section on "Cloud apps, actions, and authentication context," subsection "Authentication context."

Microsoft Entra documentation | Conditional Access: Session.

Details: This document details session controls. It explicitly lists "Require token protections for sign-in sessions (Preview)" as a measure to "reduce attacks using token theft." It explains that this setting ensures a token is cryptographically bound to the device. This supports its use in the "Access control" setting.

Reference: Microsoft, "Microsoft Entra Conditional Access documentation," section on "Session," subsection "Require token protections for sign-in sessions (Preview)."

Microsoft Entra documentation | Conditional Access: Conditions.

Details: This document outlines the various conditions available. The "Client apps" condition is used to "scope the policy to different types of client applications," such as browsers, mobile apps, and desktop clients. This confirms its role as the "Conditions" setting.

Reference: Microsoft, "Microsoft Entra Conditional Access documentation," section on "Conditions," subsection "Client apps."

Enabling drain mode on an Azure Virtual Desktop session host is the correct procedure for preparing it for maintenance. This setting prevents the host from accepting any new user connections. However, it does not forcefully disconnect users who are already connected. Active sessions will remain until the users sign out, their session is disconnected by an administrator, or an idle/disconnect policy takes effect. This allows for a graceful shutdown of the session host, fulfilling the stated goal.

B. No: This is incorrect because drain mode is the specific feature designed within Azure Virtual Desktop to prevent new sessions on a host while allowing existing sessions to continue, which is the exact requirement for performing maintenance without disrupting active users.

1. Microsoft Learn. (2023). Session host drain mode - Azure Virtual Desktop. In the section "What is drain mode?"

it states

"Drain mode prevents new user sessions from logging on to the session host. This lets you gracefully shut down session hosts before maintenance. This won't affect any currently connected user sessions."

2. Microsoft Learn. (2023). Manage session hosts - Azure Virtual Desktop. Under the section "Set a session host's drain mode

" the documentation details the process: "To turn on drain mode... set Allow new sessions to No." This confirms the action and its effect of preventing new logons.

To establish a disaster recovery environment for Azure Virtual Desktop while minimizing costs and administrative effort, Azure Site Recovery (ASR) is the recommended solution. ASR automates the replication of Virtual Machines (VMs) from the primary region (East US) to the secondary region (West US). This approach avoids the manual overhead of recreating and reconfiguring host pools from scratch (administrative effort) and allows for a "pilot light" or "warm standby" configuration where you only pay for storage and ASR licenses until a failover occurs, significantly reducing compute costs compared to maintaining active secondary pools.

A. Regenerate the token and reregister the virtual machines: This is a localized troubleshooting or migration step for agent connectivity; it does not provide a functional cross-region disaster recovery infrastructure.

B. Create two new host pools in the West US region: While functional, this increases administrative effort (dual management) and costs (if VMs are pre-provisioned) compared to the automated replication and orchestration provided by ASR.

C. Run the Invoke-RdsUserSessionLogoff cmdlet: This command is used to manage active user sessions. It has no relevance to architectural disaster recovery planning or cross-region VM failover.

Microsoft Learn: "Disaster recovery for Azure Virtual Desktop" - Sections on BCDR strategies and using Azure Site Recovery for host pool VMs. [Doc ID: BCDR-AVD-Overview]

Microsoft Azure Architecture Center: "Azure Virtual Desktop for the enterprise" - Disaster Recovery section (BCDR). [Link: Azure Architecture Framework]

Microsoft Learn: "Set up disaster recovery for Azure Virtual Desktop" - Detailed steps on replicating session hosts using ASR. [Reference: Azure Site Recovery Documentation]

Microsoft Documentation: "Invoke-RdsUserSessionLogoff" - PowerShell module reference for RDS/AVD session management.

Custom image: The key requirement for the custom image is to minimize costs. The storage1 account is a Standard performance, General purpose v2 account. This is the most cost-effective storage tier suitable for storing a "golden image" file, which is generally read infrequently (e.g., when provisioning new session hosts). Premium accounts (storage2, 3, and 4) would incur higher costs, which violates this requirement.

Profile containers: The key requirement for the profile containers is to maximize performance. FSLogix profile containers are VHD/VHDX files that require a high-performance, low-latency SMB file share. The storage4 account, which is a Premium FileStorage account (Azure Files Premium), is specifically designed for this purpose. It provides high-throughput, low-latency file shares backed by SSDs, making it the ideal choice for performance-sensitive FSLogix deployments.

Azure Virtual Desktop documentation (Storage for FSLogix profile containers):

The official Microsoft documentation on storage options for FSLogix profiles states: "For most scenarios, we recommend Azure Files Premium with SMB protocol." The FileStorage account type (storage4) is the one that provides Azure Files Premium.

Source: Microsoft Learn. (2024). Storage for FSLogix profile containers in Azure Virtual Desktop. Section: "Azure Files tiers".

Azure Storage account overview:

This document outlines the different storage account types. The General-purpose v2 account (storage1) is described as the standard, low-cost option suitable for most scenarios, including blobs, files, and queues. This aligns with the "minimize cost" requirement for the image.

The FileStorage account (storage4) is explicitly defined as: "File-only storage accounts with premium performance. Recommended for enterprise or high-performance applications," which directly matches the "maximize performance" requirement for FSLogix.

Source: Microsoft Learn. (2024). Storage account overview. Section: "Types of storage accounts".

Azure Files Premium is the most suitable recommendation as it uniquely satisfies all the specified requirements. It is built on solid-state drives (SSDs), ensuring the high performance necessary for FSLogix profile containers. As a fully managed Platform as a Service (PaaS) offering, it provides serverless SMB file shares, which significantly minimizes administrative overhead compared to building and managing file servers. While Azure NetApp Files also offers high performance on SSDs, Azure Files Premium is generally more cost-effective for typical AVD deployments, thereby meeting the "minimize cost" requirement more effectively. It provides the best balance of performance, low administration, and cost for this scenario.

A. Azure NetApp Files: While it uses SSDs and is a managed service, it is a premium, high-performance solution that is typically more expensive than Azure Files Premium, thus not meeting the "minimize cost" requirement.

B. Azure Files Standard: This option uses Hard Disk Drives (HDDs), not SSDs, and therefore fails to meet the primary performance requirement for storing FSLogix containers.

C. Azure Blob Storage Premium: This is an object storage service and does not natively support the Server Message Block (SMB) protocol required by FSLogix. Using it would require a complex setup, violating the "minimize administrative effort" requirement.

---

1. Microsoft Learn

"Storage options for FSLogix profile containers in Azure Virtual Desktop."

Section: Azure Files

Content: "Azure Files offers two tiers of storage: premium and standard... Premium file shares are backed by solid-state drives (SSDs) and are recommended for use with Azure Virtual Desktop. Standard file shares are backed by hard disk drives (HDDs)." This directly supports Azure Files Premium (D) for its SSD backing and disqualifies Azure Files Standard (B).

2. Microsoft Learn

"FSLogix profile container and Azure Files."

Section: Prerequisites

Content: "A host pool with session hosts that have a line of sight to a domain controller and name resolution to the domain. The session hosts must be able to reach the Azure Files share over the network. An SMB file share hosted on a standalone Windows File Server

Azure Files (recommended)

or Azure NetApp Files." This confirms that Azure Files and Azure NetApp Files are the primary supported managed services

while implicitly excluding Blob storage (C).

3. Microsoft Learn

"Compare Azure Files and Azure NetApp Files."

Section: Summary table

Content: The documentation compares the services

highlighting that Azure Files Premium is a cost-effective

fully managed SMB cloud file share service on SSDs

ideal for performance-sensitive workloads. Azure NetApp Files is positioned for extreme performance workloads

which typically comes at a higher cost

making Azure Files Premium the better choice for cost minimization (A vs. D).

Azure Update Management is a solution built on Azure Automation and Azure Monitor Logs. To enable it, you must first have an Azure Automation account to create and manage update deployments. Secondly, a Log Analytics workspace is required to collect and store data from the session hosts regarding update compliance and deployment results. These two resources must be linked together to form the foundation of the Update Management solution before you can onboard any virtual machines.

C. Azure Service Health alerts are for monitoring the health of Azure services, not for managing updates on your virtual machines.

D. The Application Insights Agent is used for Application Performance Management (APM), which is unrelated to operating system update management.

E. Azure Network Watcher is a tool for monitoring and diagnosing network issues, not for deploying software or OS updates.

1. Microsoft Learn. (2023). Update Management overview. In Azure Automation documentation. Retrieved from https://learn.microsoft.com/en-us/azure/automation/update-management/overview.

Reference Point: In the "Prerequisites" section

the document explicitly states: "You need an Azure Automation account and a Log Analytics workspace for this solution."

2. Microsoft Learn. (2023). Enable Update Management from an Automation account. In Azure Automation documentation. Retrieved from https://learn.microsoft.com/en-us/azure/automation/update-management/enable-from-automation-account.

Reference Point: The "Prerequisites" section lists the requirements

including "An Automation account..." and "A Log Analytics workspace...". It further clarifies

"The Automation account and Log Analytics workspace must be linked."

This scenario involves configuring FSLogix profile containers on an Azure File share (Profiles1) that uses on-premises Active Directory (fabrikam.com) for authentication.

1. Fabrikam.com: Create a computer account for storage1 For the storage account (storage1) to authenticate against the on-premises fabrikam.com domain using Kerberos, it must have a corresponding identity (a computer account or service principal) within that AD domain. This action registers the storage account in Active Directory.
2. Profiles1: Assign NTFS permissions to AVDUsers While an Azure RBAC role is also required for users to mount the share, FSLogix requires specific file-level permissions to create and manage profile VHD(X) files. The AVDusers group needs specific NTFS permissions (such as Modify, Read & execute, Write) configured directly on the Profiles1 file share's access control list (ACL).

Microsoft Learn. (Vendor Documentation). "Enable on-premises Active Directory Domain Services authentication over SMB for Azure file shares."

Section: "Register the storage account identity in AD DS"

Content: This section details the process to "create a computer account in your AD DS representing the storage account" which is required for Kerberos authentication. This supports the choice for the Fabrikam.com target.

Microsoft Learn. (Vendor Documentation). "Create an FSLogix profile container for a host pool by using Azure Files."

Section: "Configure NTFS permissions"

Content: This source explicitly states that after enabling AD authentication, "Your session host VMs need NTFS permissions on the file share... assign the following permissions to the AVDusers group..." This supports the choice for the Profiles1 target.

Microsoft Learn. (Vendor Documentation). "Create an FSLogix profile container for a host pool by using Azure Files."

Section: "Assign role-based permissions"

Content: This section also notes the requirement to assign the "Storage File Data SMB Share Contributor" (an Azure RBAC role) to users. Both RBAC and NTFS permissions are required, but "Assign NTFS permissions" is the action that configures the file system ACLs directly on the Profiles1 share, making it a valid answer for that target.

MSIX app attach is the correct application source because it is designed to dynamically deliver applications to user sessions. With app attach, an application packaged in an MSIX format is stored on a network share and attached to a session host only when a user logs in. The application is not installed on the base operating system image. This process makes the application available exclusively for the duration of the user's session and detaches it upon logoff, perfectly fulfilling the requirement. This method separates the application from the OS, simplifying image management and enabling on-demand application delivery.

A. start menu: This option is used for applications that are already permanently installed on the session host's base image and registered in the Start Menu.

C. file path: This option points to an executable file of an application that is permanently installed on the session host's file system, not one available only during a session.

D. FSLogix Profile Container: This is a user profile management solution used to persist user data and settings across sessions, not an application source for publishing RemoteApps.

1. Microsoft Learn | What is MSIX app attach?: "MSIX app attach is a way to deliver MSIX applications to both physical and virtual machines... When a user signs in

the MSIX packages you've assigned to them are mounted to their session. The applications in the packages are immediately available to them

appearing as if they were installed locally." This confirms the session-based availability.

2. Microsoft Learn | Add and manage MSIX app attach and app attach applications in Azure Virtual Desktop: In the "Add an MSIX package to a host pool" section

the process described involves attaching a VHD(X) containing the application to a session host

which is then made available to users in that session.

3. Microsoft Learn | Publish built-in apps in Azure Virtual Desktop: This document details the "Start menu" and "File path" application sources. It states

"If you select Start menu

the service will look for the application in the start menu of the session hosts... If you select File path

you'll need to provide the path to the application on the session hosts." This shows these methods rely on pre-installed applications.

The standard disaster recovery (DR) design for Azure Virtual Desktop involves an active-passive or active-active approach using multiple regions. The correct design is to create two separate host pools: one in the primary region (East US) and one in the secondary DR region (West US).

To ensure user profiles are available in the secondary region after a failure, the FSLogix Cloud Cache service is required. Cloud Cache continuously replicates a user's profile container from the primary storage (e.g., Azure Files in East US) to a secondary storage location (e.g., Azure Files in West US). This ensures that if the primary region fails, users can sign in to the DR host pool and access their replicated profiles immediately.

Microsoft Learn (Official Vendor Documentation): "Business continuity and disaster recovery for Azure Virtual Desktop"

Reference (for Design): In the section "Host pools," the documentation states: "To make Azure Virtual Desktop resilient to outages, we recommend you deploy host pools in different regions... This article assumes a primary/secondary region (active-passive) approach..." This aligns with creating one host pool in East US and another in West US.

Reference (for Service): In the section "FSLogix profile containers," the documentation states: "To provide resiliency for user profiles... we recommend using FSLogix Cloud Cache... Cloud Cache creates a near-real-time replica of the user profile... in a different region..." This confirms Cloud Cache is the correct service for profile DR.

Microsoft Learn (Official Vendor Documentation): "FSLogix Cloud Cache overview"

Reference (for Service): The documentation explicitly states: "Cloud Cache provides... business continuity by creating a 'near-real-time' replica of the profile container... This replication... is often used in disaster recovery (DR) plans."

To add a new session host virtual machine to an Azure Virtual Desktop (AVD) host pool, a registration token is required. The New-AzWvdRegistrationInfo PowerShell cmdlet generates this token for a specific host pool. This token is then used by the AVD agent during its installation on the virtual machine to securely register the machine with the AVD control plane. Generating this token is a prerequisite and therefore one of the first AVD-specific commands run in the deployment process for a new session host.

B. Get-AzApiManagementSsoToken: This cmdlet is part of the Azure API Management module and is used to generate a single sign-on (SSO) token, which is unrelated to AVD session host deployment.

C. Set-AzWvdADDomainExtension: This is not a valid or standard cmdlet in the Az.DesktopVirtualization PowerShell module. Active Directory settings are typically configured on the host pool itself, not as a first step for adding a host.

D. Update-AzWvdSessionHost: This cmdlet is used to modify the properties of an existing session host that is already registered in a host pool, such as setting its drain mode. It is not used for initial deployment.

1. Microsoft Learn

Official Documentation. New-AzWvdRegistrationInfo. This document describes the cmdlet used to create a registration token for a host pool

which is necessary for adding new session hosts.

Reference: New-AzWvdRegistrationInfo cmdlet syntax and description section.

2. Microsoft Learn

Official Documentation. Create a host pool with PowerShell or the Azure CLI. This guide outlines the end-to-end process. Step 2 explicitly details creating a registration token using New-AzWvdRegistrationInfo before creating the virtual machines that will become session hosts.

Reference: Section "Create a registration token".

3. Microsoft Learn

Official Documentation. Update-AzWvdSessionHost. This document confirms that the Update-AzWvdSessionHost cmdlet is for modifying an already-registered session host

not for initial deployment.

Reference: Update-AzWvdSessionHost cmdlet description and examples.

An Intune compliance policy is designed to evaluate a device's state against a predefined set of rules (e.g., requiring disk encryption, a minimum OS version, or an active antivirus). Its primary function is to report on the device's compliance status and integrate with Azure AD Conditional Access to allow or block access to corporate resources. It does not, however, actively push or enforce specific application settings, such as configuring security features within the Microsoft Edge browser. The correct Intune feature for this task is a device configuration profile, specifically using the Settings Catalog or Administrative Templates (ADMX) for Microsoft Edge.

A. Yes: This is incorrect. A compliance policy assesses a device's state but does not configure application-level settings. A device configuration profile is required to deploy specific settings to an application like Microsoft Edge.

1. Microsoft Learn

Intune Documentation

"Use compliance policies to set rules for devices you manage with Intune."

Reference: Under the "How compliance policies work" section

it states

"Device compliance policies are a key feature when using Intune to protect your organization's resources. In Intune

you can create rules and settings that devices must meet to be considered compliant... When a device is compliant

that device is given access to your organization's resources." This highlights its role in assessment and access control

not direct configuration of app settings.

2. Microsoft Learn

Intune Documentation

"Add Microsoft Edge policy settings to Microsoft Intune."

Reference: The introductory paragraph states

"You can use Microsoft Intune to configure Microsoft Edge policy settings. This article shows you how to configure Microsoft Edge policy settings by using either the Settings Catalog or Administrative Templates." This explicitly identifies the correct tools for the task described in the question.

3. Microsoft Learn

Intune Documentation

"What are Microsoft Intune device profiles?"

Reference: The overview section states

"Microsoft Intune includes settings and features you can enable or disable on different devices within your organization. These settings and features are added to 'configuration profiles.' You can create profiles for different devices and different platforms... When the profile is ready

you can then deploy the profile to user and device groups in your organization." This confirms that configuration profiles are the mechanism for deploying settings.

To migrate an Azure file share backup between vaults, you cannot simply "move" the backup data. You must stop the backup in the source vault (Vault1).

1. Backup items: You must navigate here to locate the specific file share and "Stop backup." If you intend to delete the old data to avoid costs or conflicts, you must choose the option to "Delete backup data."
2. Backup policies: While the policy itself isn't "changed" to move the vault, in the context of preparing Vault1 for this change (and potentially cleaning up or dissociating the resource), the policy governing that specific share must be managed or the share must be removed from it to break the link between the resource and the vault.

Microsoft Learn (Official Azure Documentation): "Back up Azure file shares" section on managing backups. It specifies that to change vaults, one must stop protection in the current vault before re-registering the storage account in a new vault.

Microsoft Learn: "Delete a Recovery Services vault." This documentation details that a vault cannot be deleted or resources moved unless all Backup items are stopped and deleted.

Microsoft Azure Documentation: "Common questions - Azure Files backup." Specifically addresses moving backups between vaults, stating it requires stopping the backup in the source and starting fresh in the target.

Microsoft Learn: "Manage Azure file share backups." Section on "Stop protection for an Azure file share" highlights the use of the Backup Items menu to initiate this process.

To enable FSLogix profile containers, the FSLogix agent software must be present on the session host virtual machines. The standard "Windows 10 multi-session + Microsoft 365 Apps" gallery image does not include the FSLogix agent by default. Therefore, after preparing the host pool and the Azure Files share for identity-based authentication, the immediate next step is to download and install the FSLogix agent on each session host. Only after the agent is installed can it be configured to use the specified file share for storing user profiles.

A. A shared access signature (SAS) key is an alternative authentication method and is not used when the file share is configured for identity-based authentication with Azure AD DS.

C. Disabling shared key access is a security hardening best practice for the storage account, not a functional prerequisite for configuring the FSLogix agent on the session hosts.

D. The FSLogix settings (typically registry keys) can only be configured after the FSLogix agent software has been successfully installed on the session hosts.

1. Microsoft Learn. "Tutorial: Configure a profile container with Azure Files and Azure AD DS." Azure Virtual Desktop documentation. In the section "Configure FSLogix on session host VMs

" the first step listed after preparing the storage and permissions is to download and install the FSLogix agent on the session host VMs. This confirms installation precedes configuration.

Reference: https://learn.microsoft.com/en-us/azure/virtual-desktop/create-fslogix-profile-container#configure-fslogix-on-session-host-vms

2. Microsoft Learn. "Download and install FSLogix." FSLogix documentation. This document outlines the installation process for the core FSLogix components (FSLogix Apps Agent) on the target machines

which is a mandatory prerequisite for its operation.

Reference: https://learn.microsoft.com/en-us/fslogix/install-ht (See section "FSLogix installation").

3. Microsoft Learn. "Authorize access to Azure Files using a shared access signature." Azure Storage documentation. This document explains that SAS provides delegated access and is an alternative to using the storage account key or identity-based authentication

confirming it is not the correct method for the described scenario.

Reference: https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview (See section "When to use a shared access signature").