AZ-802 Questions and Answers

Data Deduplication is a Windows Server file-and-storage feature that can only be enabled on NTFS-formatted data volumes; it cannot be enabled on the operating system (boot/system) volume, and it does not support ReFS or FAT/exFAT volumes at all. VM3 ' s volumes are C (NTFS, the operating system volume), D (NTFS, a data volume), E (ReFS), and F (exFAT). Volume C is excluded because Deduplication is never supported on the volume that hosts the operating system, even though its file system is NTFS. Volume E is excluded because Data Deduplication has no ReFS support in general-purpose deployments; ReFS uses its own separate storage-efficiency mechanisms such as block cloning, not the Deduplication feature. Volume F is excluded because exFAT is a lightweight file system with no support for Windows Server roles or features such as Deduplication, which depends on NTFS-specific metadata structures. That leaves volume D as the only NTFS data volume that is neither the boot volume nor formatted with an unsupported file system, so it is the only volume on which Data Deduplication can currently be enabled, making option C correct.

Statement 1: No. Statement 2: Yes. Statement 3: No.

Password-policy (Account Policy) settings inside a GPO behave differently depending on where the GPO is linked. For domain user accounts, only Account Policy settings defined in a GPO linked at the domain level (or in a fine-grained Password Settings Object) take effect; Account Policy settings in a GPO linked to an OU are ignored for domain accounts and instead apply only to the local SAM password policy of computer objects located in that OU. GPO1 (minimum length 14) is linked to OU1, where Admin1 ' s user object resides, but because it is linked to an OU rather than the domain, it has no effect on Admin1 ' s domain account password requirement. Admin1 ' s domain password is governed only by the Default Domain Policy (minimum length 10), so statement 1 is false. User1 is likewise a domain account subject only to the Default Domain Policy ' s minimum length of 10, so statement 2 is true. GPO2 (minimum length 8) is linked to the Member Servers OU, which contains Server1 as a computer object; this makes GPO2 the effective local password policy for local accounts created on Server1 (overriding the Default Domain Policy locally), not the domain policy ' s 10-character minimum. Therefore a new local account on Server1 needs only eight characters, not ten, making statement 3 false.

To AppSrv1 and AppSrv2: The Azure Site Recovery Mobility Service. To Server1: An Azure Site Recovery configuration server.

For disaster recovery of physical (non-VMware, non-Hyper-V) servers with Azure Site Recovery, the architecture requires a configuration server that communicates outbound with the Azure Site Recovery service to orchestrate replication, plus a Mobility Service agent installed on each individual protected machine to capture disk writes and forward them for replication. Since only Server1 has internet access, it is the correct place to deploy the configuration server component, because that component is the one that must reach the Azure Site Recovery service over the internet. AppSrv1 and AppSrv2 -- the physical servers actually being protected -- instead receive the Mobility Service, so their disk write traffic can be captured locally and relayed through Server1 ' s configuration server on its way to Azure. The Azure Connected Machine agent (for Azure Arc onboarding) and the Microsoft Azure Recovery Services (MARS) agent (for direct file/system-state backup to a Recovery Services vault) are unrelated to this physical-server-to-Azure replication architecture and are not part of this deployment. This division of roles is exactly how Site Recovery is designed to work when the protected servers themselves lack internet access but a designated gateway server does not.

When a data collection rule in Azure Monitor is configured to collect Windows event logs (such as the Application and System logs), the events to include are filtered using an XPath query against the event schema, for example an expression like Application!*[System[(Level=1 or Level=2)]] . KQL is used to query data once it has already landed in a Log Analytics workspace, WQL is the WMI query language used for CIM/WMI-based queries, and LINQ is a .NET query syntax unrelated to Azure Monitor data collection rules. Because the filtering happens at the collection stage rather than after ingestion, XPath is the language the DCR configuration itself expects. Using an XPath filter at collection time reduces the volume of events shipped to the workspace and lowers ingestion cost, which is why it is preferred over collecting every event and filtering later with KQL once the data has already been ingested and billed. The Windows Event Viewer ' s own Custom Views/Filter Current Log dialog can generate an equivalent XPath expression from a friendly filter, which administrators commonly copy directly into the DCR ' s data source definition rather than hand-writing the XPath syntax from scratch.

Disk space available for the virtual disk: 36 TB. Cache behavior of the SSD disks: Only write operations are cached. Cache behavior of the HDD disks: Read and write operations are cached.

When three different drive media types are present together in a Storage Spaces Direct pool, the single fastest tier -- the NVMe drives in this deployment -- is automatically dedicated entirely to caching duties and contributes no usable capacity of its own to the pool at all, while the two remaining, slower tiers both serve as capacity drives that make up the pool ' s actual usable storage. With three nodes each contributing three 1-TB SSDs and three 3-TB HDDs as capacity drives, the total capacity-tier contribution works out to nine 1-TB SSDs plus nine 3-TB HDDs, which is 9 TB from the SSDs plus 27 TB from the HDDs, for a combined 36 TB of raw pool capacity; the nine 512-GB NVMe drives are excluded entirely from that total since they are cache-only. For the caching behavior itself, Microsoft documents that in a three-media-type deployment like this one, the NVMe cache tier performs write-only caching for the SSD capacity drives, since SSDs are already fast enough that read caching adds little benefit, but performs both read and write caching for the HDD capacity drives, since HDDs benefit far more from having their read operations accelerated by the much faster NVMe cache tier.

For Hyper-V-to-Azure replication that is not managed through System Center Virtual Machine Manager, the Azure Site Recovery Provider and the accompanying Recovery Services agent are host-level components that must be installed and registered on every Hyper-V host that will participate in replication, not on the individual guest virtual machines those hosts happen to run. Since VM1 runs on Server2, the first action in this on-premises-to-Azure Site Recovery scenario is to run the AzureSiteRecoveryProvider.exe setup on Server2 itself and complete the registration wizard against the Recovery Services vault already created in Azure, supplying the vault ' s registration key downloaded from the portal. Once that registration succeeds, Server2 ' s Hyper-V site becomes visible as a protectable source within the vault in Azure, and individual virtual machines hosted on it, such as VM1, can then have replication enabled directly from the portal ' s Site Recovery blade. Running the provider setup on VM1 itself would be meaningless, since the provider is a host-level component that talks to the Hyper-V management layer rather than something installed inside a guest OS, and running the unrelated AzureBackupAgentInstaller.exe, on either VM1 or Server2, would only configure the separate MARS backup agent rather than registering the host for Site Recovery replication.

The Print Management migration wizard, built on printbrm.exe, documents that local bus printers, meaning printers connected through ports such as LPT or a locally attached USB-style port, are shown and processed during the backup step of the migration but are not successfully migrated to a working configuration on the destination server, because the physical port itself does not exist or map meaningfully on Server2. Printer1, connected through LPT1, and Printer2, connected through the similarly local, non-network Port1, both fall into this unsupported local-bus category and cannot be relied on to retain a working configuration after the move to Server2. Printer3, connected through a standard TCP/IP port pointing at a specific network address, is a fully network-addressable print queue whose port definition is meaningful on any print server, including Server2, so it migrates cleanly with its driver, queue settings, and configuration intact. Printer4, which uses the built-in FILE: port to print to a file rather than to physical hardware, is a virtual, hardware-independent port that is present identically on every Windows print server, so it too migrates without issue. Because printer drivers, queue settings, and port/configuration details only transfer meaningfully for ports that exist and behave identically on the target server, only Printer3 and Printer4 retain their current configuration after migrating to Server2.

