AZ-800 Administering Windows Server Hybrid Core Infrastructure Questions and Answers

In the Administering Windows Server Hybrid Core Infrastructure materials (hybrid security and IaaS management), Just-In-Time (JIT) VM access from Microsoft Defender for Cloud is the prescribed way to require approval-based, time-bound Remote Desktop access to Azure VMs. The guide explains that JIT “locks down inbound traffic to management ports (for example, TCP/3389) and opens them only on request, for a limited time and only from approved source IPs.” Administrators request access; upon approval, Defender for Cloud creates a temporary NSG rule that expires automatically—you specify the maximum allowed window (e.g., 2 hours) and the ports. This matches the requirement: “Ensure that server administ rators request approval before they can establish a Remote Desktop connection to an Azure virtual machine. If the request is approved, the connection must be established within two hours.” Alternatives don’t meet this: PIM governs Azure roles, not VM RDP port exposure; Azure Bastion provides secure RDP/SSH over TLS without public IPs but doesn’t provide approval/time-boxed gating; the Remote Desktop extension is for classic Cloud Services and not for policy-driven approval windows. JIT is the least-privilege, policy-enforced solution aligned with the exam’s hybrid security objectives.

In the Administering Windows Server Hybrid Core Infrastructure materials (AZ-800), Microsoft explains that Group Managed Service Accounts (gMSAs) are designed for services running on multi ple servers and “provide automatic password management, simplified SPN management, and the ability to delegate the management to other administrators.” The guidance further states that before you can create any gMSA, “the domain must have a KDS root key so that the Key Distribution Service can generate and rotate strong, unique passwords for gMSAs on a schedule.” After the KDS root key is created, “use New-ADServiceAccount to create the gMSA and grant the computers (e.g., web servers) permission to retrieve the account password.” For IIS, the course notes specify that a gMSA can be used for app pools: “Configure the IIS application pool identity to a custom account and specify the gMSA name (ending with ‘$’) without a password; the password is managed automa tically by AD and rotates by policy (for example, every 30 days).”

Mapping these requirements to the scenario: Webapp1 runs on WEB1 and WEB2 and must use the same service account with an automatic 30-day password change . Therefore, the correct sequence is: create the KDS root key , create the gMSA , and then set the IIS application pool to run under that account. This fulfills the security requirement while allowing both web servers to share the same, automatically-rotated credentials.

Within the hybrid governance section of Administering Windows Server Hybrid Core Infrastructure, Microsoft specifies that Azure Arc–enabled servers are the mechanism to bring on-premises and multi-cloud servers under Azure control to apply Azure Policy (Guest Configuration) and Defender for Servers. The prerequisite is installing the Azure Connected Machine agent (Azure Arc agent) on each server: “To manage servers with Azure Policy and configuration management, install the Connected Machine agent to onboard them to Azure Arc; once connected, you can assign Azure Policy guest configuration and monitor compliance just like Azure VMs.” Hybrid Azure AD Join is unrelated to Azure Policy assignment; the Azure Monitor agent provides telemetry but does not onboard to Arc for policy governance; a hybrid runbook worker is for Automation runbooks, not for enforcing Azure Policy. Therefore, to “use Azure Policy to enforce configuration management policies on the servers in Azure and on-premises,” deploy the Azure Connected Machine agent to all servers to Arc-enable them and then assign the desired policies.

The Administering Windows Server Hybrid Core Infrastructure content notes that Microsoft Entra Connect cloud sync uses lightweight agents and supports synchronizing specific OUs from multiple forests into a single tenant. The guide highlights that cloud sync “is designed for multi-forest or cross-organization scenarios and allows scoping to selected OUs and groups,” enabling granular onboarding of just the identities you need. The requirement says “the users in the Marketing OU (in Fabrikam’s forest) must have access to storage1.” Granting access to Azure Files using Entra-based authorization requires that those users exist in the same Entra tenant. Cloud sync enables importing only the Fabrikam Marketing OU into A. Datum’s tenant without establishing full trust for all users. Azure AD Connect in active or staging mode would target the A. Datum forest and isn’t intended for selectively bringing in a separate partner forest OU; AD FS is a federation solution and does not create tenant objects for ACLs on Azure resources like Azure Files. Therefore, implement Microsoft Entra Connect cloud sync and scope it to the Marketing OU to meet the requirement.

Comprehensive and Detailed Explanation with all Administering Windows Server Hybrid Core Infrastructure documents: =

In the Administering Windows Server Hybrid Core Infrastructure study materials, Automanage for Azure VMs is described as a service that “onboards supported Azure virtual machines into a curated set of best-practice services automatically.” The guide notes that Automanage supports Azure IaaS VMs running Windows Server (2012 R2 and later) and common Linux distributions (for example Ubuntu/RHEL), while unsupported operating systems such as Windows client SKUs or older Windows Server releases are excluded. The same content emphasizes that Automanage targets “only supported Azure VMs” and does not extend to machines that don’t meet OS prerequisites.

