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

In the Windows Server Data Deduplication guidance used for Administering Windows Server Hybrid Core In frastructure , the jobs are defined as follows: *“Optimization processes eligible files and chunks them for deduplication; Garbage Collection * reclaims disk space by removing unreferenced chunks that remain after files are modified or deleted ; Scrubbing validates data integrity and repairs corrupt chunks when possible.” The objective in this scenario is to minimize space consumed by files that were recently modified or deleted . That is precisely what the Garbage Collection job is designed to do. The study content also notes: “Use Set-DedupSchedule to create or tune Optimization, GarbageCollection, and Scrubbing schedules for a volume. GarbageCollection runs to purge orphaned chunks and free capacity.” In contrast, the Optimization job would only deduplicat e eligible files and won’t reclaim space already orphaned by changes/deletions, and Scrubbing focuses on integrity, not capacity recovery. Settings such as InputOutputScale (on Set-DedupVolume ) tune performance/IO behavior and don’t target space recovery f rom modified/deleted data. Therefore, to achieve the stated goal on drive D:, configure a GarbageCollection schedule with Set-DedupSchedule .

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.

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.

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 .

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 .

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 AZ-800 materials explain that enabling Microsoft Entra (Azure AD) sign-in to Windows Server running as an Azure VM is done by deploying the Azure AD Login for Windows VM extension. The study guide states that “for Azure VMs, Microsoft Entra sign-in is enabled by installing the AADLoginForWindows extension; once installed, Entra users and groups granted ‘Virtual Machine User/Login’ roles can sign in using Entra credentials.” The required operation is performed from Azure PowerShell with Set-AzVMExtension , providing the publisher Mic rosoft.Azure.ActiveDirectory , type AADLoginForWindows , and the target VM. Other options are not applicable: Set-AzVM changes VM properties but does not install extensions; New-ADComputer and Add-ADComputerServiceAccount are AD DS cmdlets unrelated to enabling Entra login on an Azure VM. Therefore, to meet the plan “Enable Microsoft Entra users to sign in to Server1,” you must run Set-AzVMExtension to install the AAD Login extension on Server1.

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.

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.

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 .

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 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.

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.

In the Administering Windows Server Hybrid Core Infrastructure materials for managing hybrid servers with Azure Arc, Microsoft describes two primary, supported ways to deliver Desired State Configuration at scale: Azur e Automation State Configuration and Azure Policy Guest Configuration . For large fleets of Arc-enabled servers, the guidance emphasizes that Guest Configuration uses DSC resources and content that is packaged and then assigned by Azure Policy , removing the need to stand up or manage a pull server. The study content explains that Guest Configuration “ audits and (with remediation) configures the inside of machines using DSC resources ” and that you deliver it by creating or using a policy definition that refer ences your guest configuration package , so compliance and remediation happen through policy assignment. This approach is highlighted as the lowest-overhead method for Arc servers because policy assignments can be targeted to subscriptions, resource groups, or Arc-enabled machines , providing uniform roll-out and governance with minimal administration.

The same materials note that Automation State Configuration requires onboarding nodes to an Automation account and managing configurations there , which adds ex tra setup for non-Azure VMs. In contrast, with Arc + Guest Configuration, the DSC content is stored/referenced in the Azure Policy definition and enforced by the Guest Configuration extension , enabling you to apply and remediate configurations at scale wit h Azure Policy , which best meets the requirement to minimize administrative effort across 500 Arc-enabled Windows Server machines joined to the on-premises domain.

Microsoft Entra Connect (Azure AD Connect) reads the on-premises AD DS schema to determine which attributes are available for synchronization. The hybrid administrator guidance states that after extending AD with new/custom attributes, you must refresh the directory schema in Entra Connect so the sync engine recognizes the new attributes; only then can you include them in the synchronization rules (“Customize synchronization options”) for export to Microsoft Entra ID. Until a schema refresh occurs, queries from Azure (e.g., via Cloud Shell) will not surface those attributes because the connector does not know about them. Thus, the first step is to run “Refresh directory schema” in Microsoft Entra Connect; afterwards you can map/select the custom attributes in the sync rules and verify they flow to Microsoft Entra ID.