Azure Arc-enabled servers extends Azure management (policy, monitoring, extensions, and so on) to machines that live outside Azure -- physical servers and virtual machines running on-premises or in another cloud -- by installing the Azure Connected Machine agent on each of them. Server1 (an on-premises physical server) and VM2 (an on-premises Hyper-V virtual machine) both qualify as non-Azure machines and therefore both need the Connected Machine agent installed to be onboarded to Azure Arc. VM1, however, is already a native Azure virtual machine -- it is already a first-class Azure resource, fully managed through Azure Resource Manager without any additional agent, and Azure Arc is not applicable to (and does not support) resources that are already running natively in Azure. Installing the Connected Machine agent on VM1 would be unnecessary and provides no benefit, since everything Arc would offer for an on-premises machine (centralized policy, inventory, extensions) is already natively available for an actual Azure VM. Therefore, to manage all three servers through Azure Arc with minimal wasted effort, the Connected Machine agent should be installed only on Server1 and VM2, leaving VM1 managed natively as an Azure resource.

Controlled folder access is configured from Windows Security > Virus & threat protection > Manage ransomware protection, and it works by allowing only trusted, allow-listed applications to write to designated protected folders -- which by default include common system and user document locations, and to which an administrator can add custom folders such as application data directories -- while blocking every other application, including most forms of ransomware and other unauthorized processes, from modifying that data. This directly satisfies the stated requirement of permitting only specific applications to modify data in protected folders, since an administrator can add exactly the applications that should be trusted to the allowed-apps list, and Controlled folder access then blocks every other process from writing to those folders, generating a notification and an event log entry whenever a blocked attempt occurs. No additional feature, third-party tool, or NTFS permission change is needed to achieve this outcome, and this is the mechanism Microsoft documents specifically for this exact scenario of restricting folder write access to a defined set of trusted applications. Therefore, configuring Controlled folder access meets the goal.

1. Download the Microsoft Azure Recovery Services (MARS) agent and the Vault Credentials file. 2. Run the Microsoft Azure Recovery Services Agent Setup Wizard. 3. Run the Register Server Wizard. 4. From Microsoft Azure Backup, run the Schedule Backup Wizard. 5. From Microsoft Azure Backup, run the Back Up Now Wizard.

Setting up scheduled backups to an Azure Recovery Services vault begins with downloading the MARS agent installer together with its matching Vault Credentials file, then running the Agent Setup Wizard to actually install the agent software on the server. The Register Server Wizard is run next, binding the server to the vault using the downloaded credentials, and only once registration is complete can the Schedule Backup Wizard be used to define the recurring weekly policy, satisfying the requirement to back up once per week starting the next Saturday. Because the requirement also calls for performing the initial backup as soon as possible rather than waiting for the first scheduled run to occur naturally, the administrator finishes by running the Back Up Now Wizard, which triggers an on-demand backup immediately using the just-created policy ' s retention settings. Performing these steps out of order is not possible, since each wizard depends on artifacts -- the credentials file, the installed agent, server registration, or the backup policy -- produced by the step before it.

Windows Server DHCP policies let an administrator define conditions, such as a MAC address prefix/range or vendor class, and, when a requesting client matches those conditions, assign it an address from a specific sub-range carved out within an existing scope, all without creating a second scope or disturbing how other clients in that same scope are served. Because all 50 Teams Phone devices share MAC addresses within a known, identifiable range, a policy can match on that MAC prefix and hand out addresses only from 192.168.1.100–192.168.1.200, while every other client in Scope1 continues to receive addresses from the rest of the pool as before, exactly matching the requirement to not affect other clients. Creating a second scope would require a distinct, non-overlapping subnet and would not let two scopes share the same 192.168.0.0/23-style address space as described. A DHCP filter (allow/deny list) can only permit or block specific MAC addresses from getting a lease at all; it has no ability to steer a matched device into a particular IP sub-range. Scope options configure settings such as DNS servers or default gateway for the whole scope and have no address-targeting capability. A policy is therefore the correct feature to create.

The Azure Migrate appliance only continuously discovers the specific hosts and clusters that have been explicitly registered with it as discovery sources through the appliance ' s own configuration manager; it does not automatically expand its discovery scope to cover additional Hyper-V hosts on the network just because they exist. Migrate1 is currently hosted on Server1, but for virtual machines created on Server2 and Server3 to also show up and be tracked in Azure Migrate alongside those on Server1, an administrator must explicitly add Server2 and Server3, or their respective Hyper-V hosts, as additional discovery sources on Migrate1, which causes the appliance to begin enumerating and continuously tracking their virtual machine inventory as well. Creating a GlobalName zone on the DNS server, setting the Computer Browser service ' s startup type to Automatic, and deploying a WINS server are all legacy NetBIOS name-resolution mechanisms from an earlier era of Windows networking, and none of them has any role whatsoever in how the Azure Migrate appliance discovers hosts or virtual machines. Therefore, adding a discovery source on Migrate1 is the correct action to take.

1. Create a failover cluster. 2. Enable Storage Spaces Direct. 3. Create a volume.

Deploying a Hyper-V hyper-converged cluster backed by Storage Spaces Direct follows a fixed, documented order of operations. The process begins by validating the intended nodes and creating a failover cluster from them, since Storage Spaces Direct is a capability that is enabled on top of an already-existing failover cluster rather than something that can be configured before a cluster exists. Once the cluster is formed, running Enable-ClusterStorageSpacesDirect, or the equivalent Windows Admin Center wizard, pools the local disks contributed by every node in the cluster into a single software-defined storage pool that spans the cluster. Only after that pool exists can one or more volumes actually be created from it, and those volumes become the Cluster Shared Volumes that Hyper-V virtual machines are placed on and run from. A Scale-Out File Server role and a Distributed File System namespace both belong to a converged, or disaggregated, deployment model where compute and storage live on entirely separate clusters, so neither applies to this hyper-converged design, and creating a plain file share is unnecessary since Hyper-V virtual machines are stored directly on the CSV volumes rather than accessed through a file share.

With BGP disabled, the Site-to-Site connection relies entirely on statically defined routes rather than on dynamic route propagation between the on-premises network and Azure. When Subnet2 is added within Vnet1 ' s extended address space, Azure ' s own side of the tunnel already knows about it automatically, since it is simply part of the connected virtual network, but the on-premises routers have no static route telling them that traffic destined for Subnet2 ' s address range should be sent across the VPN tunnel to Azure at all. Server1 is able to reach Server2 because that traffic stays entirely inside the Azure virtual network and never needs to cross the tunnel, but on-premises hosts have no configured path to the new subnet until the on-premises routing tables, and the local VPN device ' s configuration if applicable, are updated to include a route for Subnet2 ' s range pointed at the tunnel. Adding another Site-to-Site tunnel, a private endpoint, or a user-defined route table inside Subnet2 does nothing to address the missing route on the on-premises side, which is the actual point of failure described in the scenario.

Azure Monitor Agent collects Windows event log data based on a Data Collection Rule, which is the modern replacement for the legacy Log Analytics custom log and VM insights configuration methods and is required to route Application-log events into a Log Analytics workspace. Within the DCR ' s Windows event log data source, you scope exactly which events are collected — down to a single event ID such as 1035 — by supplying an XPath query, which lets you filter at the source instead of ingesting the entire Application log; this directly minimizes the total volume of event data stored in Azure while still making event 1035 available for analysis. A KQL or WQL query would only be usable after the full log had already been ingested, which would not reduce the stored volume, so filtering must happen at the DCR ' s XPath stage rather than after the fact. An XPath expression such as Application!*[System[(EventID=1035)]] applied to all 100 VMs ' DCR association ensures only matching events are shipped, keeping ingestion (and its associated cost) proportional to how often event 1035 actually occurs.