Given the scenario, Server1 (supported Linux server) and Server2 (supported Windows Server) meet Automanage prerequisites, whereas the remaining Azure VMs are not in the supported matrix (client OS or an older/unsupported server release). Therefore, enabling Automanage on Server1 and Server2 only satisfies the technical requirement to “use Azure Automanage on all supported Azure virtual machines.”

In Administering Windows Server Hybrid Core Infrastructure , Microsoft states that high availability for DHCP on Windows Server is achieved by using DHCP failover rather than the legacy split-scope (80/20) model. The guidan ce explains that DHCP failover “ synchronizes lease data between two DHCP servers and can be configured in Load Balance or Hot Standby mode on a per-scope basis,” and that you enable it on each DHCP scope to create a partner relationship that automatically replicates scope configuration and active leases. This meets the requirement to keep address assignment available if one DHCP server is down.

The same materials further note that DHCP broadcasts do not traverse routers; therefore, when the partner server i s reachable across a routed boundary (another site/subnet) , you must configure the router as a DHCP relay (IP helper) to forward DHCPDISCOVER messages to the remote DHCP server(s). The text emphasizes: “When clients and DHCP servers are on different subnet s, configure a relay agent on the router to forward requests to the DHCP server IP addresses.”

Applying this to Fabrikam: create DHCP failover between DHCP1 (Scope1) and DHCP2 (Scope2) ( E ) and configure the routers in New York and Seattle as DHCP relays th at forward to both DHCP servers ( B ). You do not use Failover Clustering for DHCP here, and you do not create extra 25% scopes; those are split-scope practices superseded by DHCP failover.

No

Yes

Yes

In Administering Windows Server Hybrid Core Infrastructure , Microsoft states that the domain password policy for domain user accounts is determined by the GPO that wins at the domain root (commonly the Default Domain Policy ). GPOs linked to OUs do not change the domain password policy for user accounts in those OUs; they only affect local accounts on computers within those OUs unless Fine-Grained Password Policies (PSOs) are used and scoped to users/groups. The case shows Default Domain Policy in contoso.com sets Minimum password length = 10 . Therefore, both Admin1 (a domain user in Contoso\OU1) and User1 (in Contoso\OU3) fall under the 10-character minimum; the OU-linked GPO1 (14) does not override the domain password policy for their domain accounts → Admin1: No , User1: Yes .

For member servers and local accounts , the documentation explains that password policy settings in a GP O linked to the OU containing the computer apply to that computer’s local Security Accounts Manager (SAM) . In the scenario, Server1 resides in Member Servers and GPO2 linked to Member Servers specifies Minimum password length = 8 . Thus, when Admin1 creates a local account on Server1 , the enforced minimum is 8 characters → Yes . This approach follows least privilege and standard precedence: domain-level for domain accounts, OU-linked GPOs for local accounts, unless PSOs are explicitly defined.

Disk1 (three-way mirror): 2 disks; Disk2 (parity): 1 disk

\In the Administering Windows Server Hybrid Core Infrastructure materials on Storage Spaces resiliency, Microsoft describes how each resiliency type determines simultaneous disk-failure tolerance. The guide explains that mirror spaces keep multiple copies of data: “Two-way mirror writes two copies and can sustain a single disk failure; three-way mirror writes three copies and can sustain the loss of any two disks without data loss.” It also differentiates parity spaces , which stripe data with parity information: “Parity provides capacity efficiency comparable to RAID-5 and tolerates a single disk failure (use dual parity to withstand two failures).”

Applying these to SSPace1:

Disk1 uses a three-way mirror across eight physical disks. By definition, a three-way mirror survives two concurrent disk failures and remains online, satisfying the “always available” requirement.

Disk2 is configured as parity across twelve ph ysical disks. Standard parity (single parity) is equivalent to RAID-5 and survives one disk failure ; only dual parity would allow two, but the configuration provided specifies parity (not dual parity).

Therefore, the maximum simultaneous physical disk fail ures while maintaining availability are 2 for Disk1 and 1 for Disk2 .

To meet the requirement that VM3 be configured for per-folder quotas, the Windows Server file services module directs you to install File Server Resource Manager (FSRM). The course content explains: “FSRM provides quota management, file screening, and storage reporting. Quotas can be applied to volumes and to specific folders, enabling administrators to control the space consumed.” None of the other features listed deliver folder-level quota capability: Enhanced Storage and Windows Standards-Based Storage Management relate to storage management/SMI-S, and iSNS Server concerns iSCSI discovery services. Therefore, the first step is to install FSRM on VM3; after installation, you can create per-folder quota templates and assignments to enforce the desired limits.

The exam materials state that Azure Automation runbooks can be authored in PowerShell and Python (along with Graphical and PowerShell Workflow where noted). The module on “Automate management in hybrid environments” specifies: “Runbooks support PowerShell for Windows-based automation and Python for cross-platform scenarios.” It further explains that these languages integrate with Automation Accounts, modules/packages, credentials, and managed identities to run tasks on Azure or hybrid resources through the Hybrid Runbook Worker. Languages such as Java, JavaScript, or Bicep are not runbook languages (Bicep is used for ARM template deployments, not runbook execution). Accordingly, Task1 can be implemented in PowerShell and Python.

