Free Microsoft AZ-801 Practice Test Questions MCQs

Explanation:

This question tests your knowledge of configuring BitLocker Auto-Unlock on fixed or removable data volumes in Windows Server. BitLocker Auto-Unlock allows data volumes to unlock automatically upon system boot without user intervention, provided specific prerequisites are satisfied.

✅ Correct Option:

Step 1: Install the BitLocker Drive Encryption feature.
Windows Server does not enable the BitLocker Drive Encryption feature by default. Installing the core BitLocker feature provides the necessary system drivers, background services, and PowerShell cmdlets needed to manage BitLocker encryption keys and configure automatic unlocking capabilities across all system volumes.

Step 2: Encrypt volume C.
A strict prerequisite for enabling BitLocker Auto-Unlock on any secondary data volume is that the primary operating system volume (Volume C) must be encrypted with BitLocker. Auto-unlock stores the encrypted volume's unlocking keys inside the local system registry, which must be protected by OS-level encryption to remain secure.

Step 3: Turn on auto-unlock.
With the BitLocker feature active and the operating system drive protected by BitLocker, auto-unlock can now be enabled specifically for Volume E. After enabling auto-unlock, Windows automatically decrypts Volume E during system boot whenever the encrypted operating system drive successfully unlocks.

❌ Incorrect options:

Installing the BitLocker Drive Encryption Administration Utilities feature
The BitLocker Drive Encryption Administration Utilities feature provides Remote Server Administration Tools (RSAT) for managing remote machines, which is not required since local administration tools are included when installing the main BitLocker feature on Server1.

Installing the BitLocker Network Unlock feature
BitLocker Network Unlock is designed specifically to automatically unlock operating system drives over a wired network during PXE boot using WDS and DHCP servers. It plays no role in automatically unlocking secondary data drives like Volume E.

Encrypting volume D
Encrypting Volume D is unnecessary because auto-unlock dependencies rely exclusively on the primary operating system volume (Volume C) being encrypted. Additional data volumes do not need to be encrypted to enable auto-unlock on Volume E.

🔧 Reference:
⇒ Microsoft Learn - BitLocker operations guide confirms that the operating system drive must be encrypted with BitLocker before auto-unlock can be configured for secondary data drives.

Explanation:

This question tests your understanding of the Failover Clustering Tools installation requirements for Cluster-Aware Updating (CAU) in self-updating and remote-updating modes. The key is determining which servers act as the Update Coordinator in each mode.

✅ Correct Options:

Self-updating mode: Node1 and Node2 only
In self-updating mode, the CAU clustered role is configured as a workload on the cluster itself, meaning all cluster nodes must have Failover Clustering Tools installed to participate in the updating process. The CAU Update Coordinator process runs on whichever cluster node owns the CAU clustered role, then fails over between nodes during the update run.

Remote-updating mode: Server1 only
In remote-updating mode, Server1 acts as the Update Coordinator computer. It must have Failover Clustering Tools installed to trigger and manage updating runs. The cluster nodes (Node1 and Node2) only need the Failover Clustering feature installed, not the tools, unless you need to run certain cmdlets like Save-CauDebugTrace.

❌ Incorrect Options:

Self-updating: Node1 only or Node2 only
CAU self-updating requires all cluster nodes to have Failover Clustering Tools installed because the CAU clustered role can fail over to any node. Restricting to a single node would break the automatic failover of the updating process.

Self-updating: Server1 only or Server1 combinations
Server1 is a member server outside the cluster. In self-updating mode, Server1 does not participate in the update orchestration. It has no CAU clustered role and cannot assume the Update Coordinator role within the cluster.

Remote-updating: Node1, Node2, or combinations
Cluster nodes do not function as Update Coordinator in remote-updating mode. The orchestration is performed externally from a computer that has network connectivity to the cluster, making Server1 the required installation target.

Remote-updating: Node1 and Node2 only
This option incorrectly assigns the Update Coordinator role to cluster nodes. In remote-updating mode, the coordinator runs outside the cluster, so only the remote computer needs Failover Clustering Tools.

🔧 Reference:
→ Microsoft Learn – Cluster-Aware Updating requirements and best practices – Provides the installation requirements table showing Failover Clustering Tools are required on all cluster nodes for self-updating mode and on the remote update computer for remote-updating mode.

→ Microsoft Learn – Cluster-Aware Updating overview – Explains that in self-updating mode, the CAU clustered role runs on cluster nodes, while remote-updating mode uses an external Update Coordinator computer.

Explanation:

This question tests the behavior of Windows Defender Firewall connection security (IPsec) rules when the authentication requirement is set to “Request” versus “Require.”