Private1 is deployed with its inbound endpoint in VNet1, and an Azure DNS Private Resolver inbound endpoint can resolve only private DNS zones that are virtual-network-linked to the same virtual network where the resolver itself sits; it cannot resolve a zone just because it exists in the same subscription, or because that zone happens to be linked to a different, unrelated virtual network. Per the private DNS zone table, Zone1.com is linked to VNet1, Zone2.com is linked to VNet2, and Zone3.com has no virtual network link at all. Because Private1 ' s inbound endpoint lives in VNet1, only Zone1.com, the zone actually linked to VNet1, can be resolved through it. Zone2.com cannot be resolved by Private1 because it is linked only to VNet2, a separate virtual network with no stated peering or additional resolver configuration connecting it to VNet1; and Zone3.com cannot be resolved by any resolver in any virtual network because it has no virtual network link whatsoever, meaning no virtual network can consult it through the normal Azure-provided DNS resolution path. Extending resolution to Zone2.com would require either a separate resolver deployed in VNet2, or peering combined with a forwarding ruleset and outbound endpoint, neither of which is described as being configured here. Therefore only Zone1.com can currently be resolved.

hvc.exe, ssh User2@VM2

The requirement is to use a direct SSH session to manage all the supported virtual machines on HyperV1, without relying on a network path to the guest. Hyper-V provides hvc.exe, a helper used as an SSH ProxyCommand, that opens an SSH session to a virtual machine over the VMBus (the internal Hyper-V socket/console channel) rather than over the network, which works even when the guest has no reachable IP configuration and only default management tools installed, matching the stated environment. Direct SSH management this way requires the guest to run an SSH server; of the three VMs, only VM2 runs Red Hat Enterprise Linux, which includes OpenSSH server support out of the box, so it is the only VM realistically " supported " for this direct SSH scenario as described, and the account to use is User2, the local account that exists on VM2. VM1 and VM3 both run Windows Server, so " direct SSH, " as intended by this requirement, targets the Linux guest. Connect-PSSession and Connect-WSMan are PowerShell remoting tools, not SSH, and mstsc.exe launches a graphical Remote Desktop session rather than a console-mode SSH session, so none of those alternatives fit. The correct combination is hvc.exe used as the SSH proxy, connecting as User2@VM2.

Disk1: 2. Disk2: 1.

The requirement is that data on SSPace1 must remain available at all times, meaning the storage pool ' s virtual disks must be able to tolerate physical disk failures without becoming unavailable or losing data. A three-way mirror keeps three copies of every block of data spread across different physical disks, so it remains available and readable even if any two of those disks fail simultaneously; the resiliency is fixed at tolerating two failures regardless of how many total disks (8, in Disk1 ' s case) make up the pool, as long as there are enough disks to support three-way mirroring, which eight comfortably provides. Disk2 uses parity resiliency, which stores a single parity block that can reconstruct data after one physical disk failure; unless dual parity is explicitly configured (which requires being set at virtual disk creation time and is not indicated here), a standard parity virtual disk tolerates only one physical disk failure before data becomes unavailable, regardless of the pool having twelve physical disks. Administrators sometimes assume more disks in a parity pool automatically means more fault tolerance, but the number of disks a parity space can lose is determined by the resiliency configuration (single vs. dual parity), not by the total disk count. Therefore Disk1 tolerates two disk failures and Disk2 tolerates one.

The requirement is that VMs must be configured to enable per-folder quotas. VM3 already has the File and Storage Services role installed, but native NTFS quotas only apply per volume and per user; they cannot restrict the amount of data stored inside an individual folder. File Server Resource Manager (FSRM) is the Windows Server feature that adds true folder-level quota management, letting an administrator define hard or soft quota limits (and quota templates) scoped to specific folders rather than entire volumes, which is exactly the granularity the requirement calls for. Enhanced Storage is an unrelated feature that supports certain storage devices with enhanced storage access (IEEE 1667), Windows Standards-Based Storage Management provides SMI-S/WMI-based management of storage arrays and has nothing to do with folder-level quotas, and the iSNS Server service is used for discovery of iSCSI targets and initiators on a network, also unrelated to quota enforcement. None of those three alternatives provide any per-folder capacity restriction capability, so installing FSRM is the necessary first step before per-folder quotas can be configured on VM3.

Task1 is an Azure Automation runbook, and Azure Automation supports a specific, limited set of runbook types: PowerShell (and PowerShell Workflow), Python, and Graphical runbooks (which are authored visually rather than in a scripting language). Of the listed options, PowerShell and Python are the two genuine scripting languages Azure Automation lets you author a runbook in directly, making them the two correct answers. Java and JavaScript are not supported runbook languages in Azure Automation; JavaScript is used elsewhere in Azure (for example, in Azure Functions or Logic Apps custom code), but not for Automation runbooks. Bicep is a domain-specific language for declaratively defining Azure infrastructure as code (compiling down to ARM templates) and has no role as an executable runbook language; you would not write a Task1 runbook in Bicep, since runbooks execute imperative logic rather than declare resource deployments. Therefore, Python and PowerShell are the two languages available for Task1.

1. Deploy the Azure Storage Sync service. 2. Install and register the Azure File Sync agent. 3. Create a sync group. 4. Add a server endpoint.

Data1 is a file share on VM1 that must be synced to the Azure Files share1 using Azure File Sync. The documented deployment order starts in Azure: you must first deploy a Storage Sync Service resource, because the on-premises agent registration process needs an existing Storage Sync Service to register against. With that resource in place, the next step, already fixed in the sequence, is to install the Azure File Sync agent on VM1 and register the server with the Storage Sync Service, which establishes the server ' s identity and trust relationship with Azure. After registration, you create a sync group, the container that pairs one Azure file share (the cloud endpoint) with one or more on-premises folders (server endpoints); the sync group must exist before endpoints can be attached to it. Finally, you add a server endpoint pointing at the Data1 path on VM1, which starts the actual namespace and content synchronization with share1. Installing the DFS Replication role service and installing the Storage Replica feature are unrelated technologies, DFS-R replicates between on-premises servers and Storage Replica performs block-level volume replication, neither of which is part of an Azure File Sync deployment, so both are correctly excluded from the sequence.

The Marketing OU users exist in fabrikam.com, a completely separate on-premises AD DS forest belonging to a different company than A. Datum, whose own Microsoft Entra tenant only syncs the adatum.com forest today. To give those Fabrikam users access to storage1 in A. Datum ' s tenant, their identities must also be represented in that tenant. Microsoft Entra Connect cloud sync uses lightweight, cloud-managed provisioning agents that are specifically designed to support complex or multi-forest topologies, including syncing from a partner organization ' s forest, with a much smaller on-premises footprint and configuration burden than the full Microsoft Entra Connect Sync engine, and without requiring a trust relationship between the two companies ' forests. The traditional Microsoft Entra Connect Sync engine (whether in active or staging mode) is built around a single organization ' s identity infrastructure and is a heavier deployment to extend safely across an independent partner company ' s forest; staging mode specifically only prepares a secondary sync server to take over, and does not by itself address the cross-company sync problem. AD FS provides federation and SSO but does not create Microsoft Entra ID objects for Fabrikam ' s users. Microsoft Entra Connect cloud sync is therefore the correct, purpose-built option.

1. roles 2. connections 3. connect to server dc2.adatum.com 4. quit 5. seize schema master

