AZ-802 Exam Dumps - Microsoft Certified: Windows Server Hybrid Administrator Associate Questions and Answers

Register-PSSessionConfiguration -Path .\HyperVJeaConfig.pssc -Name ' HyperVJeaHelpDesk ' -Force

Just Enough Administration constrains what a remote user can do in a PowerShell session by combining a role capabilities file (.psrc, which lists exactly which cmdlets, functions, and parameters a given role is allowed to use -- for example, a curated subset of the Hyper-V module ' s cmdlets) with a session configuration file (.pssc, generated by New-PSSessionConfigurationFile, which ties one or more role capabilities to security principals and session-wide restrictions). Once the .pssc file has been authored, it must be registered as an actual, connectable PowerShell endpoint on Server1 using Register-PSSessionConfiguration, specifying the .pssc file ' s path and a name for the resulting endpoint; -Force allows the registration to proceed even if a session configuration by that name already exists or the WinRM service needs restarting. Enter-PSSession simply starts an interactive remoting session against an existing endpoint and plays no role in creating or registering one. New-PSSessionConfigurationFile only creates the .pssc content -- it does not make the file usable as an actual session endpoint that remote users can connect to. Registering the wrong file type, such as a .ps1 script or .psm1 module, would fail, since Register-PSSessionConfiguration ' s -Path parameter specifically expects a .pssc session configuration file. Therefore, the command must be Register-PSSessionConfiguration -Path .\HyperVJeaConfig.pssc -Name ' HyperVJeaHelpDesk ' -Force.

User1 can use self-service password reset (SSPR) to reset his password: Yes. If User1 connects to Microsoft Exchange Online, an on-premises domain controller provides authentication: Yes. You can add User2 to Group1 as a member: No.

User1 ' s account lives in OU1, which is included in the Microsoft Entra Connect sync scope, so User1 has a corresponding, synced object in the tenant; with password writeback enabled and no other blocking configuration indicated, a synced user like User1 can use self-service password reset, and the reset password is written back to on-premises AD DS as well. Because password hash synchronization is explicitly disabled and pass-through authentication is enabled instead, cloud sign-in for synced users is validated by the pass-through authentication agent relaying the credential check to an on-premises domain controller in real time, rather than against a cloud-stored hash; so when User1 signs in to a cloud service such as Exchange Online, authentication is indeed provided by an on-premises domain controller through the PTA agent. User2, however, belongs to OU2, which was not selected in the Domain/OU filtering configuration, so User2 has no corresponding object synced into the tenant at all. Group1 is a group in the tenant (a cloud-side security group), and because User2 has no synced cloud identity to reference, User2 cannot be added as a member of Group1 — there is simply no cloud object representing User2 to add.

Because a domain-wide Group Policy Object already enforces Credential Guard with UEFI lock across all domain members, that policy setting is authoritative and will simply reapply the enabled, UEFI-locked Credential Guard configuration to Server1 the moment Group Policy next refreshes, entirely regardless of whatever one-time local change was just made to disable it. For the currently disabled state on Server1 to actually persist rather than being silently overwritten at the next policy refresh, the governing Group Policy Object itself has to be updated so that its Turn On Virtualization Based Security setting is no longer configured to enforce Credential Guard for the organizational unit or scope that Server1 falls under; only changing the policy that controls this setting stops Group Policy from re-asserting Credential Guard on Server1. Running the Device Guard and Credential Guard hardware readiness tool only assesses hardware compatibility and makes no configuration changes at all, and running dism with the /Disable-Feature and /FeatureName:IsolatedUserMode parameters only changes local machine state, which, exactly like the earlier local disable action, would simply be reverted the next time the domain-wide Group Policy setting reapplies to Server1.

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

Forest trusts are transitive across every domain within each of the two forests they connect but are never transitive into a third, unrelated forest, so a forest trust between contoso.com and fabrikam.com and a separate trust involving adatum.com and research.fabrikam.com do not chain together; contoso.com has no trust relationship of any kind with adatum.com ' s forest, so contoso.com users cannot access resources in adatum.com after both trusts are configured, making statement 1 false. The Contoso-Fabrikam requirement needs every domain in either forest to reach every domain in the other, which is precisely what a single two-way forest trust provides, since forest trust transitivity automatically extends to every child domain in both forests (contoso.com, europe.contoso.com, asia.contoso.com, fabrikam.com, and research.fabrikam.com), so statement 2 is true and no additional external or domain trusts are needed. The Adatum-Fabrikam requirement is narrower, needing only adatum.com ' s users to reach a single domain, research.fabrikam.com; a one-way external trust in which research.fabrikam.com is the trusting domain and adatum.com is the trusted domain grants exactly that direction of access (the trusting domain permits authorized users of the trusted domain to access its resources), and since only one specific domain pair needs access, the external trust ' s non-transitivity is not a limitation here, so statement 3 is true.

1. Stop VM1. 2. Resize the operating system disk. 3. Start VM1. 4. Resize volume C.

Resizing an existing Azure managed disk ' s provisioned capacity, unlike attaching or detaching an additional data disk, requires the virtual machine using that disk to be stopped (deallocated) first; Azure does not permit a disk resize operation against a disk that is currently attached to a running VM. The first step is therefore to stop VM1. With the VM deallocated, the operating system disk can be resized (increased from 128 GB up to 250 GB) through the Azure portal, CLI, or PowerShell. Once the resize completes, VM1 must be started again so that Windows can see and use the newly enlarged disk. Growing the underlying managed disk only makes additional unallocated space available at the disk level; it does not automatically grow the NTFS volume sitting on that disk, so the final step is to resize volume C from within the guest operating system (using Disk Management ' s Extend Volume wizard or diskpart ' s extend command) to actually claim that unallocated space into the C: volume. Resizing VM1 (changing its compute size/SKU) and redeploying VM1 (moving it to different underlying hardware) are unrelated operations that do not participate in a disk-capacity-increase workflow at all. The correct order is: stop VM1, resize the operating system disk, start VM1, then resize volume C.

The Disable-AzVMDiskEncryption cmdlet, part of the Az.Compute module, removes Azure Disk Encryption ' s protection from a VM ' s disks by uninstalling or reconfiguring the encryption extension, and its -VolumeType parameter accepts the values All, OS, or Data to scope exactly which class of disk the disable operation applies to. Specifying -VolumeType Data restricts the disable operation strictly to the data disks attached to VM1, leaving the OS disk ' s own BitLocker or DM-Crypt encryption state completely untouched, which precisely matches the requirement to disable encryption specifically on VM1 ' s data disks without affecting the operating system volume. The other candidate cmdlets shown, Disable-BitLocker, Set-AzVMDiskEncryptionExtension, and Set-AzVMDataDisk, either operate at the wrong layer, such as Disable-BitLocker acting inside the guest OS rather than through the Azure Resource Manager-level encryption extension, or perform the opposite or an unrelated operation, such as enabling encryption or attaching a data disk, so none of them accomplishes the specific disable-on-data-disks-only outcome the scenario calls for. Running this cmdlet against VM1 also triggers a VM reboot as part of removing the encryption extension ' s configuration from the targeted data disks.

Microsoft Entra Connect cloud sync uses a lightweight, on-premises provisioning agent to read directory data from AD DS and send it to the cloud provisioning service, rather than running the full, stateful sync engine that classic Microsoft Entra Connect (Connect Sync) uses. To authenticate and run its scheduled synchronization tasks without an administrator having to manage or periodically reset a password, the cloud provisioning agent is designed to run as a group managed service account, which Microsoft ' s setup process creates and configures automatically (or which can be pre-created for delegated/least-privilege scenarios) as part of enabling cloud sync. A group managed service account provides the automatic, periodically rotated password management that makes it suitable for a scheduled, unattended service like the provisioning agent, without exposing a static credential. A standard user account would require ongoing password management and does not offer the same automatic credential rotation or protection against interactive misuse. A system-assigned managed identity is an Azure resource identity mechanism used by Azure services calling other Azure services and has no role in an on-premises Windows agent authenticating to on-premises AD DS. An InetOrgPerson object is an alternate user-object class mainly used for compatibility with non-Windows LDAP directories and is not what the cloud sync provisioning agent uses. A group managed service account is therefore the correct account type.

The Storage Migration Service role (the orchestrator that manages the migration) requires an orchestrator server running Windows Server 2019 or later, and Microsoft explicitly recommends using the destination server as the orchestrator when only a single server is being migrated. Server2 is the only server in the table that meets this requirement (Windows Server 2025) — Server1 and Server3 both run Windows Server 2016, which does not qualify as an orchestrator. The Storage Migration Service tool (the Windows Admin Center extension used to drive the migration) runs on whichever machine is running the latest Windows Admin Center, which for a simple one-server migration is most naturally the same orchestrator/destination machine, Server2. Neither component has a Desktop Experience requirement, so the servers ' Install option (Server Core vs. Desktop Experience) is not a differentiator here — only the OS version requirement is, and both components can therefore be installed together on the single qualifying server.

The Windows Firewall data connector for Microsoft Sentinel streams events using the Azure Monitor Agent together with a data collection rule that targets the Windows Firewall event log source. The Azure Monitor Agent officially supports Windows Server 2016, Windows Server 2019, and Windows Server 2022, including the Azure Edition, so VM1, running Windows Server 2022 Datacenter: Azure Edition, VM2, running Windows Server 2019 Datacenter, and VM3, running Windows Server 2016 Datacenter, are all eligible on the operating-system front. Because all three are already Azure virtual machines, the Azure Monitor Agent extension can be deployed to each of them directly as a native Azure VM extension, with no additional onboarding required. Server1, in contrast, is an on-premises, non-Azure server, and the Azure Monitor Agent can only be deployed to a non-Azure machine once it has been onboarded as an Azure Arc-enabled server; since Server1 has not been connected to Azure Arc in this scenario, there is no supported path for it to run the agent or be targeted by a data collection rule, so it cannot forward Windows Firewall logs to Sentinel1 yet. This makes VM1, VM2, and VM3 only the correct set of servers that can currently send Windows Firewall logs to Sentinel1.

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.