Request authentication = Prefer an authenticated connection, but fall back to clear-text if authentication fails or the peer has no matching rule.
Require authentication = Accept only authenticated connections; block the connection if authentication cannot be negotiated.

All three servers use the Default authentication method (Kerberos), so domain-joined machines can successfully authenticate with one another. Server4 has no connection security rules and therefore only supports clear-text traffic.

✅ From Server1 (Request inbound + outbound)
Server1 is flexible. It will attempt authentication but will accept clear-text when necessary.

Server2 accepts the connection (its inbound setting is Request).
Server3 accepts the connection because Server1 successfully authenticates with Kerberos (Server3’s inbound setting is Require).
Server4 accepts the connection in clear-text (Server1 falls back because Server4 has no IPsec rule).
Therefore Server1 can communicate with Server2, Server3, and Server4.

✅ From Server2 (Request inbound / Require outbound)
Server2 will only initiate connections that can be authenticated.

Server1 accepts the authenticated connection (its inbound setting is Request).
Server3 accepts the authenticated connection (its inbound setting is Require).
Server4 cannot authenticate, so the outbound connection from Server2 is blocked.
Therefore Server2 can communicate only with Server1 and Server3.

❌ Why other combinations are incorrect

Selecting only Server2 for Server1 ignores the fact that Server1 can still talk to Server3 (authenticated) and Server4 (clear-text fallback).

Selecting only Server3 for Server2 ignores the successful authenticated connection that Server2 can establish with Server1.

🔧 Reference:
→ Microsoft Learn: Explore authentication options
Explains the difference between “Request authentication” (allows fallback) and “Require authentication” (blocks unauthenticated traffic).

Explanation:

The forest functional level is currently Windows Server 2008 R2, while the domain controllers already run Windows Server 2016 or newer. Before the forest functional level can be raised to Windows Server 2016, contoso.com must first have its domain functional level raised to Windows Server 2016. This is the required first step.

🟢 Correct Option: C. Raise the domain functional level of contoso.com to Windows Server 2016.
The contoso.com domain currently has a Windows Server 2012 R2 domain functional level, while its domain controllers run Windows Server 2016. Because the forest functional level cannot be raised above the domain functional level of any domain, contoso.com must first be raised to Windows Server 2016. After that, the forest functional level can be raised appropriately for the Windows Server 2025 upgrade.

🔴 Incorrect Option: A. Raise the domain functional level of east.contoso.com to Windows Server 2025.
The east.contoso.com domain already has a Windows Server 2016 domain functional level, but Windows Server 2025 requires the domain controllers to be running Windows Server 2025 before its functional level can be raised. Therefore, this cannot be the first step.

🔴 Incorrect Option: B. Extend the schema.
Schema preparation is required when introducing a newer Windows Server domain controller, but the forest currently has a Windows Server 2008 R2 functional level. Windows Server 2025 requires a supported functional level, so the functional-level prerequisites must be addressed before proceeding with the upgrade.

🔴 Incorrect Option: D. Raise the forest functional level to Windows Server 2025.
The forest cannot immediately be raised to Windows Server 2025. Its domains must first meet the required functional-level prerequisites, and Windows Server 2025 requires an existing domain to be at least Windows Server 2016 functional level. Also, Windows Server 2025 cannot be used as a forest functional level until the DCs run 2025.

🔧 Reference:
→ Microsoft Learn — Active Directory Domain Services functional levels — Confirms the supported Windows Server 2025 functional-level requirements and interoperability.

→ Microsoft Learn — Raise Domain and Forest Functional Levels in AD DS — Confirms that the domain functional level must be raised before the forest functional level.

Explanation:

This question tests your knowledge of the deployment requirements for Storage Spaces Direct nested resiliency. It focuses on identifying the exact node count limitation that applies when using this specific resiliency configuration.

✅ Correct Option:

A. 2
Nested resiliency is designed exclusively for two-server clusters. Microsoft documentation explicitly states that nested resiliency should only be used if your cluster has exactly two servers . This configuration enables a two-node cluster to survive multiple simultaneous hardware failures, such as losing one server and one drive at the same time, while keeping volumes online .

❌ Incorrect Options:

B. 4
Four nodes is the minimum requirement for mirror-accelerated parity, a different resiliency type. Nested resiliency cannot be deployed on four-node clusters—the documentation confirms it is not supported with three or more servers .

C. 12
This number does not correspond to any Storage Spaces Direct resiliency limitation. Nested resiliency specifically requires exactly two servers, making twelve nodes invalid for this configuration .