Because DC1 has failed and cannot gracefully transfer the schema master role, DC2 must forcibly seize it using ntdsutil.exe. From the initial ntdsutil prompt, the first command is roles, which enters the Role Management submenu where FSMO role transfers and seizures are performed. From within that submenu, the command connections opens the Connections submenu, which is required before you can bind ntdsutil to a specific target domain controller. Inside the Connections submenu, connect to server dc2.adatum.com establishes the bind to DC2, the domain controller that will actually take over the schema master role. The quit command then exits the Connections submenu and returns to the Role Management submenu while keeping the established connection to DC2 active. Finally, seize schema master, executed from the Role Management submenu while bound to DC2, forces DC2 to take ownership of the schema master role even though DC1 (the previous holder) is offline and cannot be contacted to confirm the transfer. The unused command in the list, metadata cleanup, is a separate, later step used to remove the failed DC1 ' s leftover directory metadata once its roles have been reassigned; it is not part of seizing the schema master role itself, so it is correctly left out of this five-step sequence.

Azure Automanage currently does not support virtual machines that use the Trusted launch security type; this is an explicit, documented limitation of the service, independent of which Windows Server version or edition the VM is running. Looking at the four virtual machines ' security types, Server1 (Windows Server 2022 Datacenter: Azure Edition) and Server4 (Windows Server 2019 Datacenter) are both configured with Trusted launch, which makes both of them ineligible for Automanage onboarding regardless of their OS version. Server2 (Windows Server 2022 Datacenter: Azure Edition) and Server3 (Windows Server 2022 Datacenter) both use the Standard security type and run OS versions on Automanage ' s supported list, so both qualify and Automanage should be enabled on them to satisfy the requirement that it be used on " all supported " virtual machines, which by definition excludes the ones the service cannot onboard. It is a common misreading of this scenario to assume the Azure Edition label is the deciding factor, since Server1 and Server2 share that edition; the actual determining attribute the requirement hinges on is the VM ' s security type, not its Windows Server edition. Therefore Server2 and Server3 are the correct machines on which to enable Automanage.

Enabling Microsoft Entra ID sign-in on an Azure VM running Windows is implemented through a VM extension named AADLoginForWindows, published by Microsoft.Azure.ActiveDirectory. This extension installs the components needed for the VM to accept Microsoft Entra credentials for RDP sign-in and, when combined with Azure RBAC roles such as Virtual Machine Administrator Login, controls who is authorized to sign in. VM extensions in Azure are deployed and managed with the Set-AzVMExtension cmdlet, which is how this specific extension gets installed onto Server1. Set-AzVM modifies general virtual machine properties, such as size or OS profile settings, but has no mechanism for installing extensions. Add-ADComputerServiceAccount and New-ADComputer are on-premises Active Directory cmdlets used to manage computer objects and service accounts in AD DS; they have no relevance to an Azure VM ' s sign-in method and would not apply here since Server1 ' s sign-in requirement is being satisfied by Microsoft Entra ID, not by joining a domain. Set-AzVMExtension is therefore the correct cmdlet.

Storage Migration Service is purpose-built to inventory the data, security descriptors, and both share-level and NTFS-level permissions on a source file server such as Fileserver1, transfer that data to a destination server such as Fileserver2, and then perform a cutover that reassigns the source server ' s network identity -- its computer name and IP address -- to the destination server. That cutover step is precisely what allows the existing \\Fileserver1\Data UNC path, already relied upon by the Chicago office application, to continue working unchanged after the migration, since client requests to that path transparently resolve to Fileserver2 once it has taken on Fileserver1 ' s identity. The Microsoft File Server Migration Toolkit and Windows Server Migration Tools are older, largely superseded utilities that can move some file server settings but do not provide this automated inventory-transfer-and-cutover workflow, and neither preserves the source server ' s identity on the destination the way Storage Migration Service does, meaning the UNC path would need to be manually updated or redirected. File Server Resource Manager (FSRM) is a quota, file-screening, and storage-reporting feature entirely unrelated to migrating data between servers. Therefore, Storage Migration Service is the correct tool to perform this migration while preserving the existing UNC path.

DHCP1: Export-DhcpServer, Remove-DhcpServerInDC. DHCP2: Add-DhcpServerInDC, Import-DhcpServer.

Migrating a DHCP server ' s configuration together with its existing leases and reservations by PowerShell follows an export/unauthorize-then-authorize/import pattern across the two servers. On the source server, DHCP1, Export-DhcpServer captures the existing scopes, options, leases, and reservations into a migration file, which is what allows the existing leases and reservations to actually carry over to the replacement server. Remove-DhcpServerInDC is then run on DHCP1 to unauthorize it in Active Directory, which is what prevents DHCP1 from continuing to service client requests once DHCP2 is brought online, satisfying that specific migration requirement. On the target server, DHCP2, Add-DhcpServerInDC authorizes the new server in AD DS so it is permitted to lease addresses on the network, and Import-DhcpServer then applies the configuration file exported from DHCP1, causing DHCP2 to hand out the same address ranges as DHCP1 along with the existing leases and reservations that were captured during export. Add-DhcpServerv4Scope and Remove-DhcpServerv4Scope only create or delete an individual scope ' s address range and do not export, import, or preserve any existing lease or reservation data, so neither is part of this migration sequence. Therefore, DHCP1 requires Export-DhcpServer and Remove-DhcpServerInDC, while DHCP2 requires Add-DhcpServerInDC and Import-DhcpServer.

A DHCP reservation explicitly binds a chosen IP address to a specific client ' s hardware (MAC) address, so that whenever that specific client requests or renews a DHCP lease, the DHCP server always offers it that exact same reserved address rather than any other available address from the scope ' s pool. Creating one reservation for each of the five printers -- keyed to each printer ' s own MAC address -- guarantees that each printer consistently receives the same IP address every time it requests a lease, regardless of how many other DHCP clients come and go on the network or how the general address pool is otherwise being consumed. This directly and completely satisfies the stated requirement, and it does so with the standard, purpose-built DHCP mechanism for exactly this scenario, requiring no additional configuration such as manually excluding addresses or manipulating scope-wide options that would otherwise affect every client rather than just the five printers. Therefore, creating a DHCP reservation for each printer does meet the requirement that the printers always be assigned the same IP address.

Admin1: Contoso\Domain Admins. Admin2: East\Domain Admins.

Site, subnet, and site-link objects live in the Configuration partition, and by default rights over that partition are held by Enterprise Admins and by the Domain Admins group of the forest root domain — here, contoso.com is explicitly the forest root, so Contoso\Domain Admins already has the rights Admin1 needs to create and manage sites, without requiring the broader, forest-wide Enterprise Admins membership; adding Admin1 there instead would grant far more than necessary and violate least privilege. Promoting a new domain controller into a specific domain requires either Enterprise Admins (forest-wide) or membership in the Domain Admins group of that target domain specifically. Since Admin2 only needs to deploy a domain controller into east.contoso.com, the least-privileged sufficient group is East\Domain Admins, the Domain Admins group of that child domain itself, rather than Enterprise Admins, which would additionally grant rights over contoso.com and every other domain in the forest. Contoso\Administrators and East\Administrators are local administrative groups scoped to built-in server administration and do not carry AD DS object-level management rights, so neither satisfies either requirement.