The Windows Server Hybrid Core Infrastructure materials explain that Windows Hello for Business (WHfB) in a hybrid environment relies on Azure AD registration and corresponding device objects in on-premises AD DS. Azure AD Connect provides the Device writeback optional feature, which “writes Azure AD device objects back to AD DS as msDS-Device objects so on-premises domain controllers and policies can recognize and evaluate the device during authentication.” The guide further notes that for hybrid-joined Windows 10/11 devices, enabling Device writeback “allows on-premises authentication stacks and Conditional Access decisions to use the registered device and its key material (key trust or certificate trust), enabling WHfB sign-in on domain-joined devices.” Other options do not meet the requirement: Password writeback is used for self-service password reset, Group writeback returns Microsoft 365 groups to AD DS, and Directory extension attribute sync simply synchronizes custom attributes. Therefore, to ensure users can sign in with Windows Hello for Business on Azure AD hybrid-joined devices, select Device writeback in Azure AD Connect.

The exam materials explain that to add a new domain controller to an existing AD DS forest in Azure, you deploy a Windows Server IaaS VM and then promote it: “To extend on-premises AD DS into Azure, provision a Windows Server VM in Azure and run AD DS to create an additional domain controll er for the existing domain.” Conversely, Azure Active Directory Domain Services (Azure AD DS) provides a managed domain that is separate from and not writable by your on-premises administrators —you “do not get domain admin rights or access to DCs” —so it cannot be used to add a DC (dc3.corp.fabrikam.com) to the existing corp.fabrikam.com forest. Azure AD Application Proxy and Azure AD administrative units are unrelated to deploying DCs. Therefore, the correct implementation is to deploy an Azure virtual machine in Vnet1, install AD DS/DNS, and promote it to become DC3 in the existing domain.

In the Administering Windows Server Hybrid Core Infrastructure guidance for extending AD DS into Azure, Microsoft states that when you place a domain controller in an Azure virtual network you must run DNS on that domain controller and point the VNet to that DNS server: “Domain controllers in Azure IaaS should host the AD-integrated DNS zone, and the virtual network’s DNS server setting must reference those DC/DNS IPs so Azure VMs use AD DNS rat her than the Azure-provided resolver.” The materials also emphasize that Azure’s default DNS cannot host or manage AD DS zones, so custom DNS is required for domain-joined workloads. Therefore, to meet the requirement you (1) install the DNS Server role on DC3 so it can host the corp.fabrikam.com AD-integrated zone (F), and (2) configure the DNS Servers setting on Vnet1 to the IP of DC3 (and any additional DCs), ensuring all Azure VMs in Vnet1 resolve the domain via AD DNS (D). Creating a public Azure DNS zone or a Private DNS zone with the same AD name is not appropriate for AD-integrated name resolution. This design also supports the security requirement of preventing domain controllers from relying on Internet-facing resolvers.

The exam content for Group Policy processing stresses User Group Policy loopback processing for session hosts (RDS/AVD): “In environments like Remote Desktop Session Host (or Azure Virtual Desktop), enable loopback processing on the OU that contains the session host computers so that user settings from that GPO apply when users log on to those computers, regardless of the user’s own OU.” The requirement states: “Apply GPO4 to the Azure Virtual Desktop session hosts. Ensure that Azure Virtual D esktop user sessions lock after being idle for 10 minutes. Users must be able to control the lockout time manually from their client computer.” The idle-lock is a user configuration setting that must apply when users sign in to the session hosts, not to their personal devices. Therefore, enable loopback processing (Merge/Replace) in GPO4, which is linked to the VirtualDesktops OU containing the session hosts. Using security filtering or Enforced cannot make user settings in GPO4 override the user’s own OU without loopback. Loopback ensures the AVD hosts impose the 10-minute lock for sessions, while leaving users free to set their own client device policies independently—fulfilling least-impact design.

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 Azure File Sync architecture (covered in Admin istering Windows Server Hybrid Core Infrastructure under “Implement and manage storage solutions”), the fundamental design points are:

Sync group – “A sync group defines a sync topology. Each sync group contains exactly one cloud endpoint (an Azure file sh are) and one or more server endpoints.” A server endpoint is a folder on a registered Windows Server. A server can participate in multiple sync groups so long as the server endpoints are different paths.

Storage Sync Service – “The Storage Sync Service is the top-level resource that maintains server registrations and houses your sync groups.” A Windows Server registers to one Storage Sync Service at a time, and that service can contain many sync groups and many servers.

Applying these rules to the requirement:

You have three Azure file shares: newyorkfiles, seattlefiles, and companyfiles. Because each sync group maps to one cloud endpoint, you need one sync group per share ⇒ 3 sync groups.

FS1 must sync with newyorkfiles and companyfiles; FS2 must sync with seattlefiles and companyfiles. Since one Storage Sync Service can host multiple sync groups and multiple servers, and a server must be registered to a single service, the most efficient design is a single Storage Sync Service containing all three sync groups and both servers.