D. 16
While 16 is the maximum number of nodes supported in a standard hyperconverged Azure Local cluster, nested resiliency is limited to two-node deployments only .

E. 32
This exceeds the maximum node count for hyperconverged deployments entirely. Nested resiliency has no applicability at this scale—it requires exactly two servers .

🔧 Reference:
→ Microsoft Learn – Nested resiliency for Storage Spaces Direct – States "only use nested resiliency if your cluster has exactly two servers" .

→ Microsoft Learn – Fault tolerance and storage efficiency – Documents resiliency types and their minimum fault domain requirements for Storage Spaces Direct .

Explanation:

This question tests the proper sequence for migrating the DHCP Server role from a Windows Server 2019 source server (Server1) to a Windows Server 2025 destination server (Server2) by using the built-in Windows Server Migration Tools. Both servers are already authorized as DHCP servers in the AD DS domain and have the Migration Tools installed. The process must capture the complete DHCP configuration, transfer it securely, prepare the target server, import the settings, and bring the service online with minimal disruption.

✅ Correct sequence:

From Server1, run the Export-SmigServerSetting cmdlet.
This cmdlet is executed on the source server to collect all DHCP-related data—including scopes, reservations, leases, server options, and related settings—into a single encrypted migration store file named Svrmig.mig.

Copy the Svrmig.mig file to Server2.
The migration store must be copied to a location accessible by the destination server so that the configuration can be imported in the next steps.

From Server2, run the Add-WindowsFeature cmdlet.
The DHCP Server role (and its management tools) must be installed on Server2 before any configuration can be imported. Without the role present, the import operation will fail.

From Server2, run the Import-SmigServerSetting cmdlet.
This cmdlet reads the Svrmig.mig file and applies the exported DHCP configuration to Server2, recreating the scopes, options, and other settings exactly as they existed on Server1.

From Server2, run the Start-Service cmdlet.
After a successful import, the DHCP Server service is started on Server2 so it can begin responding to client requests and serving IP addresses.

❌ Incorrect actions (not part of the required sequence):

From Server1, run the Stop-Service cmdlet – Stopping the DHCP service on the source is sometimes performed after the export to prevent address conflicts, but it is not one of the mandatory steps when using the Migration Tools for this migration.

Copy the Dhcp.mdb file to Server2 – Copying the raw DHCP database file is the older manual method. The Windows Server Migration Tools replace this approach with the standardized Svrmig.mig migration store.

🔧 Reference:
→ Microsoft Learn: Migrate a DHCP server installation to another Windows Server
Provides the official step-by-step process using Export-SmigServerSetting on the source, transferring the migration store, installing the role on the destination, running Import-SmigServerSetting, and starting the DHCP service.

Explanation:

This question tests how to onboard many on-premises Windows Servers to Azure Arc by using an automated template script. The solution must use least privilege and minimize administrative effort. A Microsoft Entra service principal provides a dedicated identity for scripted onboarding and can be assigned only the permissions required to connect servers to Azure Arc.

✔️ Correct Option:

D. Create a Microsoft Entra service principal
A service principal is designed for automated Azure Arc onboarding at scale. Instead of using a personal administrator account on all 500 servers, the template script can use the service principal to authenticate each server and register it with Azure Arc. Assigning the Azure Connected Machine Onboarding role at the appropriate resource-group or subscription scope applies least privilege while reducing repeated administrative interaction.

❌ Incorrect Options:

A. Create a group managed service account (gMSA)
A gMSA is an Active Directory account used by Windows services and scheduled tasks. It does not provide the Azure identity and role-based authorization required for the Connected Machine agent to register servers with Azure Arc. It would not be the appropriate credential for the Azure Arc template script.

B. Download the Log Analytics workspace ID
The workspace ID is required later when configuring monitoring and sending data to Log Analytics. However, it does not authenticate the servers or authorize their registration with Azure Arc. The first step must establish an identity with the required Azure permissions, so downloading the workspace ID alone is insufficient.

C. Generate a Log Analytics key
The Log Analytics workspace key is used to authenticate agents that send monitoring data to the workspace. It does not grant permission to onboard machines to Azure Arc. Generating the key first would also provide no dedicated identity for the scripted registration of 500 servers.

🔧 Reference:
→ Microsoft Learn – Connect hybrid machines to Azure at scale | Microsoft Azure
— Microsoft Azure confirms that a service principal is a limited management identity used to connect machines to Azure Arc and supports automated onboarding scripts.

