AZ-801 Practice Questions

Azure App Service Hybrid Connections provide a secure and direct way for an Azure web app to access on-premises resources, such as a Microsoft SQL Server database. This feature establishes a TCP tunnel from the App Service to a specific on-premises host and port combination. It is configured within the App Service's networking settings and requires installing a small agent, the Hybrid Connection Manager, on the on-premises network. This approach is ideal for this scenario as it doesn't require complex network configurations like a VPN or ExpressRoute, providing a targeted connection from the PaaS application to the on-premises database.

A. an Azure SQL managed instance: This is a fully managed PaaS database service in Azure. The requirement is to connect to the existing on-premises database, not migrate it.

B. an on-premises data gateway: This is primarily used by services like Power BI, Power Automate, and Logic Apps to connect to on-premises data sources, not as the primary connectivity method for App Service web apps.

C. Azure Extended Network: This feature is designed to stretch an on-premises network to Azure, allowing virtual machines to be migrated to Azure while retaining their original IP addresses. It is not for PaaS connectivity.

1. Microsoft Learn

"Azure App Service Hybrid Connections": Under the "How it works" section

it states

"Hybrid Connections can connect App Service apps to on-premises resources that use a static TCP port

such as SQL Server

MySQL

HTTP Web APIs

and most custom web services." This directly validates the use of Hybrid Connections for connecting to an on-premises SQL Server.

2. Microsoft Learn

"App Service networking features": In the comparison table under the "Hybrid Connections" section

the use case is described as "Access resources in other networks." This confirms it as the appropriate feature for connecting from the Azure App Service to an on-premises network.

3. Microsoft Learn

"What is an on-premises data gateway?": This document lists the supported cloud services that use the gateway

including "Power BI

Power Apps

Power Automate

Azure Analysis Services

and Azure Logic Apps." Azure App Service is not listed as a primary consumer

making this option less suitable than the purpose-built Hybrid Connection feature.

4. Microsoft Learn

"Azure Extended Network overview": The overview clearly states

"Azure Extended Network enables you to stretch your on-premises network to Azure for migrating on-premises workloads to Azure while preserving their IP addresses." This confirms its purpose is for IaaS migration

not PaaS-to-on-premises connectivity.

To ensure Microsoft Defender for Identity (MDI) detects all security risks, the sensor must be installed on all domain controllers, including Read-Only Domain Controllers (RODCs). MDI analyzes network traffic and events directly on the DCs; omitting any controller (such as an RODC) creates a blind spot where authentication requests or attacks could go undetected.

Regarding the installation process, the Access Key is the specific credential required within the sensor setup wizard to authorize and register the sensor with the MDI cloud instance. While a Directory Service Account (often a gMSA) is required for MDI to query Active Directory, this account is configured centrally in the MDI Portal (under Configuration > Directory Service accounts), not entered manually during the local sensor installation wizard.

Microsoft. (2024). Microsoft Defender for Identity architecture. Retrieved from Microsoft Learn: https://learn.microsoft.com/en-us/defender-for-identity/architecture#defender-for-identity-sensor (See "Defender for Identity sensor" section: "You install the Defender for Identity sensor directly on your domain controllers.")

Microsoft. (2024). Install the Microsoft Defender for Identity sensor. Retrieved from Microsoft Learn: https://learn.microsoft.com/en-us/defender-for-identity/install-step4 (See Step 5: "Enter the Access key retrieved from the previous step.")

Microsoft. (2024). Directory Service Accounts for Microsoft Defender for Identity. Retrieved from Microsoft Learn: https://learn.microsoft.com/en-us/defender-for-identity/directory-service-accounts (Confirms DSA configuration is performed in the Defender for Identity portal).

The objective is to migrate print services to a new server with minimal downtime while ensuring users receive the correct printer mappings via Group Policy.