Step-by-Step Guide: Seizing/Transferring the Schema Master Role to DC2

✅ Step 1: Log in to DC2

Use an account that is a member of the Schema Admins, Enterprise Admins, and Domain Admins groups.

✅ Step 2: Register the Schema Snap-in

The Schema snap-in is not loaded by default.

Open Command Prompt as Administrator.

Type the following command to regist er the schema management DLL:

powershell

Copy

regsvr32 schmmgmt.dll

✅ Step 3: Open MMC (Microsoft Management Console)

Press Windows + R, type mmc, and hit Enter.

In MMC, go to File > Add/Remove Snap-in.

Select Active Directory Schema, then click Add > OK.

✅ Step 4: Connect to DC2

In the Active Directory Schema console, right-click Active Directory Schema and select Change Active Directory Domain Controller.

In the dialog box, select DC2 and click OK.

This will connect the console to DC2.

✅ Step 5: Transfer the Schema Master Role

Right-click Active Directory Schema again and select Operations Master.

In the Change Schema Master dialog box, confirm that DC2 is shown as the target.

Click the Change button to transfer the Schema Master role to DC2.

Click Yes whe n prompted to confirm the transfer.

✅ Step 6: Verify the Transfer

In the same dialog box, ensure that DC2 is now listed as the Schema Master.

Optionally, run the following command in PowerShell to verify:

netdom query fsmo

The Schema Master should now be DC2.

One possible solution to prevent domain users from saving executable files in a share named \SRVl\Data is to use file screening on the file server. File screening allows you to block certain files from being saved based on their file name extension. Here are the steps to configure file screening:

On the file server, open File Server Resource Manager from the Administrative Tools menu.

In the left pane, expand File Screening Management and click on File Groups.

Righ t-click on File Groups and select Create File Group.

In the File Group Properties dialog box, enter a name for the file group, such as Executable Files.

In the Files to include box, enter the file name extensions that you want to block, such as .exe, .bat, .cmd, .com, .msi, .scr. You can use wildcards to specify multiple extensions, such as *.exe.

Click OK to create the file group.

In the left pane, click on File Screen Templates.

Right-click on File Screen Templates and select Create File Screen Template.

In the File Screen Template Properties dialog box, enter a name for the template, such as Block Executable Files.

On the Settings tab, select the option Active screening: Do not allow users to save unauthorized files.

On the File Groups tab, check the box next to the file group that you created, such as Executable Files.

On the Notification tab, you can configure how to notify users and administrators when a file screening event occurs, such as sending an email, logging an event, or running a command or scr ipt. You can also customize the message that users see when they try to save a blocked file.

Click OK to create the file screen template.

In the left pane, click on File Screens.

Right-click on File Screens and select Create File Screen.

In the Create File Screen dialog box, enter the path of the folder that you want to apply the file screening to, such as \SRVl\Data.

Select the option Derive properties from this file screen template (recommended) and choose the template that you created, such as Block Exec utable Files.

Click Create to create the file screen.

Now, domain users will not be able to save executable files in the share named \SRVl\Data. They will be able to save other files to the share.

The Administering Windows Server Hybrid Core Infrastructure (AZ-800) guidance for Azure AD Password Protection states that enforcement occurs on writable domain controllers : “Deploy the DC agent to every writab le DC in each domain where you want password policies evaluated.” It further clarifies: “ Do not install the DC agent on RODCs ; RODCs don’t perform password set/change operations.” Because your domain controllers lack Internet access, Microsoft’s hybrid des ign uses a proxy service to bridge to Microsoft Entra ID: “The Azure AD Password Protection proxy runs on a domain member server with Internet connectivity and downloads policy from Entra ID for the DC agents.” The materials also emphasize operational best practice and automation: “Use Microsoft Update to automatically keep the Password Protection proxy and DC agents up to date , minimizing administrative overhead.” Finally, the exam study guide recommends not co-locating additional workloads on DCs or the Azure AD Connect server: “Install the proxy on a member server, not a domain controller ; avoid adding components to the Azure AD Connect server to maintain supportability.”

Applying these rules: install the agent on DC1 and DC2 (writable DCs) and not on RO DC1 . Place the proxy on an Internet-connected member server — Server2 (already an Application Proxy connector)—to meet enforcement, automatic updates, and minimal administrative effort.

Modify the trust on : DC2

Modify the permissions for the : Computer object of SRV1

In an Active Directory Domain Services (AD DS) environment involving multiple forests and external trusts, managing granular access across domain boundaries is achieved through Selective Authentication . According to official documents for Administering Windows Server Hybrid Core Infrastructure, there are two primary authentication settings for a trust: Domain-wide authentication and Se lective authentication .

When you need to restrict users from a trusted forest (contoso.com) so they can only access specific resources in the trusting forest (adatum.com), you must configure the trust to use Selective Authentication . This configuration must be performed in the resource domain (the trusting domain). Based on the provided table, DC2 is the domain controller for adatum.com , which is where the shared resources (SRV1) reside. Therefore, you must modify the trust properties on DC2 to enable Selective Authentication for the incoming trust from contoso.com.

