Explanation:
This question tests the fundamental Azure Virtual Desktop (AVD) access control model. Access to AVD resources (like desktops and applications) is not managed via local machine groups on the session hosts. Instead, it is controlled through Azure role-based access control (RBAC) assignments on the AVD objects themselves. This centralizes management and scales across all VMs in the pool.

Correct Option:

D. Create a role assignment.
This is the correct answer. You must create a role assignment that grants the pilot user group (as a security principal) the appropriate AVD user role (like Desktop Virtualization User) on the application group or workspace. This assignment authorizes the users to see and launch the resources in their feed.

Incorrect Options:

A. Create a role definition.
A role definition is a custom set of permissions you create if the built-in Azure roles don't meet your needs. It does not, by itself, grant access. You must still create a role assignment that links a user/group to this custom role. This step is unnecessary for standard user access.

B. Add the users to a Remote Desktop Users group on the virtual machines.
While this local group is technically required for RDP logon, the AVD agent automatically manages its membership based on Azure RBAC assignments. Manual addition is not scalable, prone to error, and bypasses the central AVD management model.

C. Add the users to the local Administrators group on the virtual machines.
This grants excessive administrative privileges on the session host VMs, violating the principle of least privilege and posing a major security risk. Users only need access to their remote desktop session, not administrative control of the VM.

Reference:
Microsoft Docs: Delegate access in Azure Virtual Desktop - Explains that you grant user access by assigning the built-in role "Desktop Virtualization User" to users/groups on an application group.

Explanation:
This question tests the prerequisite network configuration for deploying Azure Virtual Desktop (AVD) session hosts into an Azure AD DS managed domain. The session host VMs must be able to resolve and communicate with the Azure AD DS managed domain controllers to join the domain. This requires the virtual network to be configured to use the Azure AD DS-provided DNS servers.

Correct Option:

B. Modify the DNS settings of VNET1.
This is the correct first step. When you deploy an Azure AD DS managed domain, it provides two dedicated IP addresses that act as DNS servers for the domain. You must configure VNET1's DNS server settings to use these Azure AD DS-provided IP addresses. This ensures any VMs deployed into VNET1 (including future AVD session hosts) can resolve the litwareinc.com domain and successfully join it.

Incorrect Options:

A. Modify the settings of the litwareinc.com DNS zone.
The DNS zone in Azure AD DS is managed by the service itself. You cannot directly modify its core settings (like NS or SOA records) to facilitate VM domain join. The resolution issue is at the network level (VNET configuration), not the zone level.

C. Add a custom domain name to contoso.com.
This relates to adding a verified domain (like litwareinc.com) to the Azure AD tenant contoso.com. This step is already implied as completed because the Azure AD DS domain litwareinc.com exists. It is not an action that resolves the session host's ability to find and join the domain.

D. Implement Azure AD Connect cloud sync.
Azure AD Connect (or Cloud Sync) is used to synchronize identities from an on-premises Active Directory to Azure AD. It is not required for Azure AD DS, which is a separate, standalone managed domain service. It does not help VMs join the Azure AD DS domain.

Reference:
Microsoft Docs: Update DNS settings for the Azure virtual network - Explicitly states that after enabling Azure AD DS, you must update the virtual network's DNS settings to point to the Azure AD DS DNS IP addresses.

Explanation:
This question addresses a specific issue in multi-session AVD environments where Windows 10/11 Enterprise multi-session or Windows Server session hosts can automatically remove unprovisioned language packs to save disk space. The French language pack was likely installed as a "standalone" pack and not integrated into the base image, causing the system to clean it up.

Correct Option:

B. Apply a Group Policy setting to disable the Time & language settings.
This is correct. The specific policy is "Disable the Time & language settings page" located under Computer Configuration > Administrative Templates > Control Panel. Enabling this policy prevents the system's automatic cleanup process from removing language packs that are not in the provisioned list. It locks the language configuration, preserving manually installed language packs like French.

Incorrect Options:

A. Apply a Group Policy setting that blocks the cleanup of unused language packs.
There is no direct Group Policy named exactly this. The cleanup behavior is controlled indirectly by policies related to language provisioning and the settings page, not by a standalone "cleanup blocker."

C. Configure the international settings on each host.
This is a manual, per-host action that does not prevent the system cleanup process. The settings would be reverted when the system automatically removes the unprovisioned language pack. It is not a permanent, policy-enforced solution.

D. Assign a default time zone on each host.
This has no relation to preserving installed language packs. Time zone and language settings are separate configurations.

Reference:
Microsoft Docs: Language packs in Windows 10/11 multi-session - Explains that language packs can be removed if not provisioned and recommends using Group Policy to restrict changes to language settings to prevent this automatic cleanup.

Explanation:
This question tests your knowledge of PowerShell cmdlets for managing Azure Virtual Desktop (AVD) user sessions in the modern Az.DesktopVirtualization module. The requirement is to actively sign out (log off) existing user sessions from the primary location's session hosts, which is a direct administrative action on a user session object.

Correct Option:

B. Remove-AzWvdUserSession.
This is the correct cmdlet from the Az.DesktopVirtualization PowerShell module. It is specifically designed to log off a user session from a session host in an AVD host pool. You can specify the host pool, session host, and session ID to target the users in the primary location for sign-out.

Incorrect Options:

A. Invoke-RdsUserSessionLogoff.
This cmdlet belongs to the legacy RDS PowerShell module (Microsoft.RDInfra.RDPowershell), which was used for the classic Windows Virtual Desktop deployment model. It is not the correct module for current Azure Resource Manager (ARM)-based AVD deployments.

C. Invoke-RestMethod.
This is a generic PowerShell cmdlet used to call REST API endpoints. While the underlying AVD action might use a REST API, this is not the direct, purpose-built cmdlet for managing AVD user sessions. It requires manual construction of the API call, which is inefficient and error-prone.

D. Remove-Alias.
This cmdlet is used to remove an alias (a nickname for a cmdlet) from the current PowerShell session. It has absolutely nothing to do with managing AVD user sessions or resources.

Reference:
Microsoft Docs: Remove-AzWvdUserSession - The official documentation for the cmdlet used to log off a user session in an Azure Virtual Desktop host pool.

Explanation:
This question tests your knowledge of Azure VM series and their performance characteristics, specifically focusing on bursting capability. The key requirement is the ability to accumulate CPU credits during low usage and use them for higher performance later. This is the defining feature of burst-capable VM series, which are optimized for workloads with variable CPU demand.

Correct Option:

B. B-series.
The correct answer is B-series (Burstable). VMs in the B-series (like B2s, B4ms) have a baseline CPU performance. When usage is below baseline, they accumulate CPU credits. When an application requires higher CPU performance, the VM can burst above its baseline by consuming those accumulated credits. This perfectly matches the requirement described.

Incorrect Options (Based on Standard VM Series Naming):

A. H-series.
The H-series is designed for high-performance computing (HPC) workloads. These are specialized VMs with high CPU core counts, high memory bandwidth, and fast InfiniBand networking. They do not feature a bursting model; they provide consistent, high-level performance.

C. D-series / Dsv3-series.
The D-series (General Purpose) and Dsv3-series are standard, fixed-performance VMs. They offer consistent CPU performance at their selected tier but do not have a credit-based bursting mechanism. For variable performance, you would need to scale the VM size up/down or use the B-series.

D. A-series / Av2-series.
The A-series are basic, economical VMs for entry-level workloads. They offer consistent performance at a low cost but do not support CPU credit-based bursting. They are not suitable for the described scenario.

Reference:
Microsoft Docs: B-series burstable virtual machine sizes - Explains how B-series VMs can accumulate credits when using less than the baseline and burst when needed.

Explanation:
This question tests your ability to diagnose performance issues (specifically screen update frequency) within an active AVD session. The requirement is to quickly identify the resource bottleneck type (server, network, client) from within the problematic session itself. The most direct, real-time method is to examine performance counters that differentiate between graphics rendering (server) and network transport issues.

Correct Option:

D. From within the current session, use Performance Monitor to display the values of all the RemoteFX Graphics(*)\Frames Skipped/Second counters.
This is correct. Within the Performance Monitor (perfmon) on the session host (accessible from within your session), the RemoteFX Graphics counters are key. High values in specific sub-counters, like "Frames Skipped/Second - Insufficient Server Resources" vs. "Frames Skipped/Second - Insufficient Network Resources", directly identify whether he bottleneck is the server (CPU/GPU) or the network. This provides immediate, actionable diagnostics.

Incorrect Options:

A. From within the current session, use the Azure Virtual Desktop Experience Estimator.
The Experience Estimator is a planning tool used before deployment to estimate user density based on workloads. It cannot diagnose real-time performance issues in an existing session.

B. From Azure Cloud Shell, run the Get-AzOperationalInsightsWorkspaceUsage cmdlet...
This cmdlet retrieves log analytics workspace usage data (volume of data ingested), not real-time session performance metrics. It is irrelevant for troubleshooting screen update frequency.

C. From Azure Cloud Shell, run the Get-AzWvdUserSession cmdlet...
This cmdlet retrieves administrative information about a user session (e.g., session ID, state, host name) but provides no performance or diagnostic data about resource bottlenecks causing graphics issues.

Reference:
Microsoft Docs: Troubleshoot Azure Virtual Desktop graphics and GPU issues - Recommends using Performance Monitor and the RemoteFX Graphics counters to identify the root cause of graphical performance issues.

Add VHDlocations entries to the Windows registry.

Configure an AppLocker policy on the session hosts

Reference:
https://docs.microsoft.com/en-us/azure/virtual-desktop/security-guide

qwinsta

Reference:
https://docs.microsoft.com/en-us/azure/virtual-desktop/troubleshoot-vm-configuration

Preview features for Azure Virtual Desktop

Yes

Reference:
https://www.compete366.com/blog-posts/eight-tips-on-how-to-manage-azure-virtualdesktop-
avd/