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

Membership in the Enterprise Admins group or the Domain Admins group in the forest root domain is required.

The Administering Windows Server Hybrid Core Infrastructure materials explain that group Managed Service Accounts (gMSAs) rely on the Key Distribution Service (KDS) to generate and distribute the managed password. Therefore, the first step in a new forest (or where no key exists yet) is to create a KDS root key: Add-KdsRootKey. The guide states that “the KDS root key is required once per forest before any gMSA can be created or used,” and without it, password material cannot be issued.

Next, you create the gMSA in Active Directory using New-ADServiceAccount. When creating the account, you specify the principals that are allowed to retrieve the managed password (for example, the computer account of Server1 or a group). The study content notes: “Use New-ADServiceAccount with -PrincipalsAllowedToRetrieveManagedPassword to authorize the host computers that will run the service.” This removes the need to separately run mapping cmdlets.

Finally, on the target server, you install the gMSA locally using Install-ADServiceAccount. The documentation emphasizes: “After the account is created in AD, the host computer must install the gMSA so the Local Security Authority can obtain and maintain the password automatically.”

Because authorization is granted at creation time, Add-ADComputerServiceAccount is not required in this minimal, correct sequence.

To ensure that all objects, specifically Computer1, can be used in Conditional Access (CA) policies, the environment must support device-based identity in the cloud. In a hybrid scenario, while user objects and security groups (like Group1 and Group2) can be synchronized through standard Azure AD Connect (Microsoft Entra Connect) synchronization cycles, computer objects require specific configuration to become "identifiable" by Conditional Access.

According to the official study guides for the AZ-800 exam, simply syncing a computer object does not make it a "Hybrid Azure AD joined" device. To enable Computer1 to be used as a target or a condition (e.g., "Require Hybrid Azure AD joined device") in a CA policy, you must run the Azure AD Connect wizard and select the Configure Hybrid Azure AD join task. This process configures a Service Connection Point (SCP) in your on-premises Active Directory, which allows Windows 10/11 devices like Computer1 to discover the Azure AD tenant and complete the registration process.

Furthermore, while group scopes (Universal vs. Domain Local) are often discussed in sync scenarios, Azure AD Connect by default synchronizes security groups regardless of their scope if they are within the synchronized Organizational Units (OUs). Therefore, the critical step to satisfy the requirement for "all objects"—especially the computer account—is enabling the Hybrid Join feature to establish a cloud-side device identity. This provides the necessary "device signal" that Conditional Access evaluates to grant or deny access.

In the AZ-800 materials on “Manage and maintain Windows Server IaaS virtual machines,” the Serial Console requirement is called out clearly: the VM must have Boot diagnostics enabled so Azure can capture the console and provide an interactive text console during boot and runtime. The guidance explains that enabling Boot diagnostics (either managed or with a storage account) stores the console output and screen shots that the Serial Console relies on. Guest-level diagnostics or a managed identity are not prerequisites for Serial Console access.

Access control to the Serial Console is governed by Azure RBAC. The study guidance states that users must be granted either Virtual Machine Contributor (broad rights) or the minimal login roles; for secure, least-privilege access to a console session with administrative rights, assign Virtual Machine Administrator Login to the user. This role allows interactive sign-in to the VM (RDP/SSH/Serial Console) without granting configuration permissions on the VM.

Therefore, to let user1@contoso.com use the Serial Console while meeting least-privilege objectives, enable Boot diagnostics on the VM (here, with a custom storage account, which satisfies the boot diagnostics requirement) and assign the Virtual Machine Administrator Login role to User1.

In Hyper-V, access to local devices such as a USB hard drive connected to the management computer (Server1) from within a VM session (VM1) is provided only when using Enhanced Session Mode through the Virtual Machine Connection (vmconnect) client. The AZ-800/“Administering Windows Server Hybrid Core Infrastructure” materials emphasize that Enhanced Session Mode “enables redirection of local resources (audio, clipboard, printers, drives, and supported Plug and Play devices) to a guest when connecting with Virtual Machine Connection.” To use it, you must first enable it on the host and then select the device in vmconnect before establishing the session.

Accordingly, you should:

Enable Enhanced Session on the host: In Hyper-V Manager → Host1 → Hyper-V Settings → Enhanced Session Mode Policy, select Allow enhanced session mode (and optionally Use enhanced session mode under User settings). This satisfies option A.

Choose the USB drive in the vmconnect UI: When launching the connection to VM1, click Show Options → Local Resources → More…, and select Drives or the specific USB device so it is redirected into the guest. This matches option D.

Options B and E relate to host Disk Management operations and do not provide guest redirection of a USB attached to Server1. Option C (“switch to a basic session”) explicitly disables the RDP-based redirection channel that Enhanced Session Mode relies upon, preventing USB/drive passthrough. Therefore, the correct pair is A and D.

