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

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.

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.

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.

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.

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.

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.

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.

Organize users: Domain global. Assign permissions: Domain local.

This scenario is the classic AGDLP model (Accounts into Global groups into Domain Local groups, granted Permissions) extended across a forest trust. Contoso.com users must be added only to groups that live in the contoso.com forest, which points to a domain global group created in one of the contoso.com domains; global groups are specifically designed to hold user accounts from their own domain and to be referenced elsewhere, including across a trust. That global group is then nested inside a domain local group created in a fabrikam.com domain, and permissions to the fabrikam.com resources are granted directly to that domain local group — satisfying the requirement that permission grants happen only on fabrikam.com groups. Domain local groups can accept members from any domain in a trusted forest when a forest trust exists, which is exactly what allows the contoso.com global group to be nested inside the fabrikam.com domain local group despite the forest boundary. This achieves both constraints using only two groups total (one global, one domain local), which is the minimum possible, since eliminating either group would violate one of the two placement requirements (users must stay in a contoso.com group; permissions must land on a fabrikam.com group). A universal group is not needed and would not, by itself, reduce the group count below two.

Reputation-based protection, found under App & browser control in Windows Security, governs Microsoft Defender SmartScreen ' s checks of applications, files, and websites based on their reputation before they are permitted to run or be downloaded. It is designed to block or warn about untrusted or malicious code and content, not to restrict which already-installed, already-trusted applications are permitted to modify files inside specific designated folders. Limiting write access to protected folders so that only explicitly approved applications can modify their contents is the specific job of Controlled folder access, which is configured under Virus & threat protection, Ransomware protection, and lets an administrator add trusted applications to an allowed list while blocking every other process from writing to the protected folders. Because Reputation-based protection addresses a fundamentally different threat model, evaluating whether software should be allowed to execute at all rather than whether an already-running application can write to a specific folder, configuring it does not achieve the goal of restricting folder modification to specific applications, so this solution does not meet the goal.

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.