→ Microsoft Learn – Identity and access management for Azure Arc-enabled servers | Microsoft Cloud Adoption Framework
— Microsoft Cloud Adoption Framework confirms that the Azure Connected Machine Onboarding role supports least-privilege server registration.

Explanation:

This question tests your understanding of applying Windows Defender SmartScreen and App Install Control Group Policy settings. App Install Control enforces restrictions on application installation sources to ensure only approved applications can be installed on target Windows Server machines.

✅ Correct Option:

A. App1 only
The Group Policy Object applied to OU1 configures "Configure App Install Control" with the value "Allow apps from Store only." This policy restricts software installation exclusively to applications sourced directly from the Microsoft Store. Because App1 is the only application sourced from the Microsoft Store, it is the only app permitted to be installed on Server1.

❌ Incorrect options:

B. App1 and App2 only
App2 is located on a network share. The "Allow apps from Store only" policy blocks all non-Store installation sources, preventing App2 from installing regardless of Windows Defender SmartScreen warnings.

C. App1 and App3 only
App3 is located on a removable USB key. Non-Store media sources are blocked by App Install Control when set to store-only enforcement, making App3 impossible to install.

D. App1, App2, and App3
Including App2 and App3 is incorrect because the App Install Control setting blocks any installation sourced outside of the official Microsoft Store, regardless of whether SmartScreen bypass is disabled.

🔧 Reference:
⇒ Microsoft Learn - Configure App Install Control in Windows confirms that setting App Install Control to "Allow apps from Store only" blocks all application installations that do not originate from the Microsoft Store.

Explanation:

The question tests the prerequisites for enabling File Integrity Monitoring (FIM) in Microsoft Defender for Servers Plan 2. FIM stores and analyzes collected change data in a Log Analytics workspace, making the workspace the first required component.

🟢 Correct Option: C. a Log Analytics workspace
File Integrity Monitoring in Microsoft Defender for Servers relies on a Log Analytics workspace to store collected data about file, registry, and software changes. Before FIM can be configured, a workspace must exist and be associated with the protected servers. Defender for Cloud then uses this workspace to process and display monitoring results.

🔴 Incorrect Option: A. a data collection rule (DCR)
Modern FIM uses Data Collection Rules to define what data is collected, but the DCR depends on a Log Analytics workspace as its destination. Therefore, the workspace must exist before creating and associating a DCR.

🔴 Incorrect Option: B. a private endpoint
A private endpoint provides private network connectivity to Azure services. It is not a requirement for File Integrity Monitoring and does not participate in collecting or storing FIM data.

🔴 Incorrect Option: D. a storage account
A storage account can be used for diagnostics and backups, but File Integrity Monitoring stores its data in a Log Analytics workspace, not directly in Azure Storage.

🔧 Reference:
→ Microsoft Learn — Log Analytics workspace overview — Explains the role of a Log Analytics workspace in collecting and storing monitoring data.

Explanation:

This question tests your knowledge of Windows Server built-in packet capture tools and how to filter traffic for specific protocols. It focuses on identifying the correct utility and protocol filter to capture SYN packets.

✅ Correct Options:

First dropdown: pktmon
Pktmon (Packet Monitor) is the built-in Windows Server tool for capturing and filtering network packets. The syntax pktmon filter add is specific to this utility, allowing administrators to define filters that isolate traffic matching specified criteria such as IP address and protocol.

Second dropdown: tcp
SYN packets are part of the TCP three-way handshake used to establish connections. Filtering by tcp ensures only TCP traffic is captured, which includes SYN, SYN-ACK, and ACK packets. Selecting ICMP or UDP would not capture SYN packets since those protocols do not use TCP flags.

❌ Incorrect Options:

MessageAnalyzer
MessageAnalyzer is a deprecated Microsoft tool for capturing and analyzing network traffic. It is not included in modern Windows Server versions and does not use the filter add syntax shown in the command.

netmon
Network Monitor (netmon) is a legacy packet capture tool that has been replaced by MessageAnalyzer and later by pktmon. It is not available by default on current Windows Server installations and does not support the command syntax shown.

icmp
ICMP is used for diagnostic and error-reporting messages such as ping. It does not use TCP flags or SYN packets, so filtering by ICMP would not capture the required traffic.

udp
UDP is a connectionless protocol that does not establish sessions using SYN packets. Filtering by UDP would capture unrelated traffic and miss the TCP SYN packets needed for this scenario.

🔧 Reference:
→ Microsoft Learn – Packet Monitor (Pktmon) – Confirms pktmon is the built-in Windows Server tool for packet capture and filtering.

→ Microsoft Learn – pktmon filter – Documents the pktmon filter add syntax and protocol filtering options including TCP.