The Administering Windows Server Hybrid Core Infrastructure materials for Azure File Sync explain that a cloud endpoint in a sync group must be an Azure file share and that “the storage account that contains the Azure file share must be in the same Azure region as the Storage Sync Service.” The guide also clarifies supported account types: “Azure File Sync supports Azure Files in general-purpose v2 (StorageV2) accounts for Standard performance and FileStorage accounts for Premium performance; BlockBlobStorage accounts are not supported for Azure Files.” Additionally, only storage accounts that contain Azure file shares can be selected for cloud endpoints; blob containers (used by Block Blob) are not applicable to Azure File Sync.

Applying these requirements to the table:

storage1 (East US, StorageV2) → valid region and account kind, and it has share1 (an Azure file share) → eligible.

storage3 (East US, FileStorage) → valid region and supported Premium account kind, with share3 → eligible.

storage2 (East US, BlockBlobStorage) → Block Blob only, no Azure Files share → ineligible.

storage4 (Central US, StorageV2) → has a file share but is not in the same region as the Storage Sync Service (Synd in East US) → ineligible.

Therefore, when creating the sync group in Synd (East US), you can use storage1 and storage3, and the only valid cloud endpoints you can specify are share1 and share3.

 Obtain and install a new certificate.

 Copy the certificate thumbprint.

 Run Windows Admin Center Setup and select Change.

According to the official study guides for Administering Windows Server Hybrid Core Infrastructure, maintaining the security of the Windows Admin Center (WAC) gateway is a critical administrative task, especially regarding SSL/TLS certificate management. When a certificate used by Windows Admin Center expires or needs to be replaced, the process follows a specific sequence to ensure service continuity and secure connectivity.

First, you must obtain and install a new certificate from a trusted Certificate Authority (CA). The certificate must be installed into the local machine's certificate store on the server where Windows Admin Center is running. Once installed, you must copy the certificate thumbprint. The thumbprint is a unique hexadecimal string that identifies the specific certificate; it is required by the WAC installer to bind the gateway service to the correct cryptographic object.

Finally, you must run Windows Admin Center Setup and select Change. Unlike standard web applications managed through Internet Information Services (IIS), Windows Admin Center uses its own specialized installer logic to handle port bindings and certificate associations. By selecting the "Change" option in the setup wizard (accessible via Add/Remove Programs or the original .msi file), the administrator is prompted to enter the new certificate thumbprint. The installer then updates the HTTPS listener configuration to use the new certificate. Note that "Repair" or "Remove" are incorrect as they do not allow for the reconfiguration of the certificate binding, and WAC does not typically use the standard IIS Manager for its core gateway service binding.

ProcessA: All the containers and Server1

ProcessB: Container3 and Server1 only

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

Understanding the visibility of processes within Windows Server containers depends entirely on the isolation mode used: Windows Server isolation (Process isolation) or Hyper-V isolation. According to official documents for Administering Windows Server Hybrid Core Infrastructure, these two modes determine how the container's kernel and processes interact with the host system.

Windows Server Isolation (Process Isolation): In this mode, containers share the same kernel as the host. Processes running inside the container are essentially standard processes on the host, albeit isolated through namespaces and resource controls. Consequently, a process running in a process-isolated container (like Container1 and Container2 in the exhibit) is visible from the host's Task Manager or Get-Process command, as well as from other containers sharing the same host kernel. Therefore, ProcessA can be verified as running from All the containers and Server1.

Hyper-V Isolation: This mode provides a more secure and isolated environment by running each container inside its own highly optimized virtual machine (utility VM). Because each container has its own private kernel, the host cannot "see" the internal processes of the container, and containers cannot see into each other. Container3 uses Hyper-V isolation. Therefore, ProcessC is only visible to the internal operating system of Container3 and, at a management level, to Server1 (the host). It is invisible to other containers (Container1, 2, and 4) because they are separated by kernel-level boundaries. Thus, you can verify ProcessC on Container3 and Server1 only.

The domain services security section describes the RODC Filtered Attribute Set (FAS), which prevents selected attributes from replicating to Read-Only Domain Controllers. The curriculum explains: “Attributes that must not be exposed on RODCs are added to the RODC filtered attribute set. This setting is defined in the schema partition; once an attribute is flagged as CONFIDENTIAL and added to FAS, it is not replicated to any RODC.” Because the attacker may have compromised RODC1’s computer account, protection requires ensuring sensitive attributes (e.g., employeeNumber) are never present on that RODC. Changes for FAS membership and the confidential bit are schema-level operations and apply forest-wide. Modifying the domain or configuration partitions will not change which attributes replicate to RODCs, and the global catalog is not a writable partition; it aggregates a subset of attributes but honors the schema’s FAS configuration. Therefore, to ensure Employee-Number cannot be viewed if RODC1 is compromised, you modify the schema to place the attribute in the RODC filtered attribute set (and, if required, mark it confidential).