1. Export the printers on Server1: The first step in the Printer Migration Wizard process is to export the printer queues, ports, and drivers from the source server (Server1) to a migration file.
2. Import the printers on Server2: Once the export is complete, the configuration file is imported onto the destination server (Server2), creating the necessary print queues and ports.
3. Modify GPO1: After the printers exist on Server2, the Group Policy Object (GPO1) responsible for printer deployment must be updated to reference the new UNC paths (e.g., changing \\Server1\PrinterName to \\Server2\PrinterName). This redirects client computers to the new server.
4. Decommission Server1: Finally, once the migration is verified and clients are successfully printing via Server2, the old server (Server1) can be safely decommissioned to complete the lifecycle.

Microsoft Learn. (2024). Migrate Print and Document Services to Windows Server 2012. "Migrate Print and Document Services." Retrieved from https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj134150(v=ws.11

Note: While the title references Server 2012, the Printer Migration Wizard workflow (Export -> Import) remains the standard procedure for Windows Server print migration.

Microsoft Learn. (2022). Deploy printers by using Group Policy. "Deploy printers to users or computers by using Group Policy." Retrieved from https://learn.microsoft.com/en-us/troubleshoot/windows-server/printing/deploy-printers-by-using-group-policy

Confirms the mechanism of using GPOs to map printers to clients, necessitating the "Modify GPO1" step when the server name changes.

A "Request timed out" error when pinging a remote host typically indicates a problem with the return path. The ICMP Echo Request from Server4 reaches Server3, but the ICMP Echo Reply from Server3 fails to return to Server4.

The key information is that a ping from Server2 to Server3 succeeds. This successful round-trip communication proves that Server3's default gateway is correctly configured, as it is required to send the reply packet from the 192.168.1.0/24 subnet back to the 192.168.0.0/24 subnet. This eliminates the default gateway as the cause.

An incorrect subnet mask on Server3 (e.g., 255.255.0.0 instead of 255.255.255.0) would cause it to incorrectly determine that Server4 (192.168.0.10) is on its local network. Consequently, Server3 would not send the reply packet to its default gateway, and the packet would never reach Server4, resulting in a timeout.

A. default gateway: The successful ping from Server2 to Server3 confirms that Server3's default gateway is configured correctly, as it is essential for the return traffic to the 192.168.0.0/24 subnet.

B. IP address: The successful ping from Server2 proves that Server3 has a correct and reachable IP address on the 192.168.1.0/24 network.

D. DNS server: DNS is used to resolve hostnames to IP addresses. The problem describes pinging by IP address, a process that does not involve DNS.

1. Microsoft Learn. (2023). TCP/IP fundamentals for Windows. Section: "How TCP/IP Works"

Sub-section: "IP routing". This document explains that the subnet mask is used to determine if a destination is on the local or a remote network. If remote

traffic is sent to the default gateway. An incorrect mask disrupts this fundamental decision.

2. Microsoft Learn. (2023). Troubleshooting TCP/IP connectivity. Section: "Troubleshooting Methodology"

Step 3: "Verify connectivity to a remote host". This guide notes that a "Request timed out" error can be caused by an incorrect subnet mask or default gateway configuration on the destination host

preventing the echo reply from being routed back correctly.

3. Microsoft Learn. (2023). Plan an IP addressing scheme. Section: "Understanding subnetting". This document details the bitwise ANDing process a host uses with its IP address and subnet mask to determine the network ID of a destination

which dictates whether to use the default gateway

Statement 1 (No): Server1 is configured to Request authentication for outbound connections. This setting implies a preference for IPsec but allows a fallback to clear text if the peer (Server2) does not support or negotiate IPsec. Since Server2 has no configured Connection Security Rule, Server1 falls back to a standard clear-text connection. Furthermore, default "Server-to-server" rules provide authentication and integrity (signing), but not encryption, unless explicitly configured in the Data Protection settings.

Statement 2 (Yes): Neither Server2 nor Server3 has connection security rules. They communicate using standard unencrypted network protocols (clear text). Since there are no "Require" rules to block non-IPsec traffic, the connection is successfully established.

Statement 3 (No): Server1 is configured to Require authentication for inbound connections. This strict setting forces Server1 to drop any inbound traffic that is not authenticated via IPsec. Since Server3 has no connection security rule, it initiates a standard clear-text connection, which Server1 rejects. Thus, the connection is not established (and effectively not encrypted).

Microsoft Learn, "Windows Defender Firewall with Advanced Security Design Guide," specifically the section on Connection Security Rules, which details the difference between "Request" (negotiate but allow fallback) and "Require" (enforce IPsec).

Microsoft Learn, "Data Protection (Quick Mode) Settings," which confirms that default IPsec settings (used by the Server-to-server wizard) prioritize integrity (ESP-Null or AH) over encryption unless "Require encryption" is explicitly selected.

Exam Ref AZ-801: Configuring Windows Server Hybrid Advanced Services, Chapter 4 (Secure Windows Server), discussing Connection Security Rules and Isolation Policies.

First, the storage must be managed by the cluster, so you add the disk resource and then promote it by creating a Cluster Shared Volume (CSV). According to Microsoft best practices for CSVs, you must put the disk in maintenance mode (Suspend-ClusterResource) before modifying the volume with encryption to ensure exclusive access. Next, you enable BitLocker on the volume to encrypt the data. Finally, you update the BitLockerProtectorInfo property (using Set-ClusterParameter) with the key protector ID; this step is crucial for ensuring the Cluster service can retrieve the key and unlock the volume automatically across all nodes.

Microsoft Learn - BitLocker on Cluster Shared Volumes (CSV):

"When using BitLocker with volumes designated for a cluster... Put the resource into maintenance mode before enabling BitLocker."

This source confirms the necessity of maintenance mode specifically for CSVs.

Source: BitLocker: How to deploy on Windows Server 2012 and later (Section: BitLocker on Cluster Shared Volumes).

Microsoft Learn - PowerShell Cmdlets for Clustering:

Documentation for Set-ClusterParameter often uses BitLockerProtectorInfo in examples for configuring CSV encryption, confirming this is a post-encryption configuration step to store the recovery key ID in the cluster database.

Microsoft Technical Documentation - Failover Clustering:

The workflow is described as: Add Disk -> Add to CSV -> Suspend Resource (Maintenance) -> Enable BitLocker -> Resume Resource -> (Optional/Required per version) Update Cluster Parameter.

To perform a Cluster Operating System Rolling Upgrade from Windows Server 2022 to Windows Server 2025 with minimal downtime, the process is performed on one node at a time.

1. Drain and evict the node: First, the node must be paused and roles drained to other active nodes to ensure service continuity. The node is then evicted (removed) from the cluster to prepare for the OS change.
2. Install Windows Server 2025 and Failover Clustering: A clean installation of the new operating system is performed on the evicted node, followed by the installation of the Failover Clustering feature.
3. Add the node to Cluster1: The upgraded node is added back into the existing cluster. The cluster will operate in a mixed-OS mode until all nodes are upgraded.

(Note: "Update the functional level of Cluster1" is performed only once after all nodes have been upgraded, not "on each node" individually.)

Microsoft Learn - Cluster Operating System Rolling Upgrade

Section: "Cluster OS Rolling Upgrade process" -> "Process steps"

Relevance: Step 3 in the documentation explicitly lists the per-node actions: "Pause and drain the node", "Evict the node", "Clean install Windows Server", "Add the node to the cluster".

Source: https://learn.microsoft.com/en-us/windows-server/failover-clustering/cluster-operating-system-rolling-upgrade

Microsoft Learn - Upgrade a failover cluster

Section: "Perform a rolling upgrade"

Relevance: Confirms the sequence of pausing, removing, rebuilding, and re-adding nodes for a rolling upgrade.

Source: https://learn.microsoft.com/en-us/azure-stack/hci/manage/upgrade-cluster-os

Core isolation provides added protection against malware and other attacks by isolating computer processes from the operating system and device. In the Windows Security app, this feature is managed under the Device security tile, specifically within the "Core isolation details" section.

Force randomization for images (Mandatory ASLR) is an Exploit Protection mitigation that randomizes the memory locations where application code is loaded. Exploit Protection settings are accessed via the App & browser control tile. From there, administrators must navigate to "Exploit protection settings" to configure system-wide or program-specific mitigations like ASLR.

Microsoft Learn. (2023). Device protection in Windows Security. Retrieved from https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/windows-security-app/device-security-in-windows-security (Section: "Core isolation")

Microsoft Learn. (2023). Enable exploit protection. Retrieved from https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/enable-exploit-protection?view=o365-worldwide (Section: "Windows Security app")

Microsoft Learn. (2023). Customize exploit protection. Retrieved from https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/customize-exploit-protection?view=o365-worldwide

To configure Hyper-V Replica using Kerberos authentication, the replica server must be prepared to accept incoming replication traffic over HTTP on the default port 80. The Windows Defender Firewall on the replica server, Server1, blocks this traffic by default. Therefore, the predefined inbound firewall rule named "Hyper-V Replica HTTP Listener (TCP-In)" must be enabled. This rule specifically allows the necessary traffic for Kerberos-based replication, fulfilling the requirements of the scenario. Enabling the server as a replica in Hyper-V Settings is also required, but enabling the firewall rule is a distinct and necessary step to allow network communication.

A. The Hyper-V Replica Broker is a role configured on a failover cluster to act as a replication endpoint. Server1 is a standalone server, not a cluster, so it does not use a Replica Broker.

B. Live migration is a separate technology used for moving running virtual machines between Hyper-V hosts with no downtime. It is not related to Hyper-V Replica, which is an asynchronous disaster recovery solution.

C. The Hyper-V Replica HTTPS Listener (TCP-In) rule is for port 443. This port is used for certificate-based authentication, not the Kerberos authentication specified in the question.

1. Microsoft Learn

Deploy Hyper-V Replica

"Step 3: Configure the firewall". This document states

"To allow replication between the servers

you need to ensure the Windows Firewall allows Hyper-V Replica traffic... For Kerberos authentication (HTTP)

enable the rule Hyper-V Replica HTTP Listener (TCP-In)."

2. Microsoft Learn

Hyper-V Replica Architecture

"Security and Firewall Considerations". This section details the network protocols and ports used. It explicitly mentions

"Hyper-V Replica includes a predefined inbound firewall rule “Hyper-V Replica HTTP Listener (TCP-In)” to enable replication traffic. You need to manually enable this rule."

3. Microsoft Learn

Set up Hyper-V Replica

"Enable Hyper-V Replica". This guide details the setup wizard options

clarifying the authentication methods: "If you select Use Kerberos authentication (HTTP)

replication data will be unencrypted... The wizard automatically creates a firewall exception to allow traffic on the specified ports (80 for HTTP and 443 for HTTPS)." This confirms that enabling the firewall rule for HTTP (port 80) is the correct action for Kerberos.

To meet the requirements, you must use Authentication Policies and Silos. First, create an authentication policy to define the custom Kerberos TGT lifetime (1 hour) and access conditions. Second, create an authentication policy silo to serve as the isolation container that restricts where the assigned users can authenticate. Finally, assign the authentication policy silo to user and computer accounts (specifically the Domain Admins and Domain Controllers) to enforce the policy and logon restrictions on those specific principals. The Default Domain Policy GPO is global and cannot target specific groups for TGT lifetimes.

Microsoft Learn: Authentication Policies and Authentication Policy Silos - Defines how policies control TGT lifetime and how silos restrict account usage to specific scopes.

Source: https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos

Microsoft Learn: How to Configure Protected Accounts - Provides the step-by-step workflow: Create Policy -> Create Silo -> Assign Accounts.

Source: https://learn.microsoft.com/en-us/windows-server/security/windows-authentication/how-to-configure-protected-accounts

Microsoft Learn: Set-ADAccountAuthenticationPolicySilo - Documentation for the PowerShell cmdlet used to assign the silo to accounts, confirming this is the final implementation step.

Source: https://learn.microsoft.com/en-us/powershell/module/activedirectory/set-adaccountauthenticationpolicysilo