Pass the Microsoft Certified: Windows Server Hybrid Administrator Associate AZ-802 Questions and answers with ExamsMirror

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.

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.

File1: 1. File2: 3.

A File Server for general use cluster role runs in an active-passive configuration: only the single node that currently owns the role can service client connections at any given time, so File1 is limited to one active node at most, regardless of how many total nodes Cluster1 has. A Scale-Out File Server for application data role, by contrast, is purpose-built for continuous availability and allows every node in the cluster to simultaneously own and serve the same shares concurrently over SMB Transparent Failover, so File2 can use all three nodes in Cluster1 at once to serve client connections. This distinction is fundamental to selecting the correct file server role for a given workload: general-use file shares favor the simplicity of standard active-passive failover, while application workloads such as Hyper-V over SMB or SQL Server database files benefit from the scale-out role ' s concurrent, multi-node access pattern and higher aggregate throughput. Therefore, File1 tops out at 1 node while File2 can use all 3 nodes concurrently.

First action: Enable supplemental allow rules in the base policy. Second action: Create a signer rule in a supplemental policy.

A Windows Defender Application Control supplemental policy is a separate policy that expands what an existing, enforced base policy allows, without editing the base policy ' s own allow rules, but a base policy must explicitly permit supplemental policies before any supplemental policy can be linked to and take effect alongside it, which is why enabling supplemental allow rules in the base policy has to happen first; this is a one-time change to the base policy ' s own options (adding the Enabled:Allow Supplemental Policies rule option), not a modification of its allow rules, so it satisfies the requirement not to change the base policy ' s allow rules. With supplemental policies permitted, creating a signer rule inside a new supplemental policy, keyed to the vendor ' s single code-signing certificate rather than to individual file hashes, allows every binary the vendor signs with that certificate, including all of App1 ' s monthly updates, without requiring the supplemental policy (or the base policy) to be edited again each time a new signed build ships, which directly minimizes ongoing policy maintenance. The supplemental policy can then be deployed only to the six pilot servers, leaving the other 34 servers unaffected. Adding hash-based rules or path rules to the base policy would both violate the no-base-policy-allow-rule-changes requirement and would require constant hash updates every time the vendor releases a new monthly build, and putting the pilot servers into audit mode would stop enforcing the base policy ' s controls entirely rather than selectively permitting App1.

Collecting performance metrics from a Windows Server virtual machine through Azure Monitor now uses the Azure Monitor Agent, and the agent only starts sending data once it is associated with a data collection rule that specifies which performance counters to collect and which Log Analytics workspace to send them to. Simply creating the workspace does not begin collection on its own, and options such as regenerating a workspace key, installing the Azure Connected Machine agent (used for Arc-enabling non-Azure servers), or configuring Windows Event Forwarding are unrelated to enabling AMA-based performance monitoring for an Azure VM, which already has the Azure Monitor Agent available as a VM extension without needing Arc onboarding. Creating and associating a DCR with Server1, specifying the performance counter set and the destination workspace, is the next required step, and once the DCR is linked the agent begins streaming the selected counters into Workspace1 for querying with KQL and for use in workbooks or alert rules.

A point-to-site VPN client profile embeds the address-space routes that existed in Azure at the moment the profile was generated and downloaded onto Computer1. When VNet2, hosting AppSvr2, is peered with VNet1 after User1 ' s VPN client profile was already configured and downloaded, the previously issued profile has no route entry for VNet2 ' s address space baked into it, so traffic aimed at AppSvr2 never gets forwarded across the existing tunnel even though the VNet peering itself is fully established and healthy on the Azure side. Microsoft ' s documented point-to-site troubleshooting guidance for exactly this symptom is to, if needed, reset the gateway and then download and reinstall the VPN client on the affected computer so it picks up a refreshed profile that includes routes for the newly peered network, which restores connectivity to AppSvr2 without requiring any changes to the peering configuration itself, to network security groups, or to Computer1 ' s local Windows Defender Firewall settings. Creating a route table on GatewaySubnet or adding a service endpoint to VNet2 would not address a client-side profile that is simply missing the newly peered address space, since the routing problem in this case lives in the already-downloaded client configuration rather than in Azure ' s own routing tables.

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.

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.

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.

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.