AZ-140 Practice Questions

For FSLogix profile containers on Azure Files to be accessed by users on Microsoft Entra joined session hosts, identity-based authentication is required. Microsoft Entra Kerberos is the specific feature that enables seamless Single Sign-On (SSO) by allowing Microsoft Entra joined virtual machines to access SMB file shares using Microsoft Entra credentials. When enabled on the storage account, it allows the user's Kerberos ticket, obtained from Microsoft Entra ID during login, to be used for authenticating and authorizing access to the Azure Files share. This is the designated method for non-hybrid, cloud-native AVD environments.

A. a security profile set to Maximum compatibility

This is a configuration setting for Network File System (NFS) v4.1 shares, not for Server Message Block (SMB) shares, which are required by FSLogix.

B. Microsoft Entra Domain Services

While Microsoft Entra DS can provide identity for Azure Files, it is designed for scenarios requiring traditional domain services. For purely Microsoft Entra joined hosts, Microsoft Entra Kerberos is the more direct and appropriate solution.

D. a security profile set to Maximum security

Similar to option A, this is a security setting for NFS v4.1 shares to enforce Kerberos authentication, but it is not applicable to the SMB protocol used by FSLogix.

---

1. Microsoft Learn

Azure Virtual Desktop Documentation. "Create a profile container with Azure Files and Microsoft Entra ID." Under the section "Enable Microsoft Entra authentication on your storage account

" the documentation states

"To use Microsoft Entra ID as your authentication method

you must enable it on your storage account... For session hosts that are Microsoft Entra-joined

you must use Microsoft Entra Kerberos."

Reference: https://learn.microsoft.com/en-us/azure/virtual-desktop/create-fslogix-profile-container-azure-ad#enable-microsoft-entra-authentication-on-your-storage-account

2. Microsoft Learn

Azure Storage Documentation. "Overview of Azure Files identity-based authentication options for SMB access." This document provides a comparison table showing supported scenarios. For the "Microsoft Entra-joined VMs" client type

the supported identity source is "Microsoft Entra ID" and the required protocol is "SMB with Microsoft Entra Kerberos authentication."

Reference: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-active-directory-overview#supported-scenarios-and-restrictions

3. Microsoft Learn

Azure Storage Documentation. "Enable Microsoft Entra Kerberos authentication for Microsoft Entra-joined VMs to access Azure Files." This guide explicitly details the process for the scenario in the question. The prerequisite states: "Enable Microsoft Entra Kerberos authentication on your storage account to authenticate with Microsoft Entra user identities."

Reference: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-azure-ad-kerberos-entras-joined-vms (Prerequisites section)

4. Microsoft Learn

Azure Storage Documentation. "Create an NFS share." This document describes the "Security" tab during NFS share creation

which includes the "Maximum compatibility" and "Maximum security" options

confirming they are specific to NFS and not SMB.

Reference: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-how-to-create-nfs-shares?tabs=azure-portal#create-an-nfs-share (Step 10 in the "Create an NFS share" section)

Part 1: To meet performance requirements for internet name resolution, the Chennai office must resolve external DNS queries locally rather than routing them over the WAN to Boston. Configuring the Chennai DNS resolvers to use the local ISP's DNS servers as forwarders enables a "local internet breakout." This design avoids the added latency of the WAN link (Chennai-to-Boston) for internet-bound queries, significantly improving resolution speed and overall service performance.

Part 2: The Azure Virtual Desktop Experience Estimator is the official Microsoft web-based tool specifically designed to validate the user experience by measuring the round-trip time (RTT), or latency, from the user's current location to the nearest Azure Virtual Desktop control plane and deployment regions.

Microsoft Learn (Official Vendor Documentation). "Azure Virtual Desktop network connectivity." Discusses the importance of DNS resolution paths for performance. The principle of using the shortest, most local path for DNS (local breakout) is a fundamental networking best practice for distributed environments connecting to cloud services.

Microsoft Learn (Official Vendor Documentation). "Estimate Azure Virtual Desktop user experience."

Reference: This document explicitly introduces the tool for the required task. It states: "The Azure Virtual Desktop Experience Estimator... will help you estimate the connection round-trip time (RTT) from your current location through the Azure Virtual Desktop service... This information can help you assess the user experience you can expect..."

Microsoft Learn (Official Vendor Documentation). "Name resolution for resources in Azure virtual networks."

Reference: This document details DNS configuration options. In the section "Name resolution using your own DNS server," it describes the use of forwarders for hybrid scenarios to resolve non-authoritative (e.g., internet) names, which is the mechanism required by the correct answer for Part 1.

A comprehensive network security strategy for Azure Virtual Desktop (AVD) employs a defense-in-depth approach. This involves two primary actions:

1. Deploying Network Security Groups (NSGs) and Application Security Groups (ASGs): NSGs are fundamental for micro-segmentation. They filter traffic at the subnet and network interface level, controlling inbound, outbound, and east-west traffic for the session host VMs. ASGs simplify rule management by grouping VMs, such as all hosts in a pool, allowing for consistent policy application.

2. Deploying Azure Firewall: AVD session hosts require outbound internet access to specific FQDNs for the service to function. Azure Firewall is the recommended solution to centrally manage, filter, and log this outbound traffic, ensuring hosts can only reach required endpoints. Deploying two instances with Azure Firewall Manager ensures a highly available, centrally managed, and robust solution suitable for production environments.

B. Filter traffic by using outbound rules.

This describes a configuration step within a security tool (like an NSG or Firewall), not the deployment of the complete solution itself.

C. Filter traffic by using infrastructure rules.

This is a specific, advanced feature of Azure Firewall Premium. The primary action is deploying the firewall, not just configuring one type of rule.

D. Filter traffic by using inbound rules.

This describes a configuration step within a security tool (like an NSG), not the deployment of the complete solution itself.

F. Deploy an Azure Firewall instance and Azure Firewall Manager.

While correct in principle, option A is superior as it specifies two instances, implying a highly available design which is a best practice for production workloads.

1. Microsoft Learn. (2023). Security best practices for Azure Virtual Desktop. In the "Network security" section

it states

"Use a network security group (NSG) to protect your Azure Virtual Desktop environment... You can also use Azure Firewall to protect your environment and filter outbound traffic." This supports the use of both NSGs (Option E) and Azure Firewall (Option A).

2. Microsoft Learn. (2023). Use Azure Firewall to protect Azure Virtual Desktop deployments. This document explicitly recommends the architecture combining Azure Firewall for outbound traffic and NSGs. The "Prerequisites" and "Deploy the Firewall and policy" sections detail the deployment of the firewall

and the architecture diagram shows the NSG on the session host subnet.

3. Microsoft Learn. (2023). Application security groups. This document explains

"Application security groups enable you to configure network security as a natural extension of an application's structure

allowing you to group virtual machines and define network security policies based on those groups." This validates the use of ASGs with NSGs as a best practice (Option E).

4. Microsoft Learn. (2023). What is Azure Firewall? In the "Features" section

it highlights "Built-in high availability

" which is achieved through its design. Deploying multiple instances or using a zone-redundant configuration (implied by "two instances") enhances this for maximum uptime

supporting the choice of Option A for a robust solution.

The requirement is to route traffic between two virtual networks in different Azure regions (East US and West US) privately over the Microsoft backbone. Global virtual network (VNet) peering is the specific Azure feature designed for this purpose. It connects virtual networks across regions, and all traffic between the peered VNets is private and remains on the high-speed Microsoft backbone network, never traversing the public internet. This provides a low-latency, high-bandwidth connection between the resources in HostPool1 and Server1.

A. service endpoints: These provide a secure, direct connection from a virtual network to specific Azure PaaS services (like Azure Storage or SQL Database), not for connecting two virtual networks.

C. routing tables: These are used to define custom routes (UDRs) to control how traffic is directed within a VNet, but they do not establish the actual connectivity between two separate VNets.

D. Azure Traffic Manager: This is a DNS-based load balancer that directs client traffic to public-facing application endpoints. It does not handle private network traffic between virtual networks.

1. Microsoft Documentation

Azure Virtual Network

"Virtual network peering overview."

Section: Connectivity: "Once virtual networks are peered

resources in either virtual network can communicate with resources in the other virtual network with the same latency and bandwidth as if the resources were in the same virtual network."

Section: Global VNet peering: "Global VNet peering: Connecting virtual networks across Azure regions... Traffic between virtual machines in peered virtual networks is routed directly through the Microsoft backbone infrastructure

not through a gateway or over the public Internet."

2. Microsoft Documentation

Azure Virtual Network

"Virtual network service endpoints overview."

Section: Key benefits: "Virtual Network (VNet) service endpoints extend your virtual network private address space and the identity of your VNet to the Azure services

over a direct connection." This clarifies its purpose is for VNet-to-Azure-Service communication

not VNet-to-VNet.

3. Microsoft Documentation

Azure Traffic Manager

"What is Traffic Manager?"

Introduction: "Azure Traffic Manager is a DNS-based traffic load balancer. This service allows you to distribute traffic to your public facing applications across the global Azure regions." This confirms it operates at the DNS layer for public endpoints.

The Azure Virtual Desktop Experience Estimator is a web-based tool specifically designed to help plan AVD deployments. It measures the round-trip time (RTT) from a user's current location, through the AVD service, to each Azure region where session hosts can be deployed. This allows administrators to evaluate connection latency and identify the Azure region that will provide the lowest latency and, therefore, the best user experience for their end-users. This tool is intended for the pre-deployment and planning phase.