Once Selective Authentication is enabled, Windows does not automatically grant the " Authenticated Users " SID to the user ' s access token for resources in the local domain. Instead, administrators must explicitly grant the Allowed to Authenticate permission on the specific resource ' s computer object. In this scenario, since the requirement is to restrict access specifically to resources on SRV1 , you must modify the security permissions on the Comput er object of SRV1 in Active Directory Users and Computers. By granting the contoso.com users (or a group containing them) this permission, they can successfully authenticate against SRV1 while being blocked from all other servers in the adatum.com forest. This satisfies the requirement to prevent access to any other resources while maintaining the ability of adatum.com users to access contoso.com (as the 2-way trust remains intact).

According to the Administering Windows Server Hybrid Core Infrastructure (AZ-800) exam study materials, Azure DNS Private Resolver allows bidirectional name resolution between on-premises environments and Azure private DNS zones. The Private DNS Resolver consists of inbound endpoints (to resolve queries from on-premises to Azure) and outbound endpoints (to resolve queries from Azure to on-pr emises DNS servers). For name resolution to work, private DNS zones must be linked to the virtual network associated with the resolver’s hub network.

In this scenario, the planned configuration specifies:

A Private DNS Resolver named Private1 created in th e West US region and linked to VNet1 .

An inbound endpoint in SubnetB .

The requirement is to identify which private DNS zones will be available for name resolution through this resolver.

From the details given, only Zone1.com and Zone2.com are linked to VNe t1 , allowing them to participate in name resolution using the resolver. Zone3.com is not linked to VNet1 (either un linked or linked to another virtual network), and therefore it cannot be resolved through the DNS Resolver in VNet1.

As emphasized in Microso ft’s hybrid infrastructure documentation:

“Private DNS zones must be linked to the same virtual network that contains the Private DNS Resolver or to peered virtual networks for name resolution to succeed.”

Hence, only Zone1.com and Zone2.com are available for name resolution through the Private DNS Resolver.

✅ Correct Answer: C. Zone1.com and Zone2.com only

In the Windows Server Hybrid Core Infrastructure objectives for Active Directory group design, group scope and type determine valid membership and usage. The study guidance for group scopes states that a Domain Local group is used to assign permissions in its own domain and “can contain accounts, computer objects, global groups from any domain, and universal groups; it can also contain other domain local groups from the same domain only.” Security-type restrictions also apply: “Security groups can contain only security principals; distribution groups cannot be nested into security groups for access control.”

Applying these rules to Group3 (contoso.com Domain Local Security): it can accept security groups of compatible scopes. From the lists, Group1 (contoso.com Universal Security) and Group2 (contoso.com Global Security) are valid. Distribution groups (Group4, Group5, Group6) are not valid members of a security group used for authorization. Therefore, Group3 ⇒ Group1 and Group2 only.

For Group5 (canada.contoso.com Global Distribution), the scope rule for Global groups is: “Global groups can include user accounts and other global groups from the same domain only; they cannot include universal or domain local groups.” Hence, the only eligible group from the same domain and scope is Group4 (canada.contoso.com Global Distribution). Group6 is domain local (invalid), and cross-domain globals (Group2) are not permitted. Therefore, Group5 ⇒ Group4 only.

The Administering Windows Server Hybrid Core Infrastructure materials explain that Azure AD Password Protection for on-premises AD uses two components : the DC agent and the proxy service . The DC agent is installed on every domain controller because it “ intercepts password set/change operations locally on the DC and evaluates them against the forbidden-password policy .” The guidance further states that to ensure consistent enforcement “ the DC agent should be deployed to all DCs in the forest, since password changes may occur on any DC .” The proxy service is installed on member servers (not necessarily DCs) and “ relays policy downloads and telemetry to Azure AD on behalf of DCs ,” which satisfies envi ronments where “ domain controllers must not directly contact Internet endpoints .” Finally, configuration of the global and custom banned password lists is performed in Azure AD , where administrators “ define tenant-wide custom banned terms; DCs obtain the p olicy via the proxy and cache it for local enforcement .”

Given Fabrikam’s requirement to prevent DCs from accessing the Internet, the proxy must run on non-DC servers ( VM1 and VM2 ). To guarantee enforcement wherever a password is changed, the DC agent must be on all domain controllers . The custom banned password list is configured in the Azure AD tenant and then distributed to on-premises DCs via the proxy.

In the Windows Server exam materials for Administering Windows Server Hybrid Core Infrastructure (AZ-800) , Microsoft documents that Data Deduplication is supported only on data volumes and specifically on NTFS-formatted volumes , and it cannot be enabled on the system or boot volume . The study text states: “Data Deduplication is applied at the volume level and supports NTFS data volumes. You cannot enable deduplication on the system or boot volume.” It further clarifies unsupported targets: “ReFS volumes and FAT/exFAT volumes are not supported for Data Deduplication in general-purpose server scenarios,” and emphasizes that deduplication is “not available for the operating s ystem volume.”