Add-DhcpServerv4Reservation is the DHCP Server PowerShell module cmdlet that creates a single IPv4 client reservation on a specified DHCP server, and it accepts pipeline input, so importing PrinterReservations.csv with Import-Csv and piping the resulting objects directly into Add-DhcpServerv4Reservation lets the cmdlet consume each row ' s ScopeId, IPAddress, and ClientId (MAC address) values to create all 20 reservations in a single pipelined command, which is the minimum-effort approach since it avoids writing any loop or per-row logic. Set-DhcpServerv4Reservation is used only to modify properties of a reservation that already exists, such as its description or client type, not to create new reservations, so piping CSV rows into it would fail outright since none of the reservations exist yet. Add-DhcpServerv4ExclusionRange creates an exclusion range that prevents the DHCP server from ever leasing addresses in that range to any client, which is the opposite of a reservation (which still requires the address to be leasable specifically to one identified client) and would actually break the ability to service these printers via DHCP. The fourth option ' s ForEach-Object with Add-DhcpServerv4Filter is scoped to the MAC address allow/deny filtering feature, an unrelated security control for permitting or blocking specific hardware addresses from obtaining any lease at all, not a mechanism for creating per-client static IP reservations from a CSV of address assignments.

1. Add a disk resource to the cluster. 2. Create a Cluster Shared Volume (CSV). 3. Put the disk in maintenance mode. 4. Enable BitLocker on the volume. 5. Update the BitLockerProtectorInfo property of the volume.

BitLocker can only be enabled on a Cluster Shared Volume disk while that disk is taken offline to cluster I/O, so the CSV must exist and be placed into maintenance mode before encryption can be applied. The supported sequence begins by adding the disk resource to the cluster and converting it into a Cluster Shared Volume, since BitLocker-on-CSV support requires the disk to already be a CSV rather than a plain cluster disk. The disk is then put into maintenance mode, which takes it offline to the other cluster nodes so it can be safely encrypted without a node attempting to access it mid-operation. With the CSV disk offline in maintenance mode, BitLocker is enabled on the volume. Finally, the volume ' s BitLockerProtectorInfo property is updated so that Failover Clustering registers the unlock protector, allowing the volume to automatically unlock on every cluster node once maintenance mode ends and the CSV is brought back online. Performing these steps out of order either fails outright -- BitLocker cannot be enabled on a CSV disk that is still online and actively used by the cluster -- or leaves the other cluster nodes unable to bring the encrypted volume back online afterward, since they would lack the registered unlock protector. Therefore, the correct order is: add the disk resource, create the CSV, put the disk in maintenance mode, enable BitLocker, and update BitLockerProtectorInfo.

Server administrators can be prevented from configuring Windows Defender Firewall rules by defining firewall policy centrally in a Group Policy Object and linking it to the servers ' organizational unit(s); domain-based GPO firewall policy overrides any local, administrator-configured Windows Defender Firewall rules on the domain-joined servers, since Group Policy-delivered firewall settings take precedence over local policy. Adaptive network hardening in Microsoft Defender for Cloud only generates recommendations to tighten network security group (NSG) rules protecting Azure resources -- it has no visibility into or control over host-based Windows Defender Firewall configuration on on-premises servers. A network security group (NSG) in Sub1 filters traffic at the Azure virtual network boundary and has no bearing on the on-premises Chicago office servers described in the scenario. An Azure Firewall policy governs the centrally managed Azure Firewall network virtual appliance, not the host-based Windows Defender Firewall running locally on each on-premises server. Because the servers in question are on-premises and domain-joined, only a Group Policy Object can centrally enforce and lock down their local Windows Defender Firewall configuration, preventing server administrators from modifying the rules directly on each machine. Therefore, configuring a GPO is the correct way to reduce this security risk.

To enable WebApp1 to handle requests for the website: Add a custom domain name. To point client connections to WebApp1: Modify a DNS record.

For an Azure App Service web app to accept and correctly serve requests addressed to https://www.fabrikam.com rather than only its default *.azurewebsites.net hostname, the custom domain www.fabrikam.com must be added and bound to WebApp1 -- this is the specific configuration step that makes the app recognize and handle that custom hostname at all. Creating a deployment slot supports staged rollout and swap scenarios and does nothing to bind a custom domain, and creating a private endpoint provides private, VNet-restricted connectivity rather than public custom-domain handling, so neither accomplishes the stated goal. Once WEB1 and WEB2 are decommissioned per the migration plan, client traffic that currently resolves to those on-premises-facing web servers must instead be directed to WebApp1; since DNS is what resolves the www.fabrikam.com name to a specific endpoint, the DNS record for that hostname must be modified (typically to a CNAME record pointing at WebApp1 ' s default hostname, together with the domain-verification TXT record Azure requires before it will accept the custom domain binding). Azure Front Door and Azure Traffic Manager are global routing and load-balancing services meant for multi-region or multi-endpoint failover scenarios and are unnecessary complexity for redirecting a single custom domain to a single web app, and adding HTTP redirect rules on WEB1/WEB2 is not a viable option once those servers have been decommissioned. Therefore, adding a custom domain name to WebApp1 and then modifying the DNS record are the two required actions.

On Cluster1: Import the Azure Migrate appliance. In Azure: Create an Azure Migrate project.

APP3 and APP4 run as virtual machines on the on-premises Cluster1 Hyper-V failover cluster, so migrating them to Azure uses the Azure Migrate: Server Migration workflow for Hyper-V. That workflow requires an Azure Migrate project to first be created in Azure, since the project is the container that organizes the migration effort, tracks discovered and assessed machines, and holds the configuration for the subsequent discovery and replication work. On the Cluster1 side, the Azure Migrate appliance -- a purpose-built VM or OVA image supplied by Azure Migrate specifically for Hyper-V environments -- must be imported (deployed) onto the Hyper-V host or cluster, where it discovers the VMs running there and orchestrates their replication into Azure. Configuring an Azure Network Adapter, creating a Point-to-Site VPN connection to Vnet1, installing the Azure File Sync agent, and installing the Windows Server Migration Tools are all unrelated actions that do not perform Hyper-V VM discovery or replication for an Azure Migrate project. Similarly, creating a premium block blob storage account, a private endpoint, or a VPN gateway in Azure are not the resource that Azure Migrate itself requires to begin a migration project -- an Azure Migrate project is. Therefore, importing the Azure Migrate appliance onto Cluster1 and creating an Azure Migrate project in Azure are the two required preparatory actions.

Enforce the security policy: Microsoft Defender Application Control. Manage the policy settings: Group Policy Objects (GPOs).

Windows Defender Application Control (WDAC) is the platform feature that enforces which applications are authorized to install or run on a Windows Server, directly meeting the stated requirement that only authorized applications can be installed or run on the servers in the forest. Microsoft Defender Application Guard isolates untrusted browsing sessions in a container and Microsoft Defender Credential Guard protects credential material from theft -- neither controls which applications are permitted to execute. Microsoft Defender for Endpoint is an endpoint detection-and-response platform that detects and responds to threats rather than enforcing a whitelist of permitted applications. Because the servers described are on-premises, domain-joined machines rather than Intune-managed, Microsoft Entra-joined devices, the WDAC policy settings here must be managed through Group Policy Objects distributed via AD DS, not through Intune. Configuration profiles in Microsoft Intune and compliance policies in Microsoft Intune are both cloud-management mechanisms that apply only to devices enrolled in and managed by Intune, which these on-premises, domain-joined servers are not. Therefore, WDAC is the enforcing service and Group Policy Objects are the correct management mechanism for these on-premises servers.

