Microsoft AZ-802 Practice Exam Questions & Answers

Direct access (DAX) mode for persistent memory volumes in Storage Spaces Direct is supported only in combination with the NTFS file system; a persistent memory volume formatted with ReFS can only be used in block access mode, not DAX mode, regardless of when that volume was created. Volume1 and Volume3 are formatted with NTFS, while Volume2 and Volume4 are formatted with ReFS, so DAX is available on Volume1 and Volume3 and is not available on Volume2 or Volume4. Because file system type -- rather than whether a volume is part of the existing deployment or a newly planned addition -- is the determining factor for DAX eligibility, both the currently deployed NTFS volume (Volume1) and the newly planned NTFS volume (Volume3) qualify for DAX. This NTFS-only restriction for DAX, contrasted with block access mode's support for both NTFS and ReFS, is a core planning consideration whenever persistent memory is deployed with Storage Spaces Direct. Therefore, Volume1 and Volume3 only is the correct answer.

Cluster-Aware Updating supports the -PreUpdateScript and -PostUpdateScript parameters on Invoke-CauRun, and these settings, along with every other CAU configuration option such as the maximum retries per node and the update categories to apply, can be saved together into a single reusable updating run profile, which is stored as an XML file. Once a run profile has been created and is referenced using the -CauPluginArguments or -RunProfile parameter on a subsequent CAU run, or configured as the default profile for self-updating mode, every future CAU run automatically applies the same pre- and post-update scripts without the administrator needing to re-specify them each time, which is precisely what minimizing administrative effort for this recurring maintenance task looks like. Scheduled tasks have no built-in awareness of cluster node draining, pausing, or update orchestration and would require substantial custom scripting to coordinate safely, WSUS only manages which updates are approved for distribution and has no scripting hook into CAU's node lifecycle at all, and Azure Functions is a cloud compute service entirely unrelated to on-premises CAU orchestration. Therefore, run profiles are the correct answer.

The General tab for App1 shows that its Preferred Owners list has no nodes selected at all, and the Failover tab shows Allow failback set to Immediately, but the Allow failback setting only has any practical effect once a most-preferred owner node has actually been defined in the Preferred Owners list; with that list empty, the cluster has no designated target node to fail the role back to, regardless of how the failback timing is configured. After Server2's unexpected shutdown, App1 is presumably now running on Server1, since Server1 is the surviving node in this two-node scenario. Pausing the Server1 node, which is the node currently running App1, and then simply starting Server1 again does nothing to move App1 back onto Server2 once Server2 is restarted, because pausing a node only prevents new roles from being placed onto it while it is paused; it does not trigger any existing role to move away from that node, nor does it configure any preferred-owner relationship that would drive App1 back to Server2. To actually meet the stated goal, Server2 would need to be explicitly configured as the preferred owner for App1 so that automatic failback has a defined target once Server2 comes back online, and that configuration change is not what this solution performs.

Windows Server lets you change a server's edition in place using DISM with the /Set-Edition (or /Online /Set-Edition) option and a valid edition key, which upgrades Standard to Datacenter without requiring a full reinstall and needs only a single restart to complete, minimizing downtime for the Hyper-V host and preserving its running virtual machines and configuration. Setup.exe would perform a full in-place OS upgrade rather than an edition change, which is unnecessary and far more disruptive when the OS version itself is not changing, slmgr.vbs manages license activation rather than edition conversion, and convert.exe is unrelated (it converts file systems). DISM is Microsoft's documented tool for this specific Standard-to-Datacenter edition upgrade scenario, and running DISM /Online /Set-Edition:ServerDatacenter /ProductKey: /AcceptEula is the documented command sequence for completing it with a single reboot. After the reboot, the server retains its existing roles, features, and settings, including the Hyper-V role and any virtual machines already configured, since an edition change preserves the installation rather than replacing it.

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.

App1's requirement to update objects in AD DS as part of its Kerberos-authenticated operation rules out any deployment built solely on read-only domain controllers (RODCs), because an RODC holds a read-only copy of the AD DS database and cannot accept or process write operations, such as the object updates App1 performs or password changes tied to Kerberos ticket processing; only a writable domain controller can service those requests, immediately eliminating both RODC-based options regardless of how they are made redundant. Between the two writable-DC options, deploying the two writable domain controller virtual machines across availability zones provides genuine redundancy within the same Azure region and VNet, keeping both DCs on the same low-latency virtual network VM1 already reaches through the Azure Firewall, so a zone failure still leaves a writable, reachable DC online for App1; placing the two writable DCs in physically distinct Azure regions instead would require extending VNet1's connectivity (and the Azure Firewall's filtering) across regions and introduces materially higher replication latency between the two DCs, which the scenario's single-VNet, single-firewall design does not call for or support. Deploying two writable domain controller virtual machines across availability zones therefore both satisfies VM1's write requirement and provides the requested redundancy with the least architectural disruption.