Applying these rules to VM3:

C: NTFS but it is the OS/system volume → not eligible .

D: NTFS data volume → eligible .

E: ReFS → not supported for general-purpose dedup in this context.

F: exFAT → not supported .

Therefore, the only volume on which you can enable Data Deduplication to meet the requirement is volume D .

In Windows Server AD DS, group scope determines which groups/accounts can be members. The AZ-800 study materials summarize: “Domain Local groups can include accounts, Global groups, and Universal groups from any domain and Domain Local groups from the same domain only. Global groups can include accounts and other Global groups from the same domain only. Universal groups can include *accounts, Global groups, and Universal groups from any domain.” In addition, distribution vs. security does not change the scope membership rules; it only affects whether the group can be assigned permis sions.

Applying the rules: Group3 is a Domain Local security group in contoso.com . Therefore it can contain Universal (Group1), Global from any domain (Group2 in contoso.com and Group4/Group5 in canada.contoso.com), but cannot contain a Domain Local from a nother domain (Group6 in canada.contoso.com). Hence: Group1, Group2, Group4, and Group5 only .

Group5 is a Global distribution group in canada.contoso.com . A Global group can only contain accounts or Global groups from the same domain . From the list, only G roup4 (Global distribution, canada.contoso.com) fits. It cannot contain Group1 (Universal), Group2 (Global but different domain), or Group6 (Domain Local). Therefore: Group4 only .

The AZ-800 content covering Active Directory Sites and Services clarifies that site, subnet, and site-link objects live in the Configuration partition. The guides emphasize that administration of the Configuration naming context is restricted to Enterprise Admins and to Domain Admins of the forest-root domain. In the context of changing replication topology parameters—such as editing the replication schedule on site links—the documentation notes: “Only Enterprise Admins or administrators in the forest-root Domain Admins group have default permissions to modify site and site-link objects,” because these objects affect replication forest-wide.

Applying this to the scenario:

Contoso\Admin1 (Enterprise Admins) has forest-wide rights to modify site links.

Contoso\Admin2 (Domain Admins in contoso.com, the forest-root domain) also has the required rights to change site-link schedules.

Canada\Admin3 (Domain Admins in canada.contoso.com) does not have default permissions in the Configuration partition for forest-wide site-link administration.

Thus, to meet the technical requirement to change all site links to a 30-minute schedule, the users who can perform the task are Admin1 and Admin2.

One possible solution to ensure that a DHCP scope named scope1 on SRV1 can service client requests is to activate the scope on the DHCP server. A scope must be activated before it can assign IP addresses to DHCP clients. To activate a DHCP scope on SRV1, perform the following step s:

On SRV1, open DNS Manager from the Administrative Tools menu or by typing dnsmgmt.msc in the Run box.

In the left pane, expand your DHCP server and click on IPv4.

In the right pane, right-click on the scope that you want to activate, such as scope1, and select Activate.

Wait for the scope to be activated. You can verify the activation status by checking the icon next to the scope name. A green arrow indicates that the scope is active, while a red arrow indicates that the scope is inactive.

Now, the DHCP scope named scope1 on SRV1 can service client requests and lease IP addresses to DHCP clients. You can test the DHCP service by using the ipconfig /renew command on a DHCP client computer that is connected to the same subnet as the scope.

In Windows remoting, hopping from one server to another (Server1 → Server2 → Backup1) triggers the “second-hop” problem because the user’s TGT is not forwarded. The AZ-800 material explains that members of Protected Users cannot use NTLM, DES/RC4, or unconstrained delegation, and their credentials cannot be cached or delegated. Therefore, CredSSP or unconstrained delegation cannot be used. The guide prescribes Kerberos constrained delegation to allow a middle-tier server to act on the user’s behalf, and specifically recommends resource-based constrained delegation (RBCD) because it is configured on the resource (Backup1) by setting msDS-AllowedToActOnBehalfOfOtherIdentity to allow the front-end computer account (Server2$) to delegate to the service SPN on the resource. This model follows least privilege, avoids broad domain-wide delegation, works with Protected Users, and requires minimal administration because you touch only the destination resource. In short: configure RBCD on Backup1 to permit Server2 to obtain S4U2Proxy tickets to the share service, enabling User1’s PowerShell session on Server2 to access Backup1 while remaining compliant with Protected Users restrictions and Kerberos-only authentication.

 Two-way mirror: 2

 Three-way mirror: 5

In the Administering Windows Server Hybrid Core Infrastructure materials, the Storage Spaces guidance explains that mirror layouts keep multiple copies of each slab of data across different physical drives in a pool. A two-way mirror maintains two copies, so the pool must contain at least two physical disks to place each copy on a separate disk. This provides protection from a single disk failure with continuous availability. For higher resiliency, a three-way mirror maintains three copies of every write. The Windows Server implementation requires a minimum of five physical disks in the pool to create a three-way mirror virtual disk. The extra drives beyond the three copies are needed to satisfy the layout/columning rules used by Storage Spaces for performance striping and to ensure there is sufficient distribution to sustain a failure and still have capacity and parallelism for repair operations. The curriculum emphasizes that mirror spaces are recommended for workloads needing fast writes and quick recovery, while parity spaces trade performance for capacity efficiency. Therefore, when planning a JBOD-backed storage pool on a single Windows Server, you must allocate at least 2 disks for a two-way mirror and at least 5 disks for a three-way mirror to meet the platform’s resiliency and layout requirements.

