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.