The exam materials for Administering Windows Server Hybrid Core Infrastructure explain that when replacing private WAN links with Azure, Azure Virtual WAN (vWAN) can be used to centralize connectivity. For private connectivity, ExpressRoute integrates directly with a vWAN hub by deploying an ExpressRoute gateway in the hub. The gateway is the Azure resource that terminates ExpressRoute and enables hub-and-spoke routing to connected VNets (such as Vnet1 ). The guides emphasize: “ In a Virtual WAN hub, use the ExpressRoute gateway to connect ExpressRoute circuits and propagate routes acro ss the hub to your virtual networks .”

On-premises, each site (New York and Seattle) requires an ExpressRoute circuit connection provisioned via a connectivity provider. The circuit is the dedicated private connection from the customer edge to Microsoft’s edge and is what the office sites actually use; it’s then linked to the vWAN hub’s ExpressRoute gateway. The same materials note that Site-to-Site VPN is an alternative transport but is not required when ExpressRoute is mandated. Likewise, Application Gateway is a Layer-7 load balancer for HTTP/S traffic, and on-premises data gateway relates to Power BI/Power Platform hybrid connectivity, neither of which establishes network transport between offices and Azure.

Therefore, to meet the requirement “connect both on-premises offices to Vnet1 by using ExpressRoute,” configure an ExpressRoute gateway on the vWAN hub and ExpressRoute circuit connections in the offices.

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.

TASK 3

???? Objective:

Create a user named Admin 1 in contoso.com.

Admin1 must be able to back up and restore files on SRV1.

Follow the principle of least privilege.

Step-by-Step Guide

✅ Step 1: Create the User Account

Log in to a Domain Controller (e.g., DC1) with appropriate admin rights.

Open Active Directory Users and Computers (dsa.msc).

In the contoso.com domain:

Right-click the Users container or another OU where you want to create the account.

Select New > User.

Enter the following:

First name: Admin1

User logon name: Admin1

Click Next and set a password (ensure it meets the domain’s password policy).

Configure password options (e.g., User must change password at next logon, if required).

Click Finish.

✅ Step 2: Grant Backup and Restore Rights on SRV1

By default, Backup Operators have the abili ty to back up and restore files (without giving full admin rights).

Log in to SRV1 (the target server).

Open Computer Management (compmgmt.msc).

In the left pane, expand:

System Tools > Local Users and Groups > Groups.

Find and double-click the Backup Oper ators group.

Click Add.

In the Select Users, Computers, Service Accounts, or Groups window:

Type Admin1.

Click Check Names to resolve the user.

Click OK to add Admin1 to the group.

Click OK again to close the Backup Operators group properties.

✅ Step 3: Verify Access

Log in as Admin1 on SRV1 and test performing backup and restore operations using tools like Windows Server Backup.

Since Backup Operators can back up and restore data but do not have full administrative privileges, this follows the least priv ilege principle.

✅ Additional Notes

If you prefer using PowerShell, you can add the user to the group like this on SRV1:

Add-LocalGroupMember -Group " Backup Operators " -Member " contoso\Admin1 "

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.

One possible solution to ensure that the Azure file share named share1 can sync to on-premises servers is to use Azure File Sync. Azure File Sync allows you to centralize your file shares in Azure Files without giving up the flexibilit y, performance, and compatibility of an on-premises file server. It does this by transforming your Windows Servers into a quick cache of your Azure file share. You can use any protocol available on Windows Server to access your data locally (including SMB, NFS, and FTPS) and you can have as many caches as you need across the world1.

Here are the steps to configure Azure File Sync for the Azure file share named share1 and the source files located in a folder named \dc1.contoso.com\install:

On the Azure porta l, create a Storage Sync Service in the same region as your storage account that contains the Azure file share named share1. For more information on how to create a Storage Sync Service, see How to deploy Azure File Sync.

On the on-premises server that hos ts the folder named \dc1.contoso.com\install, install the Azure File Sync agent. For more information on how to install the Azure File Sync agent, see Install the Azure File Sync agent.

On the on-premises server, register the server with the Storage Sync S ervice that you created in the first step. For more information on how to register a server with a Storage Sync Service, see Register/unregister a server with Storage Sync Service.

On the Azure portal, create a sync group that defines the sync topology for a set of files. In the sync group, select the Azure file share named share1 as the cloud endpoint and the folder named \dc1.contoso.com\install as the server endpoint. For more information on how to create a sync group, see Create a sync group and a cloud endpoint and Create a server endpoint.