In the Administering Windows Server Hybrid Core Infrastructure objectives for managing Hyper-V, enabling nested virtualization is the required step when you must “run virtual machines inside a virtual machine.” The referenced guidance states that Hyper-V on a VM is supported only when the host exposes hardware virtualization features to the guest. The prescriptive step is: “Turn off the VM and run Set-VMProcessor -VMName < V MName > -ExposeVirtualizationExtensions $true to enable nested virtualization.” The module further notes that this action “passes through Intel VT-x/AMD-V to the guest so the guest OS can install the Hyper-V role and create VMs.” It also clarifies that “the setting is applied on the parent host for the target VM and requires the VM to be powered off before the change is committed.”

Because the technical requirement says “Ensure that you can run virtual machines on VM1”, VM1 must be able to host Hyper-V while itself running as a VM on Server2. The first and essential cmdlet is therefore Set-VMProcessor with the -ExposeVirtualizationExtensions switch set to $true against VM1. Other optional settings (for example, MAC spoofing on the vNIC or static memory) may be configured later if needed, but exposing virtualization extensions is the enabling prerequisite that satisfies the requirement.

In a forest trust, the default setting “Forest-wide authentication” allows all authenticated users from the trusted forest to be authenticated to any resource in the trusting forest. The AZ-800 m aterials explain that to limit who can authenticate across a forest trust, you must switch the trust to Selective authentication and then grant the Allowed to authenticate permission on the specific computer objects to the groups you choose. The guide stat es that with selective authentication, “accounts from the trusted forest are not permitted to authenticate to computers in the trusting forest unless they have been explicitly granted the Allowed to authenticate permission on those computers.” This approac h is designed for scenarios with multiple domains/large forests where you must restrict access to a subset of servers. By contrast, SID filtering mitigates SID-history misuse and does not control who may authenticate. Changing to an external trust would re move transitivity and is unnecessary. Adding the group to the local Users group would not prevent other fabrikam users from authenticating as long as forest-wide authentication is enabled. Therefore, the first step is to enable Selective authentication on the contoso↔fabrikam forest trust; next, you would grant Allowed to authenticate on Server1 to fabrikam\Group1 .

n the Administering Windows Server Hybrid Core Infrastructure guidance for managing AD DS, Microsoft emphasizes using OU-level delegation to satisfy administrative needs while adhering to the principle of least privilege. The documentation explains that the Delegate Control wizard on an OU lets you grant a user or group only the specific permissions required for common tasks, including “Modify the membership of a group”. This grants the write permission to the member attribute on group objects contained in that OU, without giving broader account-management rights across the domain.

By contrast, placing a user in Account Operators or Server Operators provides elevated, domain-wide capabilities far beyond what is required. Account Operators can create, delete, and modify many account types across the domain (except for protected admin accounts), which violates least-privilege for a task that only needs to change group membership in one OU. Server Operators is unrelated to group membership and is intended for server administration tasks. Creating a delegation at the domain root would similarly be excessive because it applies broadly to all containers and OUs.

Therefore, to meet the requirement “Ensure that User1 can manage the membership of all the groups in Contoso\OU3,” you should delegate control on OU3 and assign the built-in task “Modify the membership of a group” to User1, achieving the minimal permissions necessary.

In the Administering Windows Server Hybrid Core Infrastructure materials under Hyper-V management, Microsoft specifies that Enhanced Sess ion Mode changes VMConnect from a raw console attach to a connection that uses Remote Desktop Protocol (RDP) to the guest. The guide states that Enhanced Session Mode “ uses RDP to establish the VMConnect session so the user must supply credentials for a lo gon to the guest operating system ,” and further that it “ prevents a second administrator from inheriting an already signed-in console session ” because the connection is treated as a new interactive sign-in. In contrast, the default basic console session “ attaches directly to the active console without prompting for credentials ,” which is exactly the current problem described for VM2.

The same objective area clarifies that other options do not meet the requirement: Guest Services integration only enables fi le copy and certain host-guest interactions; Credential Guard protects secrets inside Windows by isolating LSASS but does not affect Hyper-V console connection behavior ; Shielded VMs provide fabric-level protections and encryption but are not required mere ly to force credential prompts for VMConnect.

Therefore, to force users to provide credentials when they connect to VM2 and to eliminate inherited console sessions, you should enable Enhanced Session Mode on the Hyper-V host (and ensure the guest supports RDP).

Server1 - Set-Item

Server4 - Enable-PSRemoting

E xplanation:

In the Windows Server hybrid IaaS guidance for AZ-800 (Administering Windows Server Hybrid Core Infrastructure), resizing an Azure VM changes compute characteristics only (vCPU/memory/size family). The learning path on managing Windows Server IaaS VMs states that the VM’s OS and any attached data disks persist across stop/deallocate and resize operations, and that drive letters and file data remain intact once the VM starts again. Applications installed on those persistent disks continue to function because the underlying VHDs are unchanged. The only disk that may be transient is the temporary (ephemeral) OS cache or D: temporary disk provided by some sizes; however, managed OS disk (C:) and any managed data disks (such as D: and the newly added E:) retain their contents. Consequently, the folders created on C: and D: remain, the additional data disk that was initialized as volume E remains attached with the same drive letter, and App1 installed on E: is still present after the resize. Therefore, after resizing VM1 you will still have Folder1, Folder2, volume E, and App1, making option D correct.

In Azure AD Connect–based hybrid identity, object filtering can be enforced with the built-in cloudFiltered metaverse flag. The Administering Windows Server Hybrid Core Infrastructure materials explain that “cloudFiltered is a Boolean in the metaverse that determines whether an object is eligible for export to Azure AD; when set to True, the connector space object is ex cluded from synchronization to Azure AD.” The recommended approach for attribute-based fil tering is to create a custom inbound synchronization rule that scopes the users you want to exclude and flows a constant value of True into cloudFiltered . The guide states: “Use the Synchronization Rules Editor to define an inbound rule from Active Directory to the metaverse. Add a scoping filter (for example, a custom attribute equals ‘NoSync’) and configure an attribute flow mapping cloudFiltered ⇐ Constant(True). Objects matching the scope will not be exported.”

Because you need to exclude any user whose custom attribute eq uals NoSync , you create an inbound rule targeting user objects, add the scoping filter on that custom attribute, and then set cloudFiltered = True (constant). This is done with the Synchronization Rules Editor , not ADSI Edit or the Azure AD Connect wizard, since the wizard doesn’t author custom attribute flows and ADSI Edit doesn’t manage sync rules.

In the Windows Server hybrid administration guidance for DNS, Microsoft describes that DNS zones stored in Active Directory can use application directory partitions to customize replication scope beyond the default domain- or forest-wide options. The study materials state that “custom application directory partitions allow DNS data to replicate only to the DNS servers that are explicitly enlisted in that partition.” They further emphasize that while DNS Manager lets you pick among built-in scopes or select an existing application parti tion, “creating a new application directory partition is performed with command-line tools (dnscmd) or Windows PowerShell.”

The documented procedure is: “Use dnscmd /CreateDirectoryPartition < FQDN-of-partition > to create the custom partition, then dnscmd /EnlistDirectoryPartition on each DNS server that should host and replicate the data.” Because you must have the partition replicate to only four of the domain controllers, you first create the partition, and then enlist only those four DNS servers. Tools such as Active Directory Sites and Services or Active Directory Administrative Center do not create DNS application directory partitions, and DNS Manager cannot create a new custom partition; it can only use an existing one. Therefore, the correct tool to meet the requirement is dnscmd.exe , after which you enlist just the selected four DNS servers into that partition.

The Hyper-V networking section of the Administering Windows Server Hybrid Core Infrastructure material explains that Hyper-V provides three virtual switch types: External, Internal, and Private . It states: “An External switch is bound to a physical NIC and can optionally connect the management OS; an Internal switch connects VM s to each other and to the host only; a Private switch connects VMs to each other only (no host access).” The guide further clarifies limits on external switches: “A single physical adapter can be bound to only one External virtual switch at a time (unless using NIC Teaming). Additional External switches require additional physical adapters.”

In the exhibit, Server1 has a single NIC already bound to vSwitch3 , and the tree shows ‘Microsoft Hyper-V Network Adapter’ , indicating the management OS shares the ada pter. Therefore, you cannot add another External switch with the lone NIC; you can still create Internal and Private switches.

Regarding host connectivity, the guide specifies: “The management OS can communicate with VMs attached to an Internal switch and to an External switch (when the management OS is connected). The host cannot communicate with VMs on a Private switch.” Consequently, Server1 can access network shares only from VMs on vSwitch2 (Internal) or vSwitch3 (External with management OS) , but not from VMs on vSwitch1 (Private) .

In the AZ-800 “Administering Windows Server Hybrid Core Infrastructure” objectives for Active Directory, server promotion is governed by forest/domain administrative roles. The materials state that promoting a member server to a domain controller in a given domain requires membership in either the Enterprise Admins group or the Domain Admins group of the target domain. The Configuration and Domain naming contexts that DCPromo touches (NTDS settings, SYSVOL/DFS-R readiness, DC computer account, and associated service SPNs) are protected so that “Enterprise Admins have full rights forest-wide, and Domain Admins have full rights within their respective domain.”

In this case, the requirement is to promote Server1 to a domain controller in canada.contoso.com. From the identities table:

Contoso\Admin1 is a member of Enterprise Admins (forest-wide authority).

Canada\Admin3 is a member of Canada\Domain Admins (authority within canada.contoso.com).

