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

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.

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.

Installing and authorizing a DHCP server in an Active Directory-integrated environment requires two distinct sets of rights: local Administrators group membership on Server3 to install the DHCP Server role itself, and Enterprise Admins group membership to authorize that server in AD DS, because DHCP server authorization is stored as a forest-wide object under CN=NetServices,CN=Services,CN=Configuration and only Enterprise Admins can create or modify objects there by default. Admin1 is a member of Contoso\Enterprise Admins, which grants exactly this forest-wide right and also carries local administrative rights on every domain-joined computer in the forest, including Server3, so Admin1 can both install the role and authorize the server, fully satisfying the requirement on his own. Admin2, a member of only Contoso\Domain Admins, has full administrative rights over contoso.com and its member computers, but Domain Admins does not carry the right to authorize a DHCP server in the forest-wide NetServices container, so Admin2 cannot complete authorization even though he can install the role. Admin3, a member of Canada\Domain Admins, has administrative rights limited to the canada.contoso.com domain and likewise lacks the Enterprise Admins-only authorization right needed here, since Server3 and the DHCP authorization object both fall outside that domain ' s scope of control. Because only Admin1 holds both the local administrative rights needed to install the DHCP Server role on Server3 and the Enterprise Admins membership needed to authorize it in AD DS, Admin1 only is 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.

Group3: Group1, Group2, Group4, and Group5 only. Group5: Group4 only.

Group nesting in AD DS is governed strictly by group scope, independent of whether a group is security- or distribution-type. A Domain Local group can contain user accounts, Global groups from any domain, and Universal groups from any domain, plus other Domain Local groups from its own domain only. Group3 is a Domain Local group in contoso.com, so it can accept Group1 (Universal, contoso.com), Group2 (Global, contoso.com), and Group4 and Group5 (both Global, canada.contoso.com), since Global groups from any domain are valid Domain Local members. It cannot accept Group6, because Group6 is Domain Local in canada.contoso.com, a different domain, and Domain Local groups may only nest other Domain Local groups from their own domain. That gives Group3: Group1, Group2, Group4, and Group5 only. A Global group, by contrast, can contain only user accounts and other Global groups from the same domain. Group5 is Global in canada.contoso.com, so among the remaining groups only Group4 qualifies, since it is also Global and in the same domain; Group1 (Universal), Group2 (Global but a different domain), and Group6 (Domain Local) are all excluded by scope rules. That gives Group5: Group4 only.

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.

Site, subnet, and site-link objects are stored in the Configuration partition, which replicates to every domain controller in the forest but is administratively owned by the forest root domain. By default, only members of Enterprise Admins and members of the Domain Admins group of the forest root domain (contoso.com in this forest) have permissions to modify objects in the Configuration container, including editing a site link ' s replication schedule. Admin1 is a member of Contoso\Enterprise Admins and therefore has forest-wide rights over the Configuration partition. Admin2 is a member of Contoso\Domain Admins; because contoso.com is the forest root domain, this group also carries default rights over the Configuration and Schema partitions. Admin3, however, is a member of Canada\Domain Admins, the Domain Admins group of the canada.contoso.com child domain, which has no inherent rights over the Configuration partition. Consequently, to change the replication schedule on all site links to 30 minutes, only Admin1 and Admin2 currently have the necessary permissions, making option C the correct answer.

Promoting a member server to a domain controller in a specific domain requires membership in either the Enterprise Admins group (forest-wide rights) or the Domain Admins group of that target domain. Server1 is a member server in canada.contoso.com, and the requirement is to promote it to a domain controller in that same domain. Admin1 belongs to Contoso\Enterprise Admins, which has full administrative rights across every domain in the forest, including the right to install AD DS and promote a server anywhere in the forest, so Admin1 qualifies. Admin3 belongs to Canada\Domain Admins, the Domain Admins group of canada.contoso.com itself, which grants full administrative control, including domain controller promotion, within that domain, so Admin3 also qualifies. Admin2, by contrast, is a member of Contoso\Domain Admins, the Domain Admins group of the contoso.com domain; Domain Admins rights are scoped to their own domain and do not extend into a child domain such as canada.contoso.com, so Admin2 cannot promote Server1. User1 has only standard Domain Users membership and holds no administrative rights anywhere. Therefore, only Admin1 and Admin3 currently have sufficient rights, making option C correct.

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.

The requirement is narrow: User1 must be able to manage the membership of all the groups located in Contoso\OU3, and nothing more. The Delegation of Control Wizard, run against OU3 specifically, lets an administrator grant User1 exactly the built-in task " Modify the membership of a group, " which grants write access to the member attribute on group objects contained in that OU only. This satisfies the requirement while granting no rights outside OU3, which is the definition of least privilege. Creating the same delegation at the domain root (contoso.com) would technically work but grants far broader scope than needed, since it would apply to every container in the domain, not just OU3, violating least privilege. Adding User1 to Account Operators grants domain-wide rights to create, delete, and modify most user, group, and computer accounts throughout the domain (with some protections for built-in admin accounts), which is excessive for a task limited to group membership in one OU. Server Operators is unrelated to Active Directory object management altogether; it governs local administrative rights on domain controllers themselves. Therefore, delegating control on OU3 is the correct, minimally scoped solution.