Wait for the initial sync to complete. You can monitor the sync progress on the Azure portal or on the on-premises server. For more information on how to monitor sync progress, see [Monitor sync progress].

Once the i nitial sync is complete, you can add more on-premises servers to the same sync group to sync and cache the content locally. You can also enable cloud tiering to optimize the storage space on the on-premises servers by tiering infrequently accessed or older files to Azure Files.

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).

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.

One possible solution to ensure that all DHCP clients that get an IP address from SRV1 will be configured to use DC1 as a DNS server is to use the DHCP scope options. DHCP scope options are settings that apply to all DHCP clients that obtain an IP address from a specific scope. You can use the DHCP scope options to specify the DNS server IP address, as well as other parameters such as the default gat eway, the domain name, and the DNS suffix. Here are the steps to configure the DHCP scope options on SRV1:

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 c lick on IPv4.

In the right pane, right-click on the scope that you want to configure and select Properties.

In the Scope Properties dialog box, click on the DNS tab.

Check the box Enable DNS dynamic updates according to the settings below. This option allows the DHCP server to register and update the DNS records for the DHCP clients.

Select the option Always dynamically update DNS records. This option ensures that the DHCP server updates both the A and PTR records for the DHCP clients, regardless of whe ther they request or support dynamic updates.

Check the box Discard A and PTR records when lease is deleted. This option allows the DHCP server to delete the DNS records for the DHCP clients when their leases expire or are released.

Check the box Dynamical ly update DNS records for DHCP clients that do not request updates. This option allows the DHCP server to update the DNS records for the DHCP clients that do not support dynamic updates, such as legacy or non-Windows clients.

In the DNS servers section, cl ick on the Add button to add a new DNS server IP address.

In the Add Server dialog box, enter the IP address of DC1, which is the DNS server that you want to use for the DHCP clients, and click Add.

Click OK to close the Add Server dialog box and return to the Scope Properties dialog box.

Click OK to apply the changes and close the Scope Properties dialog box.

Now, all DHCP clients that get an IP address from SRV1 will be configured to use DC1 as a DNS server. You can verify the DNS configuration by using t he ipconfig /all command on a DHCP client computer and checking the DNS Servers entry. You can also check the DNS records for the DHCP clients by using the DNS Manager console on DC1.

TASK 7

???? Objective:

Attach the VHDX file c:\vhds\Disk1.vhdx to VM1 so it can dynamically expand when VM1 is running.

Step-by-Step Guide

✅ Step 1: Verify the VHDX File Type

Dynamic expansion means the virtual disk type should be dynamic (not fixed).

Let’s verify the disk type of Disk1.vhdx:

powershell

Copy

Get-VHD -Path " c:\vhds\Disk1.vhdx "

In the output, ensur e that VhdType shows Dynamic.

If it’s not dynamic, convert it:

powershell

Copy

Convert-VHD -Path " c:\vhds\Disk1.vhdx " -DestinationPath " c:\vhds\Disk1_dynamic.vhdx " -VHDType Dynamic

✅ Step 2: Attach the VHDX to VM1

Use PowerShell to add the disk to VM1:

p owershell

Copy

Add-VMHardDiskDrive -VMName " VM1 " -Path " c:\vhds\Disk1.vhdx "

✅ Or do it via Hyper-V Manager:

Open Hyper-V Manager.

Select VM1 and go to Settings.

In the left pane, select SCSI Controller (recommended for hot-add).

Click Add Hard Drive.

Browse and select c:\vhds\Disk1.vhdx.

Click Apply and OK.

✅ Step 3: Verify Hot-Add Support (Optional)

If VM1 is running Windows Server 2012 or later and uses a SCSI Controller, the VHDX can be added without shutting down the VM.

✅ Step 4: Verify the Di sk in the VM

Inside VM1, open Disk Management (diskmgmt.msc).

The newly attached disk should appear as unallocated.

Initialize it, create a volume, and format if needed.

Summary

VHDX file type: Must be dynamic for expanding.

Hot-adding supported if attached via SCSI Controller and OS supports it.

Now Disk1.vhdx is attached to VM1 and can expand dynamically.

Explore

To create a container image named app1 for your application using the Dockerfile in the C:\app directory on SRV1, follow these steps:

Step 1: Open PowerShell or Command Prompt First, open PowerShell or Command Prompt on SRV1.

Step 2: Navigate to the Application Directory Change to the directory where your application and Dockerfile are located:

cd C:\app

Step 3: Build the Container Image Use the docker build command to create the container image. The -t flag tags the image with the name app1:

docker build -t app1 .

The period . at the end of the command tells Docker to use the Dockerfile in the current directo ry.

