Free AZ-802 Practice Test

To deploy the Azure Monitor agent (AMA) to non-Azure environments such as on-premises servers, the host machines must first be registered as Azure Arc-enabled servers. When deploying at scale across 100 on-premises Windows servers, non-interactive authentication is required during the deployment script execution. This requires providing the client ID and client secret of an Azure Active Directory (Microsoft Entra ID) service principal created specifically for Azure Arc onboarding. The service principal authenticates the automated installation and registers each server with Azure Arc. Once registered to Azure Arc, the Azure Monitor agent extension can be deployed and managed centrally from the Azure portal.

B. Storage account credentials are used for storage access and do not authenticate Azure Arc onboarding or agent installation on hybrid machines.
C. Azure SQL Database connection strings provide database access and play no role in server onboarding or monitoring agent deployment.
D. Workspace ID and workspace keys were required for the legacy Log Analytics agent (MMA), whereas Azure Monitor agent relies on Azure Arc identity.

- Microsoft Learn: "Azure Monitor Agent overview - Prerequisites for hybrid environments", Section: "Non-Azure machines", Doc ID: azure-monitor-agent-overview.

- Microsoft Learn: "Connect hybrid machines to Azure at scale using a service principal", Section: "Create a Service Principal for onboarding at scale", Doc ID: connect-at-scale-service-principal.

To block users from uploading specific file types, such as video files with the .mov extension, to shared folders on Windows Server, you should create a file screen. File screens are a core feature of the File Server Resource Manager (FSRM) role service. By configuring an active file screen, you can explicitly prevent users from saving unauthorized file types to designated volumes or directory trees. You can define a file group that includes the .mov extension and apply it to the shared folders. This approach minimizes administrative effort because it natively targets file extensions at the file system level without requiring complex identity-based rules or external compliance engines.

A. Dynamic Access Control (DAC) is used for permission management based on user claims and file classifications, not for blocking specific file extensions.
C. Central access rules are components of DAC used for authorization, which cannot natively block file uploads based solely on extensions.
D. Data loss prevention (DLP) is typically used in Microsoft 365 to prevent the sharing of sensitive information, not for basic file extension blocking on local file servers.

1. Microsoft Learn. "File Screening Management." Windows Server Storage Documentation. Section: Create a File Screen.

2. Microsoft Learn. "File Server Resource Manager (FSRM) overview." Section: Features.

The netdom query fsmo command is a built-in Windows Server command-line utility specifically designed to locate and display the domain controllers holding the Flexible Single Master Operations (FSMO) roles within an Active Directory domain or forest. When executed from an elevated command prompt, it queries the directory and outputs the names of the servers currently holding the Schema Master, Domain Naming Master, PDC Emulator, RID Pool Manager, and Infrastructure Master roles. Because the PDC emulator is explicitly listed in the output of this command, running it directly satisfies the goal of identifying which server holds the PDC emulator role for the contoso.com domain.

[B] No is incorrect because the provided command accurately and effectively retrieves the FSMO role holders, including the PDC emulator, fulfilling the stated requirement.

Microsoft Learn: "Netdom query" - Windows Server command reference. Section: Syntax and Parameters (fsmo).

Microsoft Learn: "Active Directory FSMO roles in Windows" (Article ID: 223346). Section: Determine FSMO role holders.

To ensure that domain member servers perform DNSSEC validation for a specific namespace (in this case, fabrikam.com), you must configure the Name Resolution Policy Table (NRPT). The NRPT is managed centrally via Group Policy Objects (GPOs) and allows administrators to define specific rules for DNS domains. By adding an NRPT rule for fabrikam.com, you instruct the DNS clients on the member servers to require DNSSEC validation for any queries directed at that domain. Distributing this configuration via a GPO ensures that all member servers consistently enforce the validation requirement without needing manual configuration on each individual machine.

A: Adding a trust anchor on Server1 only configures the DNS server to validate DNSSEC, but it does not force the member servers (clients) to request validation. B: Trust anchors are configured on DNS servers to validate responses, not on standard member servers acting as DNS clients. Clients rely on the NRPT for validation rules. D: Network List Manager policies are used to identify networks and configure network-specific settings like firewall profiles, not to enforce DNSSEC validation rules for clients.

- Microsoft Learn, "The Name Resolution Policy Table (NRPT)", Windows Server DNS documentation. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn593632(v=ws.11)

- Microsoft Learn, "Deploy DNSSEC with Windows Server", Windows Server documentation. https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/deploy-dnssec-with-windows-server

To implement alerts for on-premises Domain Controllers using Azure, you must establish a data ingestion pipeline. This is achieved by installing the Azure Monitor agent (AMA) on the target servers (Domain Controllers). The agent collects guest OS performance data and event logs defined by Data Collection Rules (DCRs). The required destination for this data, which supports the log queries necessary for configuring alerts, is an Azure Log Analytics workspace. Storage accounts are used for archiving, and SQL databases are not used for log ingestion in this monitoring context.

