Free Microsoft AZ-140 Practice Test Questions MCQs

Explanation:
This question is about selecting the appropriate tool for planning an Azure Virtual Desktop deployment. When designing an AVD environment, one of the most critical initial steps is identifying the Azure region that will provide the lowest network latency for your users. High latency negatively impacts user experience, causing slow screen rendering and input lag. The tool must be capable of estimating latency between user locations and potential Azure regions before any infrastructure is deployed.

Correct Option:

B. Azure Virtual Desktop Experience Estimator
This is a web-based tool designed specifically for AVD pre-deployment planning. It allows you to input user locations and then visualizes estimated round-trip latency to various Azure regions on a map. The tool provides color-coded performance indicators (Excellent, Good, Poor) based on latency thresholds, helping administrators make data-driven decisions about which region will deliver the best user experience before deploying any host pools.

Incorrect Options:

A. Azure Traffic Manager
Azure Traffic Manager is a DNS-based traffic routing service that directs incoming requests to different endpoints based on routing methods like performance or priority. It operates at the DNS level and requires deployed endpoints to function. It cannot be used during the planning phase to estimate latency between user locations and Azure regions where no resources exist yet.

C. Azure Monitor for Azure Virtual Desktop
Azure Monitor for AVD is a post-deployment monitoring solution that provides insights into the health and performance of your existing AVD environment. It tracks metrics like connection success rates, session host performance, and user login times. Since it requires an already deployed AVD infrastructure to collect telemetry data, it cannot assist with initial region selection planning.

D. Azure Advisor
Azure Advisor analyzes your existing Azure resources and configurations to provide personalized recommendations for cost optimization, performance improvement, reliability enhancement, and security. While it can suggest performance improvements for deployed AVD environments, it cannot predict latency or recommend deployment regions for planned infrastructure that does not yet exist.

Reference:
Microsoft Learn: Plan and deploy Azure Virtual Desktop - Choose the right Azure region for Azure Virtual Desktop

Explanation:
This question tests your knowledge of the correct sequence for deploying Azure NetApp Files to store FSLogix profile containers for Azure Virtual Desktop. Azure NetApp Files requires a specific order of operations when setting up storage for FSLogix profiles. The process involves creating the foundational NetApp account, then establishing the capacity pool (which defines service level and size), followed by creating the volume, and finally configuring the Active Directory connection to enable authentication and access for AVD session hosts.

Correct Option (Order):

Create a NetApp account
This is the first step after registering the resource provider. The NetApp account serves as the administrative container and parent resource for all subsequent NetApp Files resources within a specific Azure region. Without creating this account first, you cannot proceed with capacity pools or volumes.

Create a capacity pool
The capacity pool must be created within the NetApp account before volumes can be provisioned. It defines the service tier (Standard, Premium, Ultra), size, and QoS type for the volumes. Capacity pools are the fundamental unit of provisioned capacity in Azure NetApp Files.

Create a volume

Volumes are created within capacity pools and consume the pool's provisioned capacity. For FSLogix profile containers, you would create a volume configured for SMB protocol access. The volume inherits its performance characteristics from the parent capacity pool.

Configure an Active Directory connection
The AD connection must be configured to enable SMB authentication for the volume. This step is typically done during or immediately after volume creation to ensure session hosts can join the domain and access profile containers. The connection requires proper networking (VNet injection) and domain join credentials.

Incorrect Actions Not Used:

Create and assign a managed identity -
This is not required for Azure NetApp Files configuration. Managed identities are used for Azure resources to authenticate to other services without credentials, but NetApp Files uses AD authentication for SMB access rather than managed identities.

Create an Azure file share -
This is for Azure Files (another storage solution), not Azure NetApp Files. Azure file shares are created within storage accounts and use a different architecture than NetApp Files. FSLogix profiles can use either solution, but the question specifically asks for Azure NetApp Files.

Reference:
Microsoft Learn: Deploy Azure NetApp Files for Azure Virtual Desktop - Create and manage volumes for Azure NetApp Files

