Free AZ-800 Practice Test Questions and Answers (2026)

To enable Microsoft Entra users to sign in to a Windows Server Azure virtual machine (VM), you must install the AADLoginForWindows VM extension. The Set-AzVMExtension PowerShell cmdlet is the correct tool for adding or updating extensions on an Azure VM. By specifying the correct publisher, type, and name for the Microsoft Entra login extension, this cmdlet configures the server to authenticate users against Microsoft Entra ID, thereby fulfilling the requirement.

A. Add-ADComputerServiceAccount: This cmdlet is for managing service accounts within an on-premises Active Directory Domain Services (AD DS) environment, not for configuring Microsoft Entra authentication on a server.

B. Set-AzVM: This cmdlet modifies the core properties of an Azure VM, such as its size or attached disks. It does not install or manage VM extensions, which are required for this functionality.

D. New-ADComputer: This cmdlet creates a new computer object in an on-premises Active Directory domain. It is irrelevant to configuring authentication methods on an existing server.

1. Microsoft Learn

Log in to a Windows virtual machine in Azure by using Microsoft Entra ID. This official documentation explicitly provides the PowerShell command to enable this feature.

Reference: Under the section "Enable Microsoft Entra login in for Windows Server 2019 or later

" the "Azure PowerShell" tab shows the exact command: Set-AzVMExtension -ResourceGroupName -VMName -Name "AADLoginForWindows" ...

2. Microsoft Learn

Set-AzVMExtension (Az.Compute). This is the official cmdlet reference page

which describes its purpose.

Reference: The "Description" section states

"The Set-AzVMExtension cmdlet adds a virtual machine extension to a virtual machine or updates an existing virtual machine extension." This confirms its role in managing extensions like the one required for Entra login.

Switch Embedded Teaming (SET) is a NIC Teaming feature integrated into the Hyper-V Virtual Switch on Windows Server 2016 and later. It is the only teaming technology that supports advanced Hyper-V networking performance features, including Dynamic Virtual Machine Multi-Queue (d.VMMQ). d.VMMQ optimizes network throughput for virtual machines by dynamically allocating traffic processing to host CPUs. The legacy Load Balancing and Failover (LBFO) teaming technology is not compatible with the Hyper-V Virtual Switch features required for d.VMMQ. Therefore, to meet the requirement, you must use SET.

A. Static teaming mode: This is a configuration mode for link aggregation that requires manual switch configuration. It is not the underlying teaming technology and does not itself enable d.VMMQ support.

C. load balancing and failover (LBFO): This is the legacy NIC teaming technology. It is not integrated with the Hyper-V Virtual Switch and does not support advanced features like d.VMMQ, SR-IOV, or RDMA teaming.

D. LACP teaming mode: Link Aggregation Control Protocol (LACP) is a dynamic configuration mode for link aggregation. Like Static mode, it is a mode within a teaming technology, not the technology itself that enables d.VMMQ.

1. Microsoft Learn. (2023). What's new in networking in Windows Server. "Dynamic Virtual Machine Multi-Queue (d.VMMQ)". This document states

"d.VMMQ requires the Switch Embedded Teaming (SET) feature that is also new in the Windows Server 2019 release."

2. Microsoft Learn. (2023). Switch Embedded Teaming (SET). "SET Functionality". This document details the features of SET

which is the foundation for advanced Hyper-V networking capabilities like VMMQ and its dynamic version

d.VMMQ. It notes

"Switch Embedded Teaming (SET) is an alternative NIC Teaming solution that you can use in environments that include Hyper-V and the Software Defined Networking (SDN) stack".

3. Microsoft Learn. (2023). Remote Direct Memory Access (RDMA) and Switch Embedded Teaming (SET). "NIC Teaming". This page explicitly contrasts SET with the older LBFO technology

stating

"The other teaming solution

Windows Server NIC Teaming (LBFO)

does not support teaming RDMA NICs." This illustrates that advanced networking features are exclusive to SET.

The scenario describes a classic "double-hop" authentication problem. The user authenticates from Server1 to Server2 (the first hop), but the credentials are not forwarded from Server2 to access resources on Server3 (the second hop). This is a security feature to prevent credential exposure.