A. Azure Traffic Manager is a DNS-based load balancer that distributes traffic to existing public-facing applications across different Azure regions; it does not estimate latency for planning purposes.

C. Azure Monitor for Azure Virtual Desktop is a monitoring solution that provides insights into the performance and health of an existing AVD deployment, not for initial planning.

D. Azure Advisor is a recommendation service that analyzes existing Azure resources and provides guidance on optimizing for cost, security, performance, and reliability, not for pre-deployment latency tests.

1. Microsoft Learn. "Estimate Azure Virtual Desktop connection latency." Azure Virtual Desktop documentation. This document explicitly states

"The Azure Virtual Desktop Experience Estimator is a web-based tool that helps you evaluate the connection quality to Azure Virtual Desktop by determining the round-trip time (RTT) from your current location... to each Azure region in which you can deploy virtual machines."

2. Microsoft Learn. "What is Traffic Manager?" Azure Traffic Manager documentation. This source describes Traffic Manager as a service to "distribute traffic to your public facing applications across the global Azure regions

" confirming its role in traffic routing for existing services

not planning.

3. Microsoft Learn. "Use Azure Monitor for Azure Virtual Desktop to monitor your deployment." Azure Virtual Desktop documentation. This article details how the tool is a "dashboard built on Azure Monitor Workbooks that helps IT professionals understand their Azure Virtual Desktop environments

" confirming its use for monitoring existing deployments.

4. Microsoft Learn. "Introduction to Azure Advisor." Azure Advisor documentation. This page defines Advisor as a "personalized cloud consultant that helps you follow best practices to optimize your Azure deployments

" focusing on existing resources.

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."

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 recommended solution for delivering containerized applications in Azure Virtual Desktop (AVD) without installing them on session hosts. This technology uses MSIX packages to dynamically attach applications to a user session at logon. The applications run in a lightweight container, isolating them from the operating system. This approach simplifies session host image management, reduces image size, and allows for easier application updates and assignments to users without modifying the base virtual machine image.

A. EXE applications: These are traditional executable files that require direct installation on the session host's operating system, which contradicts the core requirement.

B. MSI packages: These are Windows Installer packages that also install applications directly onto the session host, rather than attaching them dynamically.

C. APPX app packages: These are primarily for Universal Windows Platform (UWP) apps and are installed on the operating system, not dynamically attached as required by the scenario.

1. Microsoft Learn. (2023). What is MSIX app attach?. In the "Key features" section

it states

"MSIX app attach is a way to deliver MSIX applications to both physical and virtual machines... When a user signs in

you dynamically attach the MSIX package with the application to their session. The application is contained in the MSIX package and is separated from the user and the operating system."

Source: https://learn.microsoft.com/en-us/azure/virtual-desktop/what-is-msix-app-attach

Section: "Key features".

2. Microsoft Learn. (2024). Application management overview for Azure Virtual Desktop. This document explicitly contrasts MSIX app attach with traditional methods. Under the "MSIX app attach" section

it clarifies

"The applications aren't locally installed on session hosts

which makes it easier to create custom images for your session hosts and helps to reduce cost for your organization."

Source: https://learn.microsoft.com/en-us/azure/virtual-desktop/app-management-overview

Section: "MSIX app attach".

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".

FSLogix profile containers require a network path to an SMB (Server Message Block) file share. When using Azure Files for this purpose, the correct path format is the Universal Naming Convention (UNC) path. The UNC path for an Azure Files share is constructed as \\.file.core.windows.net\. In this scenario, the storage account is store1 and the share is profiles, making the correct UNC path \\store1.file.core.windows.net\profiles. This path is configured in the VHDLocations registry key or Group Policy setting on the session hosts.

A. This is an HTTPS URL, not a UNC path. FSLogix uses the SMB protocol to mount the share, which requires a UNC path.

C. This path points to the Azure Blob Storage endpoint (.blob.core.windows.net), but FSLogix profile containers must be stored on an SMB share, such as Azure Files (.file.core.windows.net).

D. This is an HTTPS URL for the Blob Storage endpoint, which is incorrect for both the protocol and the storage service type.

1. Microsoft Learn. "Create a profile container with Azure Files and AD DS". Under the section "Configure FSLogix profile container registry settings

" the documentation specifies the value for VHDLocations must be a UNC path in the format \\.file.core.windows.net\.

2. Microsoft Learn. "FSLogix profile containers and Azure Files". In the "Configure profile containers" section

it explicitly states to set the VHDLocations registry entry to the UNC path of the Azure Files share.

3. Microsoft Learn. "Profile Container registry configuration settings". The documentation for the VHDLocations setting defines it as "A REGMULTISZ value that contains one or more UNC paths to the locations where the user's profile VHD(x) files are stored." This confirms a UNC path is the required format.