Microsoft Defender for Identity is the Microsoft Sentinel data connector purpose-built to monitor on-premises Active Directory domain controllers and surface exactly the insecure-protocol activity described in the requirement, including authentication attempts and sign-ins that rely on legacy or unsigned protocols such as NTLMv1, SMBv1, and unsigned LDAP binds. It does this by analyzing domain controller network traffic and Windows Events directly on the DCs, which is exactly where this insecure-protocol usage originates. The Threat Intelligence - TAXII connector ingests external threat-intelligence indicator feeds (IP addresses, file hashes, domains) from TAXII-compliant sources and has nothing to do with monitoring authentication protocol usage on domain controllers. The Azure Active Directory (Microsoft Entra ID) connector reports on cloud sign-in and audit log events for the Entra tenant, not on legacy protocol usage against on-premises AD DS domain controllers. Microsoft Defender for Cloud focuses on cloud resource security posture management and workload protection rather than detecting legacy authentication protocol usage against on-premises domain controllers. Therefore, connecting Microsoft Defender for Identity to Microsoft Sentinel is the correct connector to identify connections to the domain controllers that use insecure protocols.

A Windows Server failover cluster requires a distinct IP address for each individual cluster node ' s network adapter, plus one additional IP address for the cluster ' s own network name resource -- the cluster access point that clients and management tools use to address the cluster as a single logical entity rather than any one specific node. Cluster3 will contain two physical nodes, Node1 and Node2, so at minimum one IP address is required for Node1 ' s network adapter and one for Node2 ' s network adapter. Beyond those two node-level addresses, the cluster core resource itself (the cluster name object and its associated IP address resource) requires one more address so that the cluster can be addressed and managed as a whole and so that any highly available roles hosted on the cluster (such as the file share role planned for Cluster3) can obtain the network identity they need to fail over between nodes. Adding these together -- one for Node1, one for Node2, and one for the cluster ' s own network name -- yields a minimum of three IP addresses required for Cluster3 ' s node and cluster roles. Fewer than three would leave either a node or the cluster itself without a usable network identity, and while additional IP addresses may be consumed by highly available roles later added to the cluster, three is the baseline minimum for the node and cluster roles themselves.

On the domain controllers: Install the Azure Monitor agent. In Azure: Create an Azure Log Analytics workspace.

Centrally managing performance alerts in Azure for on-premises domain controllers is done by connecting those servers to Azure Monitor: the Azure Monitor agent is installed on each domain controller (onboarded to Azure Arc for non-Azure servers, or directly if they are Azure VMs) to collect performance counters and event data, and that telemetry is sent to an Azure Log Analytics workspace, which is the resource that stores the collected data and against which performance-based alert rules are then defined and centrally managed. Creating a Data Collector Set in Performance Monitor and modifying the Performance Monitor Users group are both local, per-server administrative actions that never send any data to Azure and cannot support central, Azure-based alerting. An Azure SQL database, a Storage Sync Service, and an Azure Storage account are all Azure resources, but none of them is the telemetry store that Azure Monitor ' s alerting pipeline is built on -- only a Log Analytics workspace serves that role. Therefore, installing the Azure Monitor agent on the domain controllers and creating an Azure Log Analytics workspace are the two required actions.

1. Create an Azure Recovery Services vault. 2. Create a Hyper-V site. 3. Install and register Azure Site Recovery Providers. 4. Create and associate replication policies.

Setting up Azure Site Recovery for a Hyper-V cluster that is not managed by Virtual Machine Manager follows a fixed infrastructure-preparation order. An Azure Recovery Services vault must exist first, since it is the container that every later step registers against. A Hyper-V site is then created in that vault to represent the on-premises Hyper-V environment, because a Hyper-V host or cluster must belong to a site before its hosts can be registered against Azure Site Recovery. The Azure Site Recovery Provider is then installed on the Hyper-V hosts (Cluster2 ' s nodes) and registered to that site/vault, which is what actually connects the cluster nodes to Azure Site Recovery. Only once the hosts are registered can a replication policy be created and associated with the Hyper-V site, since a policy has nothing to attach to until the site and its registered hosts already exist. Installing Azure Connected Machine agents is unrelated to Hyper-V VM replication -- that agent is used for onboarding servers to Azure Arc -- and is not part of this workflow. Therefore, the correct order is: create the vault, create the Hyper-V site, install and register the Providers, and create and associate the replication policy.

Using Hyper-V Replica within a clustered Hyper-V environment such as Cluster3 requires deploying the Hyper-V Replica Broker, which itself runs as a clustered role on the failover cluster; without the Broker, replication cannot follow a protected virtual machine if it live-migrates between Cluster3 ' s nodes, since there would be no single, cluster-aware endpoint tracking which node currently owns each VM ' s replication state. Adding a failover cluster role is exactly how the Hyper-V Replica Broker is deployed onto Cluster3, satisfying the requirement to use Hyper-V Replica to protect Cluster3 ' s virtual machines. Enabling integration services on the virtual machines addresses guest-OS-to-host integration (time synchronization, heartbeat, and similar) rather than providing any replication capability. Adding a generic Windows Server server role does not, by itself, install or configure the Hyper-V Replica Broker -- the Broker must specifically be added as a clustered role through Failover Cluster Manager. Configuring a fault domain for the cluster is not a real Windows Server failover clustering concept and does not provide Hyper-V Replica capability. Therefore, adding a failover cluster role (the Hyper-V Replica Broker) is the correct solution for Cluster3.

Backing up a standalone Windows Server ' s files, folders, and system state directly to an Azure Recovery Services vault -- exactly what the requirement calls for on Server4 -- is done using the Microsoft Azure Recovery Services (MARS) agent, so installing that agent on Server4 is the necessary first step. Microsoft Azure Backup Server (MABS) is used for application-aware and Hyper-V virtual machine backups rather than direct file/system-state backup of a single standalone server, and while it can also protect servers, it is not the lightweight, direct-to-vault mechanism appropriate for a single standalone server like Server4 and represents unnecessary additional infrastructure. Native Windows Server Backup does not target an Azure Recovery Services vault on its own without additional agent installation, and Storage Replica provides block-level volume replication between servers rather than the point-in-time backup and long-term retention the requirement calls for. Therefore, installing the MARS agent on Server4 is the correct first step to meet this technical requirement.

Promoting a new domain controller that runs a newer operating system version than any existing domain controller in the forest -- here, DC4 running Windows Server 2022 into a forest whose functional level is still Windows Server 2012 R2 -- requires the Active Directory schema to first be extended to support that OS version ' s schema additions (the adprep /forestprep and /domainprep operations, which modern promotion tools such as Install-ADDSDomainController run automatically when needed). Extending the schema requires connectivity to the domain controller holding the Schema Master FSMO role, since schema changes can only be made by contacting that specific role holder; if the Schema Master is offline, the schema extension step fails and the promotion cannot proceed. According to the domain controllers table, DC1 holds both the RID master and the schema master roles. DC2 holds the PDC emulator and infrastructure master roles, and DC3 holds the domain naming master role -- neither of those role sets is relevant to a schema extension. Therefore, DC1, as the Schema Master, must be online for DC4 ' s promotion (and its associated schema extension) to succeed.

Server1 can communicate with: Server2, Server3, and Server4. Server3 can communicate with: Server1 and Server2 only.

Server4 has no isolation connection security rule configured at all, so it never attempts or performs IPsec authentication with any peer. Server1 ' s rule only requests IPsec in both directions rather than requiring it, meaning that if IPsec negotiation does not occur -- as with Server4, which has no IPsec capability configured -- the connection still falls back to succeed in the clear; Server1 can therefore reach Server2, Server3, and Server4. Server3 ' s rule requires IPsec in both directions, meaning a connection only succeeds if IPsec authentication is actually negotiated. Server3 can successfully negotiate IPsec with Server1 (whose " request " setting means it will still respond to and complete an IPsec negotiation when the peer requires it) and with Server2 (which requires inbound and requests outbound IPsec, and likewise supports negotiation), so both of those connections succeed. Server3 cannot successfully negotiate IPsec with Server4, since Server4 has no IPsec capability configured at all, and Server3 ' s " require " setting blocks any connection that cannot be authenticated via IPsec. Therefore, Server1 can communicate with Server2, Server3, and Server4, while Server3 can communicate with only Server1 and Server2.

Signing in over Remote Desktop requires a user to hold the " Allow log on through Remote Desktop Services " right and the " Access this computer from the network " right, and to be excluded from any matching Deny counterpart, since an explicit Deny always overrides an Allow granted through any other group membership. User1 is a member of Group2 (granted the Remote Desktop Services logon right) but is also a member of Group4, which is explicitly denied " Access this computer from the network " on Server4 -- that network-access denial blocks the RDP connection outright regardless of the Everyone-based network-access Allow or the RDS logon right, so User1 is denied. User2 belongs only to Group2: Group2 grants the RDS logon right, User2 is covered by the Everyone-based network-access Allow, and User2 is not a member of either Group3 or Group4, so neither Deny applies and User2 can sign in successfully. User3 is a member of Group3, which is explicitly denied " Allow log on through Remote Desktop Services " on Server4 -- that denial blocks the RDP logon right itself, so User3 cannot sign in regardless of network-access rights (and User3 is also in Group4, which independently denies network access as well). Therefore, only User2 can successfully sign in to Server4 using Remote Desktop.

DC3 is a domain controller for the existing corp.fabrikam.com AD DS forest, deployed into Vnet1 in Azure. Domain controllers rely on AD-integrated DNS for locating other domain controllers, SRV records, and replication, so DC3 needs to host that zone itself, which requires installing the DNS Server role on DC3 and letting it host an AD-integrated copy of the corp.fabrikam.com zone. Azure ' s default virtual-network-provided DNS resolver has no awareness of AD DS records and cannot host or serve an AD-integrated zone, so every resource in Vnet1 that needs to locate the domain (including Azure VMs and DC3 ' s own replication partners) must be pointed at real DNS servers instead. That is accomplished by configuring the custom DNS Servers setting on Vnet1 to reference DC3 (and, once available, DC1 and DC2), which makes all Azure VMs in the virtual network resolve names through the AD-integrated DNS infrastructure rather than the platform resolver. An Azure DNS zone (public) or an Azure private DNS zone are separate, unrelated Azure-native DNS services that cannot host an AD-integrated zone and are not used for this scenario. Installing the DNS Server role on DC3 and pointing Vnet1 at it together satisfy the requirement.