Kerberos constrained delegation (KCD) is the standard and most secure mechanism to resolve this issue. By configuring KCD, you explicitly grant Server2 permission to impersonate the user and present their delegated credentials to specific services on Server3. This allows the command running on Server2 to authenticate to Server3 as the original user, resolving the access denied error with minimal and targeted administrative effort.

B. Configure Just Enough Administration (JEA).

JEA is a security technology used to limit administrative capabilities to the bare minimum required for a role; it does not solve the double-hop credential delegation problem.

C. Configure selective authentication for the domain.

Selective authentication is a security setting applied to forest trusts to control which users from a trusted forest can authenticate. This scenario involves a single domain, not a forest trust.

D. Disable the Enforce user logon restrictions policy setting for the domain.

This policy setting relates to enforcing user logon hours. It has no impact on how credentials are delegated between servers in a multi-hop scenario.

1. Microsoft Learn. (2023). Making the second hop in PowerShell Remoting. "The Double-Hop Problem... By default

your credentials can only be passed to one remote machine... To make the 'second hop'

you need to enable a credential-forwarding technology... The most secure way to do this is with Kerberos constrained delegation."

Reference: Section "The Double-Hop Problem" and "Kerberos Delegation".

2. Microsoft Learn. (2023). Kerberos Constrained Delegation overview. "Kerberos constrained delegation was introduced in Windows Server 2003 to provide a safer form of delegation that could be used by services. When it's configured

constrained delegation restricts the services to which the specified server can act on behalf of a user."

Reference: "Introduction" section.

3. Microsoft Learn. (2023). Just Enough Administration. "Just Enough Administration (JEA) is a security technology that enables delegated administration for anything that can be managed with PowerShell. With JEA

you can reduce the number of administrators on your machines and improve your security posture."

Reference: "What is JEA?" section.

4. Microsoft Learn. (2023). Security settings for trust relationships. "Selective authentication over a forest trust restricts access to resources in a trusting domain to only those users in a trusted domain who have been explicitly given authentication permissions to the computers in the trusting domain."

Reference: "Selective authentication" section.

The built-in Backup Operators group is a domain-local security group. Its permissions are scoped to the domain in which it exists. When a user is added to this group, they are granted the "Back up files and directories" and "Restore files and directories" user rights on all domain controllers and member servers within that specific domain.

In this scenario, User1 is added to the Backup Operators group in the contoso.com domain. Therefore, User1 gains backup rights only on the computers within the contoso.com domain, which are DC1 (a domain controller) and Server1 (a member server). The permissions do not extend to the child domain east.contoso.com, so User1 cannot back up DC2 or Server2.

A. DC1 only: This is incorrect. The rights granted to the Backup Operators group apply to all member servers within the domain, not just domain controllers.

B. Server1 only: This is incorrect. The rights granted to the Backup Operators group also apply to all domain controllers within the domain.

C. DC1 and DC2 only: This is incorrect. The permissions of the contoso.com Backup Operators group do not extend to the east.contoso.com domain where DC2 is located.

E. DC1, DC2, Server1, and Server2: This is incorrect. The group's permissions are limited to the contoso.com domain and do not apply to any servers in the east.contoso.com domain.

1. Microsoft Learn

"Active Directory security groups": This document describes the default security groups in Active Directory. For the Backup Operators group

it states

"Members can back up and restore files on a computer

regardless of the permissions that protect those files." The context of these built-in groups is that their scope is the domain in which they are created.

Reference: Microsoft Learn. (n.d.). Active Directory security groups. Retrieved from https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups#backup-operators

Section: "Default security groups"

Subsection: "Backup Operators".

2. Microsoft Learn

"Back up files and directories": This document details the "Back up files and directories" user right (SeBackupPrivilege). It specifies the default security settings for this right on different Windows Server versions. For domain controllers

this right is assigned by default to the Administrators and Backup Operators groups via the Default Domain Controllers Policy

which is linked to the Domain Controllers OU within its own domain.

Reference: Microsoft Learn. (n.d.). Back up files and directories. Retrieved from https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/back-up-files-and-directories

Section: "Default values".

3. Microsoft Learn

"Default local groups": This article explains the purpose of default groups. While it discusses local groups

it clarifies their role within an Active Directory domain. The Backup Operators group in the Builtin container of a domain grants rights on computers within that domain.

Reference: Microsoft Learn. (n.d.). Default local groups. Retrieved from https://learn.microsoft.com/en-us/windows/security/identity-protection/access-control/default-local-groups

