Free Practice Questions for Microsoft AZ-800 Exam

DHCP scopes: 3

DHCP relays: 2

In a Windows Server Hybrid Core Infrastructure, managing IP address assignment across multiple physical or virtual segments requires a combination of DHCP scopes and Relay Agents. A DHCP scope is a required administrative grouping of IP addresses for computers on a specific subnet that use the DHCP service. Since the network consists of three distinct IPv4 subnets (two client VLANs and one datacenter VLAN), you must create a minimum of three scopes to ensure each subnet is managed and provided with appropriate configuration options, such as default gateways and DNS servers specific to their segment. Even if the DHCP server resides in the datacenter VLAN, the scope for that subnet allows for the management of any other devices or future clients in that segment.

Regarding the distribution of these addresses, DHCP utilizes broadcast traffic (DHCPDISCOVER), which is restricted to the local Layer 2 broadcast domain (the VLAN). To allow the DHCP server in the datacenter to receive requests from the two remote client VLANs, a DHCP Relay Agent (or IP Helper) must be configured on the gateway or a local server within those segments. The minimum number of relays required is two, corresponding to the two client VLANs that do not host the DHCP server. The datacenter VLAN does not require a relay because the DHCP server is directly connected to that broadcast domain and can listen for local requests natively. This configuration adheres to the design principles of centralized DHCP management in a segmented enterprise environment.

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.

 File1 : Server1 and the Azure file share

 File3 : The Azure file share only

Azure File Sync cloud tiering manages local storage by bal ancing two specific policies: the Volume Free Space Policy and the Date Policy . According to the official documentation for Administering Windows Server Hybrid Core Infrastructure, the Volume Free Space policy is the primary governing factor for tiering de cisions.

Storage Calculations : Volume E is 500 GB . With a 30 percent free space requirement, the server must maintain 150 GB of free space ($500 \times 0.30 = 150$). This means only 350 GB ($500 - 150$) of file content can be cached locally on Server1.

Dat e Policy Application : The date policy is set to 70 days . Any file not accessed within this window is automatically tiered regardless of free space.

File4 (Last accessed 100 days ago) is older than 70 days, so it is tiered to The Azure file share only .

Volume Free Space Application : The remaining files (File1, File2, and File3) were all accessed within the last 70 days. Their total size is 500 GB ($200 + 100 + 200 = 500$). Since the maximum allowed local storage is 350 GB , Azure File Sync must tier addit ional files to satisfy the 30% free space requirement.

Tiering Priority : Files are tiered based on their " coldness " (last access time). File3 (60 days ago) is significantly older than File1 (2 days) and File2 (10 days). By tiering File3, the remaining loca l data (File1 + File2) totals 300 GB , which fits within the 350 GB limit.

Conclusion : Consequently, File1 remains cached on Server1 and the Azure file share , while File3 is tiered to The Azure file share only .

In Just Enough Administration (JEA), you restrict what remote users can do by publishing a PowerShell se ssion endpoint that references a session configuration file and one or more role capability files . The AZ-800 “Administering Windows Server Hybrid Core Infrastructure” materials explain that a JEA deployment follows this order: (1) create role capability f iles (.psrc) in a module’s RoleCapabilities folder to enumerate allowed cmdlets, functions, and parameters; (2) author a session configuration file (.pssc) —typically with New-PSSessionConfigurationFile —that maps users or groups to the role capabilities; an d (3) register the endpoint with Register-PSSessionConfiguration , supplying the .pssc path and a Name for the endpoint. Only after registration can helpdesk users connect to the constrained endpoint.

Critically, among the listed cmdlets, Register-PSSession Configuration is the one that accepts -Name and -Path to a .pssc file, which matches the prompt ( -Path .\hypervJeaConfig __ -Name ' hypervJeaHelpDesk ' -Force ). Enter-PSSession is for connecting to an already published endpoint, and New-PSSessionConfigurationFile creates the .pssc but does not publish it. Likewise, file types .ps1 (script), .psm1 (module), and .psrc (role capability) are not valid for the -Path parameter when registering an endpoint. Therefore, the correct completion is:

Register-PSSessionConfiguration -Path .\hypervJeaConfig.pssc -Name ' hypervJeaHelpDesk ' -Force .

In the AZ-800/“Administering Windows Server Hybrid Core Infrastructure” content, Azure AD Connect cloud sync uses a lightweight provisioning agent that reads from on-premises AD DS. The agent runs under a Group Managed Service Account (gMSA) so it can securely obtain and rotate credentials automatically. The implementation guidance states that during agent installation you provide domain admin credentials once so the installer can create and delegate a gMSA for the agent; alternatively, you can pre-create the gMSA and assign it. The documentation emphasizes that cloud sync does not rely on user or computer accounts with static passwords; instead it “deploys a gMSA for the agent service to ensure secure, automatic password management and least-privilege directory access.” System-assigned managed identities apply to Azure resources only (not on-prem AD DS), and InetOrgPerson is an object class for users, not a service identity. A regular user account would introduce password management and rotation issues and is not the recommended nor required identity type for the cloud sync agent. Therefore, to satisfy Azure AD Connect cloud sync prerequisites, you create and use a gMSA.

In Windows Admin Center (WAC), “gateway access” is controlled by the Allowed groups list on the gateway. The AZ-800 materials explain that membership in the local Administrators group on the WAC gateway still permits sign-in unless you explicitly scope access to specific groups in the Allowed groups list . The guidance further states that to restrict who can sign in to the WAC gateway, you must populate Allowed groups with one or more security groups (for example, a domain group) and remove broad principals (like BUILTIN\Users). Until you add at least one explicit group, existing administrators can continue to authenticate, which is why “everyone” appears able to sign in after only removing BUILTIN\Users. By adding a dedicated security group to Allowed groups, only members of that group can authenticate to the gateway UI; non-members are denied. Settings such as Performance profile or Require manage-as sessions to re-authenticate affect performance and remote management prompts, not gateway sign-in. Proxy bypass lists control outbound connectivity, not access control. Therefore, to prevent unauthorized sign-ins, configure Allowed groups with a specific security group and manage membership there.

 Disk1: NTFS only

 Disk2: NTFS or ReFS only

The Windows Server Hybrid Core Infrastructure objectives specify that disk (volume) quotas—the classic per-user/per-volume quota feature exposed in the volume’s properties—are a capability of NTFS. The guidance states that “NTFS supports user and volume quotas that can be configured per volume; ReFS does not implement the legacy NTFS disk-quota mechanism.” Therefore, to meet the requirement that Disk1 must support disk-level quotas, the volume must be formatted as NTFS.

For Data Deduplication, the storage module explains that Data Deduplication is a file-system feature available on modern Windows Server versions and that it is “supported on NTFS volumes and on ReFS volumes beginning with Windows Se rver 2019/2022 scenarios.” The same materials emphasize that exFAT doesn’t support Windows Server features such as quotas or dedup. Consequently, to satisfy the requirement that Disk2 must support Data Deduplication, you can format Disk2 as NTFS or ReFS; both file systems are valid for dedup workloads on current Windows Server releases, while exFAT is not.

Thus:

Disk1 → NTFS only (to enable disk-level quotas).

Disk2 → NTFS or ReFS only (to enable Data Deduplication).

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.