DC3 is explicitly described as a domain controller named dc3.corp.fabrikam.com that will exist inside Vnet1, meaning it must be a genuine, writable domain controller for Fabrikam ' s existing corp.fabrikam.com AD DS forest, replicating with DC1 and DC2. The only way to run an actual domain controller for an existing on-premises forest inside Azure is to deploy a regular Azure virtual machine, place it on Vnet1, install the AD DS role on it, and promote it as an additional domain controller for corp.fabrikam.com. Microsoft Entra Domain Services is a fundamentally different, fully managed service: it creates its own separate, standalone managed domain and does not add a domain controller to, or replicate directly with, an existing on-premises forest, so it cannot be used to deploy " DC3 " as described. Microsoft Entra Application Proxy publishes on-premises web applications to external users and has nothing to do with domain controller placement. A Microsoft Entra administrative unit is a container used to scope administrative permissions over Microsoft Entra objects and is unrelated to deploying infrastructure. Therefore, an Azure virtual machine, promoted to a domain controller, is the correct implementation for DC3.

Sync groups: 3. Storage Sync Services: 1.

In Azure File Sync, a sync group defines a single sync topology and can contain exactly one cloud endpoint (one Azure file share) but can contain multiple server endpoints (on-premises server locations) that all sync to that same file share. Fabrikam needs newyorkfiles to sync only to FS1, seattlefiles to sync only to FS2, and companyfiles to sync to both FS1 and FS2. Because each Azure file share can only belong to one sync group, newyorkfiles requires its own sync group with a single server endpoint on FS1, seattlefiles requires its own sync group with a single server endpoint on FS2, and companyfiles requires a third sync group whose one cloud endpoint (companyfiles) has two server endpoints, one on FS1 and one on FS2, which Azure File Sync fully supports within a single sync group. That gives a minimum of three sync groups. A Storage Sync Service is the top-level Azure resource that contains and manages sync groups, and there is no requirement here that forces the shares into separate Storage Sync Service instances (such as differing regions or subscriptions); a single Storage Sync Service can hold all three sync groups. Therefore only one Storage Sync Service is required.

DHCP1 (New York, Scope1) and DHCP2 (Seattle, Scope2) currently serve only their own local office. To make DHCP highly available across both offices, the modern, supported approach is DHCP Failover, configured per scope (option E), which replicates lease information between DHCP1 and DHCP2 in either load-balance or hot-standby mode so that either server can service either scope ' s clients if its partner becomes unavailable. However, DHCP Failover alone only helps if a client ' s DHCP broadcast can actually reach the surviving partner server across the WAN; broadcasts do not cross routed office boundaries on their own. Configuring a DHCP relay agent on the router (or another relay-capable device) in each office (option B) forwards DHCPDISCOVER broadcasts from local clients to the remote partner server whenever the local DHCP server is down, allowing failover to actually take effect for clients in either office. The legacy split-scope technique of manually carving off a percentage of the other scope ' s addresses (options A and C) is the older, pre-failover workaround and is unnecessary once DHCP Failover is used; there is also no DHCP cluster role delivered through Windows Failover Clustering (option D), since DHCP achieves high availability through Failover mode, not a clustered role.

GPO4 is already linked to the VirtualDesktops OU, which contains the Azure Virtual Desktop session host computer accounts, so it is correctly targeted at the right computers. The requirement is that the idle lockout behavior configured in GPO4 must apply to whichever user is signed in to a session host, and that the user must still be able to adjust the lockout time manually from their own client, which means the relevant setting is a per-user configuration item rather than a strict, non-negotiable computer policy. By default, user-configuration settings inside a GPO apply based on the OU containing the user account, not the computer the user signs in to; Fabrikam ' s users are located in the AllUsers OU, which is governed by GPO1, not GPO4. Group Policy Loopback Processing, enabled in GPO4 and set to Merge (to allow the client-side adjustment) or Replace, forces the user-configuration portion of GPO4 to apply to any user who logs on to a computer in the VirtualDesktops OU, regardless of where that user ' s own account resides. Security filtering and the Enforced property both affect who a GPO applies to or its precedence in conflicts, but neither one makes a GPO ' s user-side settings follow the computer instead of the user, so loopback processing in GPO4 is correct.

Fabrikam ' s plan is to use Azure Policy to enforce configuration management policies across both its Azure and on-premises servers. Azure Policy ' s guest configuration capability, which evaluates and can remediate in-guest settings, only works against a server that is registered as an Azure resource. For an on-premises or non-Azure server, that registration is achieved by deploying the Azure Connected Machine agent, which onboards the machine as an Azure Arc-enabled server, gives it an Azure resource ID, and makes it a valid target for Azure Policy assignments, including guest configuration policies, in exactly the same way an Azure VM would be. Hybrid joining servers to Microsoft Entra ID affects identity and device management (such as Conditional Access) but does not make a server a valid Azure Policy target. A hybrid runbook worker lets Azure Automation runbooks execute on-premises but is unrelated to Azure Policy enforcement. The Azure Monitor agent collects telemetry into Log Analytics and Azure Monitor but does not register the server as an Arc resource or enable policy assignment on its own; it is typically deployed after Arc onboarding, not instead of it. Deploying the Azure Connected Machine agent is therefore the correct first step.