Section: "Backup Operators".

Fine-grained password policies (Password Settings Objects, PSOs) are the only mechanism that can override the Default Domain password policy for individual users. When several PSOs apply, the one whose msDS-PasswordSettingsPrecedence attribute has the lowest numeric value is selected.

User1 belongs to Group1, which is linked to a PSO that requires a 7-character minimum password and has the lowest precedence among all policies shown. Although OU-level Group Policy objects or the Default Domain Policy define longer minimum lengths, they are ignored once a PSO with higher (i.e., lower-numbered) precedence applies. Therefore, when User1 changes the password, the enforced minimum length is 7 characters.

B. 8 – Defined in another PSO/GPO whose precedence value is higher, so it is overridden by the 7-character PSO.

C. 10 – Same; different PSO with higher precedence value, therefore not applied.

D. 12 – Minimum length in the Default Domain Policy; superseded by any applicable PSO.

E. 14 – Not specified for any policy affecting User1; no evidence it applies.

1. Microsoft

“Fine-grained password policies in Active Directory Domain Services

” Windows Server 2022 docs

section “Precedence and resultant password policy” (https://learn.microsoft.com/windows-server/identity/ad-ds/manage/component-updates/operate-fine-grained-password-policies).

2. Microsoft

“Step-by-Step Guide for Fine-Grained Password and Account Lockout Policy

” Windows Server 2019 version

pp. 5-6

“Determining the resultant PSO for a user.”

3. Microsoft

“Group Policy and Active Directory: Password Policy Processing

” Windows Server GPO documentation

§“Why OU-linked password settings are ignored

” para. 2.

The fundamental requirement for establishing a Site-to-Site (S2S) VPN connection between an on-premises network and an Azure virtual network (VNet) is that their IP address spaces must not overlap. In this scenario, the on-premises network uses 10.0.0.0/23 (covering 10.0.0.0 to 10.0.1.255), and VNet1 uses 10.0.1.0/24 (covering 10.0.1.0 to 10.0.1.255). The VNet1 address space is a subset of the on-premises address space, creating an overlap. This conflict will prevent routing from working correctly. Therefore, the first step must be to reconfigure VNet1 with a unique, non-overlapping address range, such as 10.0.2.0/24, before any VPN components can be deployed.

A. The IP address range 10.0.1.128/25 is still contained within the on-premises 10.0.0.0/23 range and does not resolve the address space overlap.

B. Azure Bastion is a service for secure RDP/SSH access to virtual machines and is not relevant to establishing a Site-to-Site VPN or resolving IP address conflicts.

D. Azure Extended Network is a specialized solution for stretching an on-premises subnet into Azure for migration, not the standard method for creating an S2S VPN connection.

1. Microsoft Learn

"VPN Gateway FAQ": Under the "Site-to-site connections and VNets" section

the question "Can I have overlapping address spaces for a VNet and a local on-premises site when I'm using a site-to-site VPN connection?" is answered with a definitive "No. Address spaces must not overlap." This directly supports the need to change the VNet address space.

2. Microsoft Learn

"Tutorial: Create a site-to-site VPN connection in the Azure portal": In the "Prerequisites" section

it states

"Add the address space of the on-premises network... Make sure that the address ranges you declare for your on-premises network don't overlap with the address ranges for the VNet that you want to connect to." This highlights that non-overlapping address spaces are a prerequisite for the entire process.

3. Microsoft Learn

"Plan and design VPN Gateway": In the "Planning table" section for Site-to-Site configuration

the "Private IP address space" for both the VNet and the on-premises local network site must be defined. The documentation throughout emphasizes that these spaces must be unique to ensure proper routing.

To resolve hostnames within an Azure Private DNS zone (fabrikam.com) from an on-premises network, a DNS forwarder within the Azure virtual network is required. This is because the Azure-provided DNS resolver (at IP 168.63.129.16) is not directly reachable from on-premises.

The solution involves two steps:

1. Deploy a Windows Server virtual machine in the Azure VNet, install the DNS Server role, and configure it to forward DNS queries to Azure's internal DNS service. This VM acts as a proxy. (Option E)

2. Configure the on-premises DNS server (DC1) with a conditional forwarder for the fabrikam.com zone. This forwarder will point to the private IP address of the DNS forwarder VM in Azure, directing all fabrikam.com queries across the Site-to-Site VPN for resolution. (Option A)

B. A stub zone resolves authoritative name servers for a zone, not individual host records. A conditional forwarder is the correct mechanism for this query forwarding scenario.

C. Azure Private DNS does not support the zone transfers required to create and maintain a secondary zone on an external DNS server like DC1.

D. Modifying the virtual network's DNS settings primarily affects name resolution for resources within that VNet, not for resolving names from the on-premises network.

1. Microsoft Learn. (2023). Azure Private DNS scenarios. Section: "On-premises workloads using a DNS forwarder". This document explicitly states

"To resolve private zone records from on-premises

you need to deploy a DNS forwarder in the VNet that is linked to the private zone... Then you can configure your on-premises DNS server with a conditional forwarder pointing to the DNS forwarder in Azure." This directly validates the combination of answers A and E.

2. Microsoft Learn. (2023). Name resolution for resources in Azure virtual networks. Section: "Name resolution that uses your own DNS server". This article details how a custom DNS server (such as the forwarder VM in option E) can be used in a VNet to forward queries to Azure's recursive resolvers for hybrid scenarios.

3. Microsoft Learn. (2023). Use conditional forwarders. This document explains the function of a conditional forwarder on a Windows Server DNS server

which is the technology used on the on-premises DC1 as described in option A.

An exclusion range is a set of IP addresses within a DHCP scope that the server is prohibited from leasing to DHCP clients. The scenario involves devices with pre-configured static IP addresses that fall within the DHCP scope's address pool. To prevent the DHCP server from assigning these same addresses to other clients and causing an IP address conflict, these addresses must be excluded from distribution. Since the four IP addresses are in a contiguous block (10.10.1.10-10.10.1.13), creating a single exclusion range is the most direct solution and requires the least administrative effort.

B. Create reservations.

Reservations are used to assign a specific IP address to a specific DHCP client based on its MAC address. The devices in the scenario are configured with static IPs, not as DHCP clients.

C. Configure the Scope options.

Scope options are used to deliver configuration parameters to DHCP clients, such as DNS servers or a default gateway, not to control which IP addresses are leased from the pool.

D. Create a policy.

DHCP policies provide granular control over address assignments based on client attributes. This is an overly complex solution for simply preventing a block of addresses from being leased.

1. Microsoft Learn. "Manage IP address scopes." Windows Server Documentation. In the section "Add an exclusion range

" it states

"You can exclude IP addresses from a scope if you want to prevent them from being leased to DHCP clients. An exclusion is a contiguous range of IP addresses within a scope that are not available for lease." This directly supports using an exclusion range for this purpose.

2. Microsoft Learn. "DHCP Address Pools." Windows Server Documentation. This document explains

"An exclusion range ensures that the server doesn't offer any address in that range to a DHCP client. You should create an exclusion for each address that you've manually assigned to another device on your network."

3. Microsoft Learn. "DHCP Reservations." Windows Server Documentation. This document clarifies the purpose of reservations: "You can use DHCP reservations to assign a specific IP address to a specific DHCP client... Reservations ensure that a specific hardware device on your subnet can always have the same IP address." This confirms reservations are for DHCP clients

which is not the case here.

4. Microsoft Learn. "DHCP Policies." Windows Server Documentation. This source describes policies as a mechanism to "group and configure clients

or to control the parameters that are assigned to them." This is for targeted configuration

not for blocking a static range of IPs.

To use Azure Arc for configuration management policies on servers outside of Azure, you must first onboard them into the Azure control plane. This is accomplished by deploying the Azure Connected Machine agent to each server. This agent connects the machine to Azure, projecting it as an Azure resource. Once the server is an Azure Arc-enabled resource, you can leverage Azure management services like Azure Policy's Guest Configuration feature to audit and enforce configuration settings directly inside the machine's operating system.

A. Hybrid Azure AD join all the servers.

This option is incorrect because Hybrid Azure AD join is an identity feature for registering devices in Azure AD, primarily for single sign-on and conditional access, not for Azure Arc configuration management.

B. Create a hybrid runbook worker m Azure Automation.

This is incorrect. A Hybrid Runbook Worker is a component of Azure Automation used to execute runbooks on non-Azure machines, which is distinct from applying declarative configuration policies via Azure Policy.

D. Deploy the Azure Monitor agent to all the servers.

This is incorrect because the Azure Monitor agent's purpose is to collect monitoring data (logs and metrics) from the guest OS, not to enforce configuration management policies.

1. Microsoft Learn. "Azure Connected Machine agent overview." Azure Arc documentation. This document states

"The Azure Connected Machine agent enables you to manage your Windows and Linux machines hosted outside of Azure... After you've configured your machine with the Azure Connected Machine agent

you can... Assign Azure Policy Guest Configuration policies to audit settings on the machine."

2. Microsoft Learn. "What is Azure Arc-enabled servers?" Azure Arc documentation. This article clarifies

"When a hybrid machine is connected to Azure

it becomes a connected machine and is treated as a resource in Azure. Each connected machine has a Resource ID... and benefits from standard Azure constructs such as Azure Policy and applying tags." This establishes that the connection via the agent is the foundational step.

3. Microsoft Learn. "Understand Azure Policy's Guest Configuration feature." Azure Governance documentation. In the "Client" section

it specifies

"The configuration assignments are processed by the Guest Configuration extension for Azure virtual machines

or the Azure Connected Machine agent for Arc-enabled servers." This directly links the Connected Machine agent to the implementation of configuration policies.

The proposed solution is incorrect. The Active Directory Domains and Trusts console is used to manage the Domain Naming Master, which is a forest-wide Flexible Single Master Operation (FSMO) role. The action of right-clicking the "Active Directory Domains and Trusts" root node and selecting "Operations Master" will display the holder of the Domain Naming Master role, not the PDC emulator.

The PDC emulator is a domain-specific FSMO role. To identify it using a graphical user interface (GUI), you must use the Active Directory Users and Computers console (dsa.msc), right-click the domain object, and then select "Operations Masters".

A. Yes: This is incorrect because the described procedure identifies the Domain Naming Master, not the PDC Emulator as required by the goal.

1. Microsoft Learn. (2023). Active Directory FSMO roles in Windows. Under the section "Viewing and transferring FSMO roles

" it explicitly states: "To view or transfer the domain naming master role

use the Active Directory Domains and Trusts snap-in." and "To view or transfer the RID master

PDC emulator

and infrastructure master roles

use the Active Directory Users and Computers snap-in."

2. Microsoft Learn. (2023). Transfer or seize FSMO roles in Active Directory Domain Services. The section "Transfer FSMO roles by using the MMC snap-ins" provides step-by-step instructions

confirming that Active Directory Domains and Trusts is used for the Domain Naming Master

while Active Directory Users and Computers is used for the PDC Emulator

RID Master

and Infrastructure Master.

An Azure Resource Manager (ARM) template is an Infrastructure as Code (IaC) file used to declaratively define and deploy Azure resources. To automate the deployment of 100 virtual machines and ensure they are joined to an on-premises Active Directory Domain Services (AD DS) domain, an ARM template is the most suitable tool. The template can include the JsonADDomainExtension virtual machine extension. This extension runs a script during the VM provisioning process that automatically joins the machine to the specified AD DS domain, providing a scalable and consistent deployment method.

A. Azure AD Connect: This tool synchronizes identity objects between an on-premises AD DS and Azure AD. It does not deploy or configure Azure virtual machines.

B. a Group Policy Object (GPO): GPOs apply configuration settings to computers that are already members of an AD DS domain. They cannot be used to perform the initial domain join action.

D. an Azure management group: Management groups are a governance tool for organizing Azure subscriptions and applying policies or access controls at scale. They do not directly deploy or configure resources.

1. Microsoft Docs

"JsonADDomainExtension for Windows": This document describes the VM extension used to join an Azure VM to an Active Directory domain. The "Template deployment" section explicitly states

"Azure VM extensions can be deployed with Azure Resource Manager templates."

Reference: Microsoft Corporation. (n.d.). JsonADDomainExtension for Windows. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/json-ad-domain-extension

2. Microsoft Docs

"Tutorial: Create an Azure VM that is joined to a domain": This official tutorial provides a step-by-step guide that uses an ARM template and the JsonADDomainExtension to automate the creation of a Windows Server VM and join it to a domain.

Reference: Microsoft Corporation. (n.d.). Tutorial: Create an Azure VM that is joined to a domain. Microsoft Learn. See the "Deploy the template" section. Retrieved from https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/identity/adds-extend-domain#deploy-the-template

3. Microsoft Docs

"What is Azure AD Connect?": This document defines the purpose of Azure AD Connect

clarifying that it is for synchronizing on-premises directories with Azure AD and is not involved in resource deployment.

Reference: Microsoft Corporation. (n.d.). What is Azure AD Connect?. Microsoft Learn. See the "What is Azure AD Connect?" section. Retrieved from https://learn.microsoft.com/en-us/azure/active-directory/hybrid/connect/whatis-azure-ad-connect

In an Azure Active Directory Domain Services (Azure AD DS) managed domain, the AAD DC Administrators group is specifically designed to delegate administrative tasks. Members of this group are granted permissions to perform domain administration, which includes creating, editing, and linking Group Policy Objects (GPOs) for custom Organizational Units (OUs). Assigning the administrator to this group provides the necessary permissions to manage GPOs without granting excessive privileges, thereby adhering to the principle of least privilege. Privileges for groups like Domain Admins and Enterprise Admins are reserved by the service and cannot be assigned to users.

B. Domain Admins: In Azure AD DS, users cannot be added to the Domain Admins group, as these permissions are reserved for the managed service to operate the domain.

C. Schema Admins: This group has permissions to modify the Active Directory schema, which is far beyond what is needed for GPO management and is a restricted group in Azure AD DS.

D. Enterprise Admins: Similar to Domain Admins, users cannot be added to the Enterprise Admins group in Azure AD DS; these elevated permissions are reserved for the service.

E. Group Policy Creator Owners: This group can create GPOs but can only manage the GPOs they create. It lacks the broader permissions to manage all GPOs or link them, which is required for full administration.

1. Microsoft Learn. (2023). Administer Group Policy on an Azure Active Directory Domain Services managed domain. In "Tutorials > Identity > Azure AD Domain Services". Retrieved from https://learn.microsoft.com/en-us/azure/active-directory-domain-services/manage-group-policy.

Reference Point: In the "Before you begin" section

it explicitly states: "To create and configure GPOs

you need to be signed in to a user account that's a member of the AAD DC Administrators group in your Azure AD tenant."

2. Microsoft Learn. (2023). Administration concepts for an Azure Active Directory Domain Services managed domain. In "Concepts > Security". Retrieved from https://learn.microsoft.com/en-us/azure/active-directory-domain-services/concepts-delegation.

Reference Point: Under the "AAD DC Administrators group" section

it lists the privileges for members

including: "Create and administer Group Policy Objects (GPOs) in the custom GPO container."

3. Microsoft Learn. (2023). Frequently asked questions (FAQs) about Azure Active Directory Domain Services. In "Troubleshoot". Retrieved from https://learn.microsoft.com/en-us/azure/active-directory-domain-services/faqs.

Reference Point: Under the "Administration and operations" section

the FAQ "Can I get domain administrator or enterprise administrator privileges for the managed domain that Azure AD DS creates?" is answered with: "No. You aren't granted domain administrator or enterprise administrator permissions on the managed domain." This confirms options B and D are incorrect.

No: DC1 and DC3 are in non-adjacent sites (Site1 and Site3) separated by Site2. While replication is transitive (changes eventually reach DC3), they do not form a direct replication partnership (connection object) because they do not share a site or a direct site link.

No: Active Directory Inter-Site replication only load balances traffic if multiple paths have identical costs. In this scenario, the KCC will exclusively select SiteLink4 (Cost: 20) because it is cheaper than SiteLink3 (Cost: 60).

No: By default, the "Bridge all site links" option is enabled in the IP intersite transport container. This allows the KCC to treat the network as fully routed and automatically calculate a transitive replication path from Site4 to Site2 via Site1. As DC1 is the only bridgehead in Site1, traffic is naturally routed through it without requiring any configuration changes.

Microsoft Learn: Creating a Site Link Bridge Design. "By default, all site links are transitive... Bridge all site links (enabled by default)."

Microsoft Learn: Determining the Cost. "The KCC uses the cost to determine the cheapest route for replication... If multiple routes have the same cost, the KCC load balances..."

No: An Azure File Sync sync group must contain exactly one cloud endpoint (Azure file share). Since Group1 already uses share1, you cannot add share2 to it. You would need to create a new sync group for share2.

No: While a registered server can participate in multiple sync groups, a sync group can contain only one server endpoint per registered server. Since Server1 already has an endpoint (D:\Folder1) in Group1, you cannot add a second endpoint from the same server (E:\Folder2) to the same group.

Yes: The primary purpose of Azure File Sync is to sync files across multiple locations. You can add server endpoints from different registered servers (like Server2) to the same sync group to keep them in sync with the cloud endpoint.

Microsoft Learn - Planning for an Azure File Sync deployment: "A sync group defines the sync topology for a set of files... A sync group must contain one cloud endpoint, which represents an Azure file share and one or more server endpoints."

Source: https://learn.microsoft.com/en-us/azure/storage/file-sync/file-sync-planning

Microsoft Learn - Create a sync group and a cloud endpoint: confirms the one-to-one relationship between a sync group and a cloud endpoint.

Source: https://learn.microsoft.com/en-us/azure/storage/file-sync/file-sync-deployment-guide?tabs=azure-portal#create-a-sync-group-and-a-cloud-endpoint

In an Active Directory Domain Services (AD DS) environment, the PDC Emulator (Primary Domain Controller Emulator) operations master role is responsible for acting as the authoritative time source for the domain. All other domain controllers synchronize their clocks with the PDC Emulator. Therefore, to configure DC3 as the authoritative time server, you must transfer the PDC Emulator role to it.

The PDC Emulator role is a domain-level Flexible Single Master Operation (FSMO) role. It is managed and transferred using the Active Directory Users and Computers console. You would right-click the domain object within this console, select "Operations Masters," and initiate the transfer under the PDC tab.

Microsoft Learn. (2024). FSMO placement and optimization on Active Directory domain controllers. Retrieved from https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/fsmo-placement-and-optimization-on-ad-dcs (Section: "PDC emulator")

Microsoft Learn. (2023). How to configure an authoritative time server in Windows Server. Retrieved from https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/configure-authoritative-time-server

Microsoft Learn. (2024). View and transfer FSMO roles. Retrieved from https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/view-transfer-fsmo-roles (Table: "FSMO roles and the snap-ins to manage them")

Yes: User1 is located in OU1, which is selected for synchronization in the "Domain and OU filtering" settings. Consequently, the user identity exists in Azure AD. The "Ready to configure" screen shows that Password writeback is enabled. Password writeback is a prerequisite for Self-Service Password Reset (SSPR) to function for synchronized users.

Yes: The configuration shows that Pass-through authentication (PTA) is being enabled. In the PTA method, when a user signs in, the password is validated directly against the on-premises Active Directory Domain Controller by an authentication agent. This contrasts with Password Hash Sync, where authentication occurs in the cloud.

No: User2 is located in OU2. In the "Domain and OU filtering" settings, OU2 is unchecked, meaning User2 is filtered out and not synchronized to the Azure AD tenant. You cannot add a user to an Azure AD group (Group1) if that user object does not exist in the Azure AD directory.

Microsoft Learn - Microsoft Entra Connect sync: Configure filtering:

Section: Domain and OU-based filtering

"The domain and OU-based filtering option allows you to select specific domains and OUs to synchronize... If an OU is not selected, the users and groups in that OU are not synchronized."

URL: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-configure-filtering#domain-and-ou-based-filtering

Microsoft Learn - User sign-in with Microsoft Entra Pass-through Authentication:

Section: Feature highlights

"Pass-through Authentication validates users' passwords directly against your on-premises Active Directory."

URL: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-pta

Microsoft Learn - Tutorial: Enable Microsoft Entra self-service password reset writeback:

Section: Enable password writeback in Microsoft Entra Connect

Confirming that enabling the "Password writeback" option in the synchronization settings is the required step to allow password changes in the cloud to be written back to the on-premises directory.

URL: https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback

In Azure Active Directory Domain Services (Azure AD DS), the service manages the underlying domain controllers, so traditional "Domain Admin" or "Enterprise Admin" privileges are not available to users. Instead, administrative tasks—such as creating and linking Group Policy Objects (GPOs)—are delegated specifically to members of the AAD DC Administrators group. You must sign in with an account in this group to perform these actions.

The objective is to set a password policy for local user accounts on the virtual machines. Local account settings are controlled via the "Computer Configuration" section of a GPO. By default, when a virtual machine joins an Azure AD DS managed domain, its computer object is placed in the AADDC Computers organizational unit (OU). Therefore, to apply the GPO to these VMs, it must be linked to the AADDC Computers OU.

Microsoft Learn. "Administer Group Policy in an Azure Active Directory Domain Services managed domain." Microsoft Entra. Accessed February 10, 2026.

Relevance: Section "Before you begin" states: "You need a user account that's a member of the AAD DC Administrators group in your tenant to administer Group Policy."

Microsoft Learn. "Create and manage organizational units (OUs) in an Azure Active Directory Domain Services managed domain." Microsoft Entra. Accessed February 10, 2026.

Relevance: Section "Default OUs in a managed domain" confirms: "The AADDC Computers OU contains computer objects for all computers that are joined to the managed domain."

To create a Group Managed Service Account (gMSA), the New-ADServiceAccount cmdlet is required. The scenario states that "Group1 can use Account1." In the context of gMSAs, "using" the account implies the ability of a host (or group of hosts) to retrieve the managed password from Active Directory to start a service running as that account.

The parameter -PrincipalsAllowedToRetrieveManagedPassword specifies the security descriptor that defines which principals (users, groups, or computers) are authorized to retrieve the password for the managed service account. The parameter -PrincipalsAllowedToDelegateToAccount is incorrect as it relates to resource-based constrained delegation, not password retrieval rights.

Microsoft Learn (Official Documentation): "New-ADServiceAccount"

Source: learn.microsoft.com

Relevant Section: Description of -PrincipalsAllowedToRetrieveManagedPassword: "Specifies the set of principals allowed to retrieve the password of the group managed service account."

Microsoft Learn (Official Documentation): "Getting Started with Group Managed Service Accounts"

Source: learn.microsoft.com

Relevant Section: "To create the group managed service account... run the following command: New-ADServiceAccount -Name -DNSHostName -PrincipalsAllowedToRetrieveManagedPassword "

Statement 1 (No): When accessing a file via a network share, the most restrictive permission between Share and NTFS applies (Effective Permissions). While User1 has NTFS Full Control, the Share permissions for Domain Users are limited to Change and Read. The Change permission allows modification and deletion but does not grant the right to Take Ownership or change permissions; Full Control at the share level is required for that.

Statement 2 (Yes): The setting FolderEnumerationMode : AccessBased indicates Access-Based Enumeration (ABE) is enabled. ABE hides files unless a user has Read (or List) permissions. User2 has explicit NTFS Read permission, so the file is visible.

Statement 3 (No): User3 has explicit NTFS Write permission but lacks Read permission. The "Enable inheritance" button in the exhibit confirms inheritance is disabled, and the Domain Users group is not listed in the NTFS ACL, so User3 cannot inherit read rights. Since User3 implies "Write-only" (Drop-box scenario) and cannot read the file, ABE hides it from their view.

Microsoft Learn (Windows Server): Share and NTFS Permissions on a File Server. Explains that the most restrictive permission applies when accessing shared resources and that Change share permission does not include Full Control rights (like taking ownership).

Microsoft Learn (Windows Server): Enable Access-based Enumeration on a Namespace. Confirms that ABE displays only the files and folders that a user has permission to access (specifically requiring Read/List permissions).

Microsoft Official Courseware (AZ-800): Administering Windows Server Hybrid Core Infrastructure. Section on File and Storage Services, covering effective permissions and Access-Based Enumeration logic.

Box 1: An External virtual switch binds to a physical network adapter. The scenario states Server1 has a single network interface, which is already consumed by the existing external switch (VSwitch3, indicated by the network adapter name in the tree). Consequently, you cannot create another external switch. Private and Internal switches are purely software-based and do not require a dedicated physical interface, so multiple instances of these can still be created.

Box 2: Network connectivity for the management operating system (Server1) is determined by the switch type:

• Private (VSwitch1): Isolates VMs from the host. Server1 cannot access these VMs.
• Internal (VSwitch2): permits communication between VMs and the host. Server1 can access these VMs.
• External (VSwitch3): Connects to the physical network. On a single-NIC server, the "Allow management operating system to share this network adapter" setting is standard to maintain host connectivity, placing the host on the switch. Thus, Server1 can access these VMs.

Microsoft Learn. (2023). Create a virtual switch in Hyper-V. Windows Server. Retrieved from https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/connect-to-network

Microsoft Learn. (2022). Hyper-V Virtual Switch. Windows Server. Retrieved from https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/hyper-v-virtual-switch/hyper-v-virtual-switch