Microsoft Learn. "Azure Monitor agent overview - Azure Monitor." Learn.microsoft.com, https://learn.microsoft.com/en-us/azure/azure-monitor/agents/azure-monitor-agent-overview. Accessed 26 Jan. 2026.

Microsoft Learn. "Create a Log Analytics workspace in the Azure portal." Learn.microsoft.com, https://learn.microsoft.com/en-us/azure/azure-monitor/logs/quick-create-workspace. Accessed 26 Jan. 2026.

Microsoft Learn. "Collect event and performance counters from non-Azure machines with the Azure Monitor agent." Learn.microsoft.com, https://learn.microsoft.com/en-us/azure/azure-monitor/agents/azure-monitor-agent-windows-client. Accessed 26 Jan. 2026.

To implement Storage Spaces with tiered storage (utilizing both SSDs and HDDs for performance), the correct workflow is:

1. Create a storage pool: Group the eight physical disks (4 SSDs and 4 HDDs) into a single logical pool.
2. Create a virtual disk: Create a virtual disk from the available storage in the pool. To achieve the "fastest read performance for frequently used files," you would configure Storage Tiers (using SSDs for the Performance tier and HDDs for the Capacity tier) during this step.
3. Create a simple volume: Once the virtual disk is created, it is presented to the operating system as a standard disk. You then create a simple volume on this disk to assign a drive letter and format it for use.

Microsoft Learn. (2023). Deploy Storage Spaces on a stand-alone server. Retrieved from https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/deploy-standalone-storage-spaces

Reference Details: See section "Step 1: Create a storage pool" and "Step 2: Create a virtual disk". The guide outlines the sequential process of creating a pool, then a virtual disk, and finally a volume.

Microsoft Learn. (2022). Storage Spaces overview. Retrieved from https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/overview

Reference Details: This document explains the architecture where "Storage pools" are the foundation, "Virtual disks" (Storage Spaces) are created from pools, and "Drives" (volumes) are created on virtual disks. It also details "Storage tiers" for performance optimization.

To implement Azure File Sync, you must follow a specific deployment hierarchy.

1. Deploy the Azure Storage Sync service: This is the top-level Azure resource required to manage sync relationships. It must be created first.
2. Install/Register Agent (Provided Step): The agent enables the server to communicate with the Storage Sync Service.
3. Create a sync group: After registering the server, you define the sync topology by creating a sync group. This step also involves defining the cloud endpoint (the Azure file share).
4. Add a server endpoint: Finally, you add the server endpoint to the sync group. This maps the specific local folder path on the registered server to the cloud endpoint, enabling synchronization.

Microsoft Learn. Deploy Azure File Sync. Retrieved from https://learn.microsoft.com/en-us/azure/storage/file-sync/file-sync-deployment-guide

See section "Deploy the Storage Sync Service": "The deployment of Azure File Sync starts with placing a Storage Sync Service resource into a resource group of your selected subscription."

See section "Create a sync group and a cloud endpoint": "A sync group defines the sync topology for a set of files... A sync group must be created."

See section "Create a server endpoint": "A server endpoint represents a specific location on a registered server, such as a folder on a server volume."

To enable replication for a Hyper-V cluster to Azure (specifically in a non-VMM scenario implied by "Hyper-V site"), the sequence is critical. First, Create an Azure Recovery Services vault to store metadata and backups. Second, Create a Hyper-V site within that vault; this acts as the logical container for your on-premises hosts. Third, Install and register Azure Site Recovery Providers on the Hyper-V hosts; during registration, you link the hosts to the vault and the specific Hyper-V site created earlier. Finally, Create and associate replication policies (defining RPO and retention) to the site before you can enable replication for individual VMs. The Azure Connected Machine agent is used for Azure Arc management, not the core ASR replication data flow.

Microsoft Learn: "Set up disaster recovery of on-premises Hyper-V VMs to Azure" - Section: Create a Recovery Services vault.

Confirms Step 1: "In the Azure portal... create a Recovery Services vault."

Microsoft Learn: "Set up disaster recovery of on-premises Hyper-V VMs to Azure" - Section: Set up the source environment.

Confirms Step 2 & 3: "To set up the source environment, you create a Hyper-V site... Then, you download and install the Azure Site Recovery Provider... on each host, and register the Hyper-V site in the vault."

Microsoft Learn: "Set up disaster recovery of on-premises Hyper-V VMs to Azure" - Section: Set up a replication policy.

Confirms Step 4: "Create a new policy... it's automatically associated with the specified Hyper-V site."

Microsoft Learn: "Prepare on-premises Hyper-V servers for disaster recovery to Azure" - Section: Prepare Infrastructure.

Confirms Sequence: Validates the workflow of Vault -> Site -> Provider -> Policy.