Contoso\Admin2 is Domain Admins (contoso.com) only, which does not grant administrative authority in the canada.contoso.com child domain.

Therefore, the users who can currently perform the required task for Server1 are Admin1 and Admin3.

The Windows Server Data Deduplication section of the Administering Windows Server Hybrid Core Infrastructure course explains that deduplicated volumes require the deduplication components on any system that needs to read them: “Data Deduplication is implemented as a filter driver. To access a deduplicated volume on another server, you m ust install the Data Deduplication role service; otherwise files may appear as reparse points and cannot be opened.” It also clarifies that “when the role is present, the system transparently rehydrates data on access without requiring a restore.” In your scenario, Disk2 was deduplicated on Server1 and is now attached to Server2. To regain immediate access to all files as quickly as possible, install the Data Deduplication role service on Server2 so the filter can interpret the chunk store and metadata and make the files readable instantly. Creating a storage pool is irrelevant because the disk already exists and is readable; FSRM does not interpret dedup data; and restoring from Azure Backup would be slower and unnecessary since the original deduplicated volume is intact. Hence, the fastest, correct action is to install Data Deduplication on Server2. https://docs.microsoft.com/en-us/windows-server/storage/data-deduplication/overview

The course content distinguishes site management from FSMO role administration . Active Directory Sites and Services is used to manage sites, subnets, site links, replication topology, and server objects (NTDS Settings), not domain or forest operations master roles. The documentation explains that FSMO roles are either forest-wide (Schema, Domain Naming) or domain-wide (RID, PDC, Infrastr ucture) and are exposed via ADUC (domain roles), Active Directory Domains and Trusts (Domain Naming), and Active Directory Schema (Schema) , or by command-line tools like NETDOM and NTDSUTIL . Right-clicking Default-First-Site-Name and opening Properties shows site-level configuration (e.g., inter-site transports, licensing, location metadata) but does not display FSMO role holders . Consequently, the proposed action does not meet the goal of identifying the PDC Emulator . To meet the goal, use ADUC → Operation s Masters , netdom query fsmo , or ntdsutil roles as laid out in the administration guide.

The DNS planning section of Administering Windows Server Hybrid Core Infrastructure states: “Private internal namespaces are not resolvable via Internet root hints. For resolution across internal DNS zones hosted on different servers, use zone delegation, stub zones, or conditional forwarders so that each server can reach the authoritative source.” In the scenario, Server1 hosts contoso.local , which already con tains delegations to east.contoso.local and west.contoso.local . However, Server2 (east) and Server3 (west) have no knowledge of the parent zone (contoso.local) and, because all servers use only root hints, queries for contoso.local from Server2/Server3 can not be resolved by recursion on the public roots. The proposed fix adds a conditional forwarder on Server2 for west.contoso.local and on Server3 for east.contoso.local , which enables cross-child resolution, but does not provide a path to resolve contoso.lo cal from Server2 or Server3. The guidelines further note: “To ensure all servers can resolve all internal namespaces, configure forwarders (or stub zones/secondaries) to the authoritative servers for each internal zone, including the parent zone.” Because the solution omits a forwarder (or stub/secondary) on Server2 and Server3 for contoso.local , it does not meet the goal.

The DNS chapters in Administering Windows Server Hybrid Core Infrastructure describe conditional forwarders as a way to direct queries for specific namespaces to authoritative DNS servers. The text notes: “A conditional forwarder forwards queries for a designated DNS domain to specified DNS servers,” which is used to “integrate split or private namespaces across sites or forests.” In this design, Server1 hosts contoso.local and delegates east and west to Server2 and Server3. By configuring Server2 and Server3 with a conditional forwarder for contoso.local pointing to Server1 , any query for contoso.local (including child names like east.contoso.local or west.contoso.local when not answered locally) is sent to Server1. Server1, being authoritative for the parent, uses the existing delegations to return referrals/answers from the proper child zones. For Internet hosts , all three server s already use root hints , which the course material confirms remains valid alongside conditional forwarding. The documentation also stresses that “authoritative data is answered locally first; forwarding applies only to names the server is not authoritativ e for,” so Server2 continues to answer east locally while leveraging Server1 to reach parent and sibling zones . This configuration ensures that all servers can resolve all internal namespaces and Internet hosts .

The remoting prerequisites in the AZ-800 curriculum state that WinRM/PowerShell remoting to a target computer is permitted for local Administrators and Remote Management Users on the target. The documentation notes: “Users who are members of the local Administrators group or Remote Management Users group on the destination can establish PowerShell remoting sessions.” In a domain, high-privilege domain administrative groups are, by default, granted local administrator rights on domain-joined servers. Applying this: User3 is in Server2\Administrators (local admin) → allowed. User4 is in Server2\Remote Management Users → allowed. User1 belongs to the domain Administrators group, which confers administrator privileges on domain-joined servers, enabling remoting to Server2. User2, however, is only in the domain “Remote Management Users” group, not the local group on Server2; domain membership alone does not grant the required local right. Therefore, the users who can open a PowerShell remoting session from Server1 to Server2 are User1, User3, and User4.