Azure Virtual Desktop (WVD) Simulation: AZ-140-Style Question, Answer and Explanation

1. Portal → Azure Virtual Desktop → Host pools → + Create. On Basics: subscription, rg-contoso-avd, name hp-avd-01, region East US 2, validation environment: No.
2. Host pool type: Pooled; preferred app group type: Desktop; load balancing: Breadth-first; max session limit: 10.
3. On Virtual machines, choose “Yes” to add VMs. Image: Windows 11 Enterprise multi-session, version 23H2, Gen 2.
4. Size: Standard_D2s_v5; number of VMs: 2; name prefix: hp-avd-01; availability zone: 1.
5. Networking: vnet-avd → snet-sessionhosts; join type: Active Directory (contoso.com) with a domain-join account; skip the (optional) Entra ID/Intune join. Finish the wizard — the template creates the VMs, joins the domain and joins them to the host pool automatically.

1. Open hp-avd-01 → Application groups → + Create. Name dag-avd-01, type Desktop (only a RemoteApp app group needs applications added).
2. Inside dag-avd-01 → Assignments → + Add → add the AVD-Users group. Without this assignment users see nothing in their feed.

1. Azure Virtual Desktop → Workspaces → + Create → name ws-avd-01, rg-contoso-avd, region East US 2.
2. In Application groups, select dag-avd-01 (this “registers” the app group — the step people forget) and confirm the Desktop plan is ticked, then create.

1. Open stcontosoprofiles → File shares → + File share → name profiles, quota (e.g. 50 GiB) → create.
2. Azure RBAC layer: on the share (Share → Access control (IAM) → + Add role assignment) grant AVD-Users the built-in role Storage File Data SMB Share Contributor. This role controls who can reach the SMB share at all.
3. NTFS layer: if the share is new, grant the same group Modify on the share root (run once with storage credentials or set it via the AAD Kerberos setup / icacls on the first mount). Both layers must allow access or FSLogix fails.
4. On the AD side, on any domain-joined session host (or via GPO on contoso.com): Computer Configuration → Administrative Templates → System → User Profiles.
5. Enable FSLogix Profile Container → Enabled, and set Profile path to \\stcontosoprofiles.file.core.windows.net\profiles (FSLogix appends the %username% folder automatically from v2, or use \profiles\%username%). Apply the GPO, run gpupdate /force on the session hosts.

1. Browse to the web client, sign in as a pilot user: the feed shows Contoso Desktop.
2. Check profiles in the storage account — a folder per user (e.g. azureuser1) with Profile_*.vhdx proves FSLogix is active.
3. On the session host, %ProgramData%\FSLogix\Logs\Profile\ shows a healthy connection log.

A pooled pool lets many users share few multi-session VMs (that is the whole value of the multi-session SKU); personal pools give users their own single-session VM. With Breadth-first load balancing the broker places each new session on the least-loaded host, and FSLogix keeps the user experience identical on every host. A Desktop app group publishes the full desktop and needs no application list; only RemoteApp groups require you to add apps. Even a perfect app group shows users nothing until it is both assigned to users and registered to a workspace — the classic “why is my feed empty?” failure.

Windows 11 Enterprise multi-session is published only in Azure Marketplace (Gen 2, re-signed images), which is why the task specifies it. It is the only Windows client SKU that permits concurrent signed-in sessions on one VM. Access rights come from Microsoft 365 E3/E5 (per user) or Windows VDA per-user licensing — the lab gives you M365 E5, so no extra purchase is needed.

This is the most-tested trap in AZ-140: Azure RBAC (Storage File Data SMB Share Contributor/Reader) governs access to the SMB share itself, while NTFS ACLs govern what a user can do inside it. Granting only one produces “profile failed to load” or empty profile containers. Also remember Azure Files SMB for Entra-joined/domain-joined clients needs Kerberos enabled on the storage account (or the ADDS/Kerberos key configuration) for seamless sign-in — a common second failure point. FSLogix containers, unlike roaming profiles, mount only during sign-in and work with both pooled and personal pools, and they are the reason apps like Outlook don’t rebuild a profile on every host.

Session hosts must sit in the same Azure region as the host pool and in a subnet with a route to the domain controller (or be Entra-joined). Users never RDP to the session host IP: the Azure Virtual Desktop client connects outbound over 443 to the Azure Virtual Desktop service (feed, gateway). So no inbound 3389 rule is needed on the NSG — a nice checking point when a lab asks “is the session host reachable?”. Use a validation environment for a pilot; roll out updates to it before production hosts.

Simulators often grade the state of the environment. Before you finish: the app group is assigned to users, the workspace shows the published resources, the host pool list shows two healthy VMs (the Adding/Updating state must clear), and the FSLogix share contains a Profile_*.vhdx. Health checks in the Azure Virtual Desktop overview page and Get-AzWvdSessionHost in Azure Cloud Shell confirm readiness.

1. Creating the app group but never registering it to a workspace — the feed stays empty. 2. Choosing Windows 11 Enterprise single-session (or a Windows Server image) for a pooled pool — no multi-user support. 3. Assigning only Azure RBAC or only NTFS rights for FSLogix, never both. 4. Setting the workload profile share at container root but forgetting the %username% path or GPO scope so only the admin machine applies it. 5. Deploying session hosts in a different region than the host pool. 6. Forgetting M365/Windows VDA licensing is a prerequisite, not an exam task — mention it in the explanation.