Step 4: Verify the Image Creation After the build process completes, verify that the image app1 has been created successfully by listing all images:

docker images

You should see app1 in the list of images.

Step 5: Use the Image Now, you can use the ima ge app1 to run containers or push it to a container registry if needed.

By following these steps, you’ll have created a Docker container image named app1 using the Dockerfile located in C:\app on SRV11. Ensure that Docker is installed on SRV1 and that you have the necessary permissions to execute these commands.

Objective:

Grant permissions to the BranchAdmins group to manage the fabikam.com DNS zone on DC1.

Step-by-Step Guide

✅ Step 1: Log in to the DNS Server

Log in to DC1 (which hosts the DNS zone fabikam.com) using an account with Domain Admin or Enterprise Admin rights.

✅ Step 2: Open the DNS Manager

Open DNS Manager:

Press Windows + R, type dnsmgmt.msc, and hit Ent er.

✅ Step 3: Locate the Zone

In the DNS Manager, expand the Forward Lookup Zones.

Locate and right-click on the zone fabikam.com.

✅ Step 4: Open Zone Properties

Right-click on fabikam.com and select Properties.

In the Properties window, go to the Secu rity tab.

✅ Step 5: Grant Permissions

In the Security tab, click Add.

Enter the name of the group:

nginx

Copy

BranchAdmins

Click Check Names to resolve the group.

Click OK.

✅ Step 6: Assign the Appropriate Permissions

In the Permissions window, select the BranchAdmins group.

Assign the following permissions:

Read

Write

Create All Child Objects

Delete All Child Objects

Optionally, click Advanced for more granular control if needed.

✅ Step 7: Apply and Close

Click Apply and OK to save the changes.

To configure the domain to support the creation of gMSAs, you need to perform the following steps:

On a domain controller or a computer that has the Remote Server Administration To ols (RSAT) installed, open PowerShell as an administrator and run the following command to install the Active Directory module:

Install-WindowsFeature -Name RSAT-AD-PowerShell

Run the following command to create a Key Distribution Service (KDS) root key, w hich is required for generating passwords for gMSAs. You only need to do this once per domain:

Add-KdsRootKey -EffectiveImmediately

Wait for at least 10 hours for the KDS root key to replicate to all domain controllers in the domain. Alternatively, you can use the -EffectiveTime parameter to specify a past date and time for the KDS root key, but this is not recommended for security reasons. For more information, see Add-KdsRootKey.

After the KDS root key is replicated, you can create and configure gMSAs usi ng the New-ADServiceAccount and Set-ADServiceAccount cmdlets. For more information, see Create a gMSA and Configure a gMSA.

TASK 5

???? Objective:

Configure a Group Policy Preference to create a shortcut to \\srvi.contoso.com\data on the desktop of users in the Server Admins OU.

Step-by-Step Guide: Using Group Policy Preferences to Create a Desktop Shortcut

✅ Step 1: Open Group Policy Management Console (GPMC)

Log in to a DC or a management computer with RSAT installed.

Open Grou p Policy Management (gpmc.msc).

✅ Step 2: Create a New GPO

In the GPMC console, expand the forest and the domain (e.g., contoso.com).

Right-click the OU named Server Admins and select Create a GPO in this domain, and Link it here.

Name the GPO, e.g., Desktop Shortcut for Server Admins.

✅ Step 3: Edit the GPO

Right-click the newly created GPO and select Edit.

This opens the Group Policy Management Editor.

✅ Step 4: Navigate to User Preferences

In the editor, expand:

User Configuration > Preferences > Windows Settings > Shortcuts.

✅ Step 5: Create the Shortcut

Right-click Shortcuts and select New > Shortcut.

In the New Shortcut Properties window:

Action: Create

Name: Data Folder

Target Type: File System Object

Location: Desktop

Target Path: \\srvi.c ontoso.com\data

Optionally, set an icon or description if you want.

✅ Step 6: Configure Item-Level Targeting (Optional)

If you want to limit this shortcut strictly to specific users/groups, click the Common tab.

Check Item-level targeting and configure c onditions (optional).

For this scenario, linking the GPO to the Server Admins OU is usually sufficient.

✅ Step 7: Close and Update

Close the editor.

In GPMC, ensure the GPO is linked to the Server Admins OU.

Force a Group Policy Update on client computers:

On a client computer:

gpupdate /force

Or wait for the next Group Policy refresh cycle.

✅ Step 8: Verify

Log in as a user in the Server Admins OU.

The shortcut to \\srvi.contoso.com\data should appear on the desktop.