On a Virtual WAN hub: An ExpressRoute gateway. In the offices: An ExpressRoute circuit connection.

Fabrikam ' s plan is to replace the existing WAN links between the New York and Seattle offices with Azure Virtual WAN and ExpressRoute, connecting both offices to Vnet1 through the Virtual WAN hub. Azure Virtual WAN uses its own hub-native ExpressRoute gateway object (distinct from the standalone virtual network gateway used when ExpressRoute is connected directly to a single VNet); this ExpressRoute gateway is deployed inside the Virtual WAN hub and is required before any ExpressRoute circuit can terminate into that hub. A standard virtual network gateway is used for VNet-to-VNet or VPN scenarios, not for Virtual WAN hub ExpressRoute termination, and an ExpressRoute circuit connection itself is the logical link resource, not something you deploy on the hub. At each office, connectivity into Microsoft ' s network is established through an ExpressRoute circuit connection provisioned with a connectivity provider, which then links, via Microsoft ' s backbone, into the ExpressRoute gateway in the Virtual WAN hub. A Site-to-Site VPN, an Azure application gateway (a web traffic load balancer), and an on-premises data gateway (used for Power Platform/Logic Apps connectors) are all unrelated to this ExpressRoute-based design.

1. Create the KDS root key in AD DS. 2. Create a group managed service account (gMSA) in Active Directory. 3. Configure the IIS application pool (on WEB1 and WEB2) to run as the gMSA via a specified user account.

The requirement is that every instance of Webapp1 (running on both WEB1 and WEB2) uses the same identity, and that identity ' s password rotates automatically every 30 days, without any administrator manually resetting it. A standalone managed service account (sMSA) is tied to a single computer and cannot be shared across WEB1 and WEB2, so it does not meet the requirement. A group managed service account (gMSA) is designed exactly for this scenario: one AD-managed identity that multiple servers can use simultaneously, with the Key Distribution Service automatically rotating its password (by default every 30 days) without needing manual intervention or downtime. Before any gMSA can be created in the forest, a one-time prerequisite must exist: the KDS root key, which the Key Distribution Service uses to generate and later recompute the gMSA ' s password material. So the correct order is to first create the KDS root key, then create the gMSA object in Active Directory, and finally configure the IIS application pool on each web server to run as that gMSA using the " specified user account " identity option (entered as domain\gMSA$ with no password required, since the password is centrally managed). Creating a system- or user-assigned managed identity in Microsoft Entra ID does not apply here, since Webapp1 runs on IIS on domain-joined VMs, not as an Azure PaaS resource.

The requirement states that server administrators must request approval before establishing a Remote Desktop connection to an Azure virtual machine, and that once approved, the connection must be established within a defined two-hour window. This request-approve-then-time-limited-access pattern for a specific management port on an Azure VM is precisely what just-in-time (JIT) VM access, a Microsoft Defender for Cloud capability, provides: it keeps the RDP/SSH management ports closed by default in the network security group, requires an explicit access request, and, once approved, opens the port only for a specified time window and only from the requester ' s source IP. Microsoft Entra Privileged Identity Management provides time-bound, approval-based elevation for Microsoft Entra and Azure RBAC roles, not for opening network ports to a VM, so it does not by itself control Remote Desktop network access. The Remote Desktop extension for Azure Cloud Services is a legacy classic-deployment feature unrelated to this scenario. Azure Bastion provides browser-based RDP/SSH without exposing public IPs but does not implement an approval workflow with a bounded connection window. JIT VM access is therefore the correct, purpose-built solution.

Set-VMProcessor -VMName VM1 -ExposeVirtualizationExtensions $true

The requirement is to run virtual machines on VM1 itself, which means enabling nested virtualization so that VM1 (a guest VM hosted on Server2) can install Hyper-V and host its own virtual machines. Nested virtualization on Hyper-V requires the parent VM ' s virtual processor to expose the host ' s hardware virtualization extensions (Intel VT-x or AMD-V) through to the guest. This is done with the Set-VMProcessor cmdlet using the -ExposeVirtualizationExtensions parameter set to $true, run against VM1 from the Hyper-V host (Server2): Set-VMProcessor -VMName VM1 -ExposeVirtualizationExtensions $true. VM1 must be turned off before this setting can be applied, and after it is applied, VM1 needs the Hyper-V role installed inside the guest before it can run its own VMs. Set-VM, Set-VMBios, Set-VMHost, and Set-VMFirmware do not control virtualization extension exposure: Set-VM manages general VM configuration such as memory and name, Set-VMHost configures host-wide settings, and Set-VMFirmware/Set-VMBios control boot and firmware settings for generation 2 and generation 1 VMs respectively. Only Set-VMProcessor with -ExposeVirtualizationExtensions satisfies the stated requirement, making it the correct first step.

Server1: Set-Item. Server4: Enable-PSRemoting.

The requirement is to manage Server4 from Server1 by using PowerShell remoting. Server4 is a workgroup computer, not a member of either AD DS domain, so the WinRM authentication that PowerShell remoting relies on cannot use Kerberos between Server1 and Server4; it must fall back to NTLM, which WinRM only permits toward hosts explicitly listed in the client ' s TrustedHosts list. On Server1, the correct action is therefore Set-Item, used as Set-Item WSMan:\localhost\Client\TrustedHosts -Value " Server4 " (with -Concatenate as needed), which adds Server4 to Server1 ' s trusted hosts so an NTLM-based remoting session is permitted. On Server4, the target must first be configured to accept remote commands at all, which is done with Enable-PSRemoting; this cmdlet starts and configures the WinRM service, creates a listener, and enables the Windows Remote Management firewall rule for the current network profile, matching Server4 ' s private firewall profile. Enable-ServerManagerStandardUserRemoting only grants a non-administrator limited Server Manager access and does not establish remoting, and Start-Service alone does not create or configure a WinRM listener or firewall exception. Configuring Set-Item on Server1 and Enable-PSRemoting on Server4 together satisfies the requirement.

The stated problem is that when an administrator connects to VM2 ' s console through Virtual Machine Connection and disconnects without signing out, a second administrator who opens the console can silently inherit that still-signed-in session without ever supplying credentials. By default, VMConnect attaches directly to the raw console of the guest, which behaves like walking up to a physical, unlocked machine. Enhanced Session Mode changes this behavior by routing the VMConnect session over the Remote Desktop Protocol into the guest, which means every connection is treated as a new interactive Remote Desktop logon and therefore always prompts for credentials, eliminating the ability to passively inherit someone else ' s open session. Enabling Enhanced Session Mode requires both host-side and guest-side support (the guest operating system must support RDP and have the setting enabled) but is the direct, purpose-built fix for this exact console-sharing problem. The Guest Services integration component only enables basic file-copy functionality between host and guest and has no effect on console/session behavior. Credential Guard protects locally stored credentials from theft using virtualization-based security, and shielded VMs protect a VM ' s disk, state, and console from a compromised or malicious fabric administrator; neither addresses console session takeover between two legitimate administrators. Enhanced Session Mode is therefore the correct solution.