Explanation:
This question tests your understanding of Azure Shared Image Gallery (now called Azure Compute Gallery) constraints, specifically regarding region alignment and image definition requirements. The image definition Image1 was created in the East US region within SharedGallery1, which resides in West Europe. When creating image versions, the source VM must be in the same region as the target image definition. Additionally, the image definition specifies "Specialized" as the operating system state, which allows capturing from generalized or specialized VMs, so this is not a limiting factor.

Statement 1: You can use the operating system disk of VM1 as a source for a version of Image1.

Answer: No

Explanation:
VM1 is located in West Europe. Although SharedGallery1 is also in West Europe, the image definition Image1 was explicitly created in the East US region. Image versions must be created in the same region as the image definition. Since VM1 and Image1 are in different regions (West Europe vs. East US), you cannot use VM1's OS disk as a source. Cross-region image version creation is not supported directly from a source VM.

Statement 2: You can use the operating system disk of VM2 as a source for a version of Image1.
Answer: Yes

Explanation:
VM2 is located in East US, which matches the region where the image definition Image1 was created. This regional alignment is required when creating image versions from source VMs. The operating system state of "Specialized" in the image definition allows capturing from specialized VMs without requiring generalization. Therefore, VM2's OS disk is a valid source for creating a new image version of Image1.

Statement 3: You can use the operating system disk of VM3 as a source for a version of Image1.

Answer: No

Explanation:
VM3 is located in West US, while the image definition Image1 resides in East US. The region mismatch prevents using VM3 as a source for creating an image version. Even though the gallery itself (SharedGallery1) is in West Europe, the image definition has its own region setting that determines where image versions can be created. The source VM must be in the same region as the image definition.

Reference:
Microsoft Learn: Create an image definition and image version - Image versions must be created in the same region as the image definition they belong to.

Explanation:
This question tests your understanding of disaster recovery planning for Azure Virtual Desktop. When designing failover capabilities between regions, you need a structured recovery approach. The first step in any Azure disaster recovery strategy involving virtual machines is to set up Azure Site Recovery, which requires a Recovery Services vault as the foundational component. This vault stores replication data and orchestrates failover operations for session hosts.

Correct Option:

A. Create a Recovery Services vault.
The Recovery Services vault is the primary container for Azure Site Recovery and Backup services. Before you can replicate any session hosts from East US to West US, you must create this vault in the target or source region. It manages replication policies, stores recovery points, and coordinates failover workflows. Without this vault, you cannot enable replication or perform orchestrated failover of your session hosts.

Incorrect Options:

B. Create a virtual machine snapshot of each session host.
While snapshots can capture VM state, they are manual backup mechanisms, not automated disaster recovery solutions. Snapshots don't provide orchestrated failover, replication to another region, or automated recovery plans. Azure Site Recovery provides continuous replication and controlled failover, which is more appropriate for regional failover scenarios than manual snapshots.

C. Create an Azure Storage account that uses geo-redundant storage (GRS).
GRS storage accounts replicate data to a paired secondary region, but this is for storage data only, not for VM replication. While FSLogix profile containers or other AVD data might use such storage, the question asks about failing over the host pool itself, which requires replicating the session host VMs, not just storage accounts.

D. Create a new host pool.
Creating a new host pool in West US is part of the eventual disaster recovery configuration, but it is not the first step. Before creating the target host pool, you need to establish replication for your existing session hosts using Azure Site Recovery, which requires the Recovery Services vault as the prerequisite foundation.

Reference:
Microsoft Learn: Set up disaster recovery for Azure VMs to a secondary Azure region - Prerequisites include a Recovery Services vault

Explanation:
This question focuses on controlling access to Azure Virtual Desktop managed resources (session hosts) specifically from on-premises users. The requirement is to restrict connectivity so that only users originating from the on-premises network can access the AVD session hosts. Azure Firewall is already deployed in the environment and can filter traffic based on source IP addresses. Since the on-premises network connects via site-to-site VPN, on-premises traffic will appear with specific source IP ranges that can be identified and allowed through the firewall.

Correct Option:

A. An Azure Firewall rule.
Azure Firewall can filter inbound and outbound traffic at the network and application levels. By creating a network rule that allows Remote Desktop Protocol (RDP) traffic (TCP port 3389) only from the on-premises network IP ranges to the session hosts' private IP addresses, you can restrict access exclusively to on-premises users. This solution minimizes effort because Azure Firewall is already deployed and provides centralized policy management without modifying each session host individually.

Incorrect Options:
B. A conditional access policy.
Conditional access policies operate at the Azure Active Directory level and control authentication to Azure services based on user identity, device compliance, location, and risk. While they can restrict which users can sign in to AVD, they cannot control network-level access to the session hosts themselves. This policy also requires Azure AD Premium licensing and does not address the network connectivity requirement specifically.

C. A network security group (NSG) rule.
NSGs provide basic traffic filtering at the subnet or network interface level. While you could apply NSG rules to restrict RDP access to on-premises IP ranges, this would require applying the same rules to every session host or the subnet. However, NSGs lack the centralized management and advanced capabilities of Azure Firewall, making this less optimal when Azure Firewall is already available.

D. A user-defined route.
User-defined routes (UDRs) control network traffic routing paths, not access permissions. They determine how traffic flows between subnets, virtual networks, and on-premises networks. UDRs cannot filter or block traffic based on source IP addresses or protocols; they only direct where traffic should be sent. Therefore, UDRs cannot enforce the access restriction requirement.

Reference:
Microsoft Learn: Azure Firewall network rules - Filter network traffic across multiple subscriptions and virtual networks

Explanation:
This question tests your understanding of internet filtering and Microsoft service access in Azure Virtual Desktop environments. Modifying the IP configuration of each session host individually is not an effective approach for controlling internet access while maintaining access to Microsoft services. IP configuration changes only affect the network addressing of the session hosts, not traffic filtering or routing rules. This approach would not prevent users from accessing the internet through the session hosts.

Correct Option:

B. No.
Modifying the IP configuration of each session host does nothing to restrict outbound internet access from user sessions. IP configuration changes only modify settings like private IP addresses, DNS servers, or enable/disable public IPs. To control internet access while allowing Microsoft services, you need network filtering solutions like Azure Firewall with service tags, route tables forcing traffic through firewalls, or proxy configurations. The proposed solution does not implement any traffic filtering mechanism.

Incorrect Option Explanation (Not applicable as answer is No):
The solution fails because IP configuration changes do not provide traffic filtering capabilities. Even if you remove public IPs from session hosts, they could still access the internet through NAT or Azure's default outbound access. To selectively block internet while allowing Microsoft services, you need application or network rules that specifically permit Microsoft service endpoints (using service tags) while denying all other outbound traffic.

Reference:
Microsoft Learn: Network considerations for Azure Virtual Desktop - Controlling outbound access and using service tags for Microsoft services

Explanation:
This question tests your knowledge of Azure Virtual Desktop network requirements, specifically for Windows activation. Azure Virtual Desktop session hosts running Windows 10 or Windows 11 (including multi-session editions) must activate Windows with Microsoft licensing servers. This requires specific outbound connectivity to the Key Management Service (KMS) endpoints. The activation process uses a standard port and specific URLs that must be allowed through firewalls for proper licensing validation.

Correct Option:

Outbound URL: kms.core.windows.net
Windows activation for Azure Virtual Desktop session hosts requires connectivity to Microsoft KMS servers. The URL kms.core.windows.net is the Azure-specific KMS endpoint for Windows activation in cloud environments. When session hosts connect to this endpoint, they can activate Windows licenses properly. Without this access, session hosts may enter a grace period and eventually become deactivated, impacting user experience and compliance.

Outbound Port: 1688
Port 1688 is the default port used by Key Management Service for Windows activation. This is not a standard web port but is specifically designated for KMS communications. The session hosts must be able to establish outbound TCP connections to kms.core.windows.net on port 1688 to complete the activation process successfully. Firewalls must allow this specific port for the activation traffic.

Incorrect URLs:

*.wpd.microsoft.us - This endpoint is for Windows Update and diagnostic services, not specifically for activation.

*.eh.servicebus.windows.net - This is used for Azure Event Hubs and service bus messaging, unrelated to Windows activation.

gcs.prod.monitoring.core.windows.net - This endpoint is for Azure monitoring and diagnostics services, not for KMS activation.

Incorrect Ports:

80 (HTTP) - Used for general web traffic and some update services, but not for KMS activation.

389 (LDAP) - Used for Lightweight Directory Access Protocol, typically for Active Directory communications.

443 (HTTPS) - Used for secure web traffic and many Azure services, but KMS activation specifically requires port 1688.

Reference:
Microsoft Learn: Azure Virtual Desktop network connections - Session host virtual machine outbound connectivity requirements for Windows activation

Explanation:
This question tests your knowledge of disaster recovery strategies for Azure Virtual Desktop that minimize failover times while meeting specific requirements. The solution must provide equivalent resources in West US, maintain a single client icon for users, allow manual failover initiation, and minimize failover times. Azure Site Recovery provides orchestrated replication and failover for virtual machines between regions, which addresses all requirements while ensuring minimal downtime through continuous replication.

Correct Option:

E. Enable Azure Site Recovery replication of the virtual machines to the West US region.
Azure Site Recovery (ASR) continuously replicates session host VMs from East US to West US, ensuring that replicated VMs are ready for failover with minimal data loss. ASR supports manual failover initiation by administrators and provides Recovery Plans to orchestrate the startup order of replicated VMs. After failover, users can connect through the same single Remote Desktop client icon because the host pool configuration and workspace assignments can be maintained or updated post-failover, minimizing disruption.

Incorrect Options:

A. Create new session hosts in the West US region and add the session hosts to an existing host pool.
While this creates equivalent resources, it does not provide disaster recovery automation. Adding West US hosts to the existing East US host pool would create a multi-region host pool, but this requires ongoing management of both sets of hosts and does not address failover orchestration. It also does not replicate existing session state or configurations from East US hosts.

B. Enable Azure Backup to a Recovery Services vault in the West US region.
Azure Backup provides backup and restore capabilities but is not designed for rapid failover. Restoring entire VMs from backup takes significantly longer than ASR failover and does not provide continuous replication. Backup solutions are for data protection and recovery from corruption or accidental deletion, not for minimizing regional disaster failover times.

C. Configure a shared image gallery that has replicas in the East US and West US regions.
Shared image galleries store VM images, not running VMs. While replicating images ensures you can deploy new VMs in West US from the same image, it does not provide failover for existing session hosts. You would still need to deploy new VMs and configure them, which takes time and does not preserve the state of existing user sessions or installed applications.

D. Create an additional host pool in the West US region.
Creating a separate host pool provides equivalent resources but introduces management complexity. Users would need separate workspace assignments or multiple icons unless you configure cross-region workspace aggregation. More importantly, this does not replicate existing VMs or their state, and you would need to deploy and configure new session hosts separately without any automated failover mechanism.

Reference:
Microsoft Learn: Set up disaster recovery for Azure VMs to a secondary Azure region using Azure Site Recovery

Explanation:
This question tests your understanding of disk management for Azure Virtual Desktop session hosts, specifically regarding drive letter assignments and page file configuration. The exhibit shows that Host1 currently has a Temporary Storage disk assigned drive letter D with a page file on it. To install an application requiring 500 GB on drive D, you need to add a new larger data disk and assign it drive D. However, drive D is currently in use by Temporary Storage, so you must first free up that drive letter by moving the page file and reassigning or removing the Temporary Storage drive letter.

Correct Order:

Move the page file to drive C.
Before you can change the drive letter of Temporary Storage or remove its page file, you must first relocate the page file to another location. Drive C has sufficient free space (110.40 GB free) to accommodate the page file. This ensures the system remains stable during the disk reconfiguration process.

Change the drive letter of Temporary Storage (D:).
After moving the page file, you can now change the drive letter of the existing Temporary Storage disk from D to another available letter (such as E or T). This frees up drive letter D for the new data disk you will add. Temporary Storage will continue to function with its new drive letter.

Add the new disk and assign drive D.
With drive letter D now available, you can add the new 500 GB data disk to the session host. During disk initialization and formatting, you can assign it the desired drive letter D. This ensures the application expecting data on D will find the new large disk.

Move the page file to Temporary Storage (optional but not required).
Note: The correct sequence does not include moving the page file back. After changing the Temporary Storage drive letter, you could optionally move the page file back to Temporary Storage, but this step is not among the required four actions for meeting the goal. The solution maintains current performance by keeping the page file on drive C, which has adequate space and performance characteristics.

Incorrect Actions Not Used:
Move the page file to System Reserved - System Reserved partition is only 500 MB and is not suitable for page file storage. It is a system partition used for boot files and BitLocker, not for data or page files.

Mark Temporary Storage (D:) as Active - Marking a partition as Active is for system boot partitions only. Temporary Storage is a data disk and should never be marked as Active, as this could interfere with the boot process.

Move the page file to Temporary Storage - This action would be performed after changing the drive letter if you wanted to return the page file to Temporary Storage, but it is not required for the main goal of adding a new D drive. The question asks for four actions in sequence, and this would be an optional fifth step.

Reference:
Microsoft Learn: Understanding temporary storage on Azure VMs - Temporary storage drive letter assignment and page file configuration best practices

Explanation:
This question tests your knowledge of managing MSIX package applications in Azure Virtual Desktop using PowerShell. The scenario describes a third-party application (App1) installed monthly via MSI with changing executable filenames. To automate making new versions available via RemoteApp while maintaining the same user experience (same icon in Windows Desktop client), you need to leverage MSIX application attach functionality. This requires registering the new MSIX package and then creating or updating the RemoteApp application reference.

Correct Options:

D. New-AzWvdMsixPackage
This cmdlet registers an MSIX package with an Azure Virtual Desktop host pool. When a new version of App1 is installed monthly, you must first register the MSIX package with Pool1 using this cmdlet. It makes the package available to the host pool and allows it to be referenced by RemoteApp applications. The cmdlet requires parameters specifying the host pool, package path, and package dependencies.

B. New-AzWvdApplication
After registering the MSIX package, you need to create a new RemoteApp application that points to this specific package version using New-AzWvdApplication. This cmdlet creates an application in a RemoteApp group that references the registered MSIX package. Users will see the same application icon in their Windows Desktop client because the RemoteApp group and application name can remain consistent while pointing to different underlying package versions each month.

Incorrect Options:

A. Remove-AzWvdApplication
This cmdlet removes an existing RemoteApp application. While you might eventually need to clean up old application versions, this is not part of the monthly automation process for making new versions available. Removing the existing application would disrupt user experience by temporarily removing the icon from clients.

C. New-AzWvdApplicationGroup
This cmdlet creates a new RemoteApp or Desktop application group. Creating a new application group each month would change how users access App1, requiring new workspace assignments and potentially multiple icons in the client. This violates the requirement to maintain the same user experience.

E. New-AzRoleAssignment
This cmdlet assigns Azure RBAC roles to users, groups, or service principals. It is unrelated to publishing applications or managing MSIX packages in Azure Virtual Desktop and does not help automate the monthly application update process.

F. Remove-AzWvdMsixPackage
This cmdlet removes an MSIX package registration from a host pool. While you might use this to clean up old package versions, it is not required for making new versions available. Removing the existing package would break the current application until the new one is registered and published.

Reference:
Microsoft Learn: Publish MSIX applications with PowerShell in Azure Virtual Desktop - Use New-AzWvdMsixPackage to register packages and New-AzWvdApplication to publish them