Microsoft AZ-801: Azure Arc and Hybrid Server Management — Study Guide

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Part of the Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Azure Arc brings non-Azure servers—on-premises or in other clouds—under the same control plane as native Azure resources. Arc-enabled servers surface as first-class Azure resources so you can apply Azure Policy, manage extensions, collect telemetry with Azure Monitor Agent, orchestrate patching with Update Management Center, and standardize with Azure Automanage. Mastery of onboarding patterns, agent and network requirements, role-based access control (RBAC), and at-scale governance is essential to operate hybrid fleets securely and consistently.

Azure Arc-enabled servers: onboarding, prerequisites, networking, RBAC, and secure access

Onboarding connects a machine to Azure by installing the Azure Connected Machine agent (azcmagent), which registers a server into a chosen subscription, resource group, and region.

• Scripted interactive onboarding is the fastest way to start. From the Azure portal, generate the “Add servers” script and run it locally. The script downloads and installs the agent, then uses device code flow to authenticate your user to Azure Resource Manager and create the ConnectedMachine resource.
• Service principal–based onboarding is the recommended production method. Create a Microsoft Entra app registration and least-privilege credential with the Azure Connected Machine Onboarding role scoped to the target resource group. Pass the service principal ID and secret to the onboarding script to enable unattended and at-scale deployment via your existing tools (Configuration Manager, Group Policy, Ansible, or custom automation).
• At-scale enablement with Azure Policy focuses on post-onboarding standardization. Azure Policy cannot install the Arc agent on non-Azure machines, but once machines are Arc-connected, assign policies to automatically deploy required extensions (Azure Monitor Agent, Dependency Agent, Custom Script) and guest configuration baselines to thousands of servers with drift detection and remediation. This is the minimal-effort approach to onboard Arc servers into services such as Microsoft Sentinel or VM insights, as tested.

Supported operating systems include Windows Server 2012 R2, 2016, 2019, and 2022, and common enterprise Linux distributions such as Ubuntu LTS (18.04+), RHEL 7–9, SLES 12/15, Oracle Linux 7/8/9, CentOS 7, and Amazon Linux 2. Always verify precise versions and kernel requirements in the current documentation before large-scale rollout.

Agent prerequisites are straightforward: TLS 1.2, outbound HTTPS (TCP 443), sufficient disk and memory for agent cache and extensions, a stable machine clock, and administrator/root privileges to install. For proxies, the agent supports system proxy on Windows (WinHTTP) and an explicit proxy on both platforms. Configure azcmagent to use a proxy with azcmagent config set proxy.url=https://user:pass@proxy:port or leverage netsh winhttp set proxy on Windows. If your environment uses TLS inspection, import the proxy’s trusted root CA into the machine store so the agent can validate Azure endpoints.

Firewall and egress allowlists must permit outbound 443 to Microsoft Entra ID (for authentication), Azure Resource Manager, and regional Arc services. If you will use Update Management Center and Automanage, also allow Windows Update/Microsoft Update and your Linux distribution repositories, plus content delivery endpoints that distribute packages. Arc requires no inbound firewall openings; all control traffic originates from the server to Azure.

RBAC for Arc-enabled servers follows Azure’s model. Use built-in roles to separate duties:

• Azure Connected Machine Onboarding allows creating ConnectedMachine resources via service principals while preventing broader modification rights.
• Azure Connected Machine Resource Administrator manages the Arc server resource and its extensions without granting subscription-wide permissions.
• Azure Connected Machine User Login and Azure Connected Machine Administrator Login control interactive access when enabling Azure AD–based login over SSH (Linux) or RDP/WinRM (Windows). Organize Arc machines into resource groups that reflect environment (Prod/NonProd), geography, business unit, or patch ring. Scope policies, locks, and role assignments at resource group or management group level to simplify governance.

Secure SSH access without a public IP is supported through Arc’s just-in-time tunneling. Install the AADSSHLoginForLinux extension to enable Entra ID–based authentication and map users/groups to local principals. Authorized users with the appropriate login role can run az ssh arc –resource-group RG –name Server01 to establish an ephemeral, outbound TLS tunnel to the server’s SSH daemon—no inbound port, VPN, or bastion required. Apply Conditional Access and Privileged Identity Management to time-bound the login roles.

Governance and configuration at scale: Azure Policy guest configuration and Automanage

Guest configuration is Azure Policy’s in-guest auditing and configuration capability for Arc. Built-in policies cover common baselines such as ensuring the Azure Monitor Agent is installed, auditing password policies, enforcing BitLocker or FIPS mode on Windows where supported, or requiring specific syslog facilities on Linux. Assign these policies at scale to Arc scopes, and the platform deploys the Guest Configuration extension as needed. For custom policies, author a DSC-based guest configuration package that expresses the desired state (for example, a hardened SSHD configuration or Windows Firewall rules), publish it as a custom policy definition, then assign it to your Arc scope.

Remediation tasks transform audits into action. Policies with DeployIfNotExists or Modify effects can create or change configuration, and you can trigger On-demand remediation to bring existing machines into compliance. For recurring drift, enable automatic remediation so the policy engine re-applies the desired state. Track compliance posture per policy, per machine, and per scope in the Compliance blade and export evidence to regulators from the same UI.

Azure Automanage for Arc-enabled servers operationalizes “machine best practices.” Select a configuration profile appropriate for Dev/Test or Production and the platform onboards the machine into a curated set of services: Azure Monitor (via AMA and a VM insights profile), Update Management Center with defined maintenance windows, Change Tracking and Inventory, Microsoft Defender for Cloud plan enablement, and core OS security baselines. Automanage continuously detects drift from the chosen profile and remediates where supported, while providing visibility into any items that require manual intervention in non-Azure environments. Because Automanage uses Azure Policy under the hood, you can deploy profiles at scale and rely on the same compliance reporting model.

Operations and monitoring: Update Management Center, AMA and DCR, and Arc extensions

Update Management Center (UMC) is the modern, agent-light patching service for Azure and Arc machines. It continuously assesses missing security and non-security updates, surfaces compliance by severity and classification, and supports both one-time and recurring maintenance configurations. Define maintenance windows with maximum duration, reboot behavior (Never, If required, or Always), pre- and post-scripts, and dynamic targeting using Azure queries and tags so new Arc machines that match the criteria are automatically included. For Windows, UMC sources from Windows Update/Microsoft Update or WSUS if configured; for Linux, from the configured package repositories. Use compliance reports to track percentage patched by scope, view failures with granular error codes, and export data for audit. Because UMC does not depend on Azure Automation and the legacy MMA, it is the strategic path forward for patch orchestration.

The Azure Monitor Agent (AMA) is the unified telemetry pipeline for Arc-enabled servers. Rather than hardcoding a workspace on the machine, you define Data Collection Rules (DCRs) that describe:

• What to collect: Windows event logs, Linux syslog facilities and severities, performance counters, and change tracking signals.
• Where to send it: one or more Log Analytics workspaces, Azure Monitor Metrics, and optionally Event Hubs.
• How to transform: optional data shaping before ingestion. Associate DCRs at the resource, resource group, subscription, or management group scope. This decouples configuration from the machine and makes it trivial to move a machine between workspaces or collect different data in different environments. VM insights on Arc now uses AMA with the VM insights DCR profile for performance; for dependency maps and process topology, install the Dependency Agent.

Extensions are the delivery mechanism for in-guest capabilities. Manage them from the Arc server’s Extensions blade, CLI, or Policy:

• Microsoft Monitoring Agent (MMA) is legacy and retired for most solutions; only use it if a dependency has not yet moved to AMA.
• Azure Monitor Agent (AMA) is the current default for logs and metrics; pair it with DCRs.
• Dependency Agent provides service and process maps, required for VM insights map until its full replacement is complete.
• Custom Script Extension (Windows/Linux) executes scripts at scale for bootstrap or corrective actions when Policy remediation cannot express the desired change.
• AADSSHLoginForLinux and AADLoginForWindows enable Entra ID login. Other common extensions include Defender for Endpoint and configuration management clients. Use Azure Policy to ensure required extensions are present and healthy. Extension updates, rollbacks, and status are visible in the resource and in Activity log for auditing.

Inventory, compliance, and reporting with Azure Resource Graph

Azure Resource Graph (ARG) queries return near-real-time inventory and compliance state across all Arc-enabled servers without agents. Use it to drive CMDB synchronization, tag hygiene, and scope selection for policy and patching. Common patterns include:

• Hybrid inventory by OS and location:

Resources
| where type == "microsoft.hybridcompute/machines"
| project name, resourceGroup, location, osName = properties.osName, osVersion = properties.osVersion, status = properties.status

• Sentinel/AMA readiness:

Resources
| where type == "microsoft.hybridcompute/machines"
| extend hasAMA = todynamic(properties.extensions) has_any (x: x.name =~ "AzureMonitorWindowsAgent" or x.name =~ "AzureMonitorLinuxAgent")
| project name, hasAMA

• Tag-based reporting and patch ring targeting:

Resources
| where type == "microsoft.hybridcompute/machines"
| project name, patchRing = tags.PatchRing, owner = tags.Owner
| summarize count() by patchRing

• Policy compliance rollup:

PolicyResources
| where type == "microsoft.policyinsights/policystates"
| summarize nonCompliant = countif(isCompliant == false) by resourceId

These queries underpin dynamic scopes in Update Management Center, Automanage assignments, and dashboards. Standardize a minimal tag set (Environment, PatchRing, BusinessUnit, Owner) at onboarding so ARG remains actionable.

Practical Problem Scenario

Contoso Ltd. has 600 on-premises Windows Server and Linux VMs hosted across two datacenters, managed by Configuration Manager and Ansible. Leadership requires standardized monitoring, monthly patching with strict Saturday maintenance windows, Sentinel onboarding, and secure engineer SSH access without exposing public IPs. They also want compliance evidence for auditors and minimal ongoing admin effort.

1. Prepare least-privilege access

• Create a service principal scoped to the RGs that will contain Arc machines and assign the Azure Connected Machine Onboarding role. This enables unattended onboarding through existing tools without granting broad rights. Why: Service principal–based onboarding scales and satisfies least privilege.

2. Onboard machines with automation

• Use the generated Arc onboarding script with the service principal in Configuration Manager for Windows and Ansible for Linux to install azcmagent and register each server into the appropriate RG (tagged with Environment and PatchRing). Why: Reuses existing deployment tooling for rapid, consistent rollout and embeds tags for downstream governance.

3. Establish network and proxy egress

• Ensure outbound 443 to Entra ID, Azure Resource Manager, Arc regional endpoints, Windows Update/Microsoft Update, and distro repos. Configure azcmagent proxy settings and import the TLS inspection root CA where required. Why: Guarantees agent and extension health, update retrieval, and avoids connectivity drift.

4. Enforce baselines with Azure Policy guest configuration

• Assign built-in policies to deploy the Guest Configuration extension, AMA, and Dependency Agent. Apply a custom guest configuration package to harden SSH and RDP settings. Enable automatic remediation for critical settings. Why: Policy expresses desired state at scale, provides drift detection, and repairs deviations.

5. Standardize operations with Automanage

• Assign the Automanage for Arc Production profile to Prod RGs and Dev/Test profile to non-production. Review any items flagged as manual for non-Azure. Why: Automanage continuously applies best practices with minimal operator effort.

6. Configure monitoring and Sentinel onboarding

• Create DCRs to collect Windows SecurityEvent, Syslog auth facilities, and performance counters to a central Log Analytics workspace connected to Microsoft Sentinel. Use Azure Policy to associate DCRs with all Arc machines and to deploy the Sentinel solution packs as needed. Why: AMA + DCR decouple collection from machines and Azure Policy provides the minimal-effort onboarding method validated in exam scenarios.

7. Orchestrate patching with Update Management Center

• Define monthly recurring maintenance configurations per PatchRing tag with a 4-hour Saturday window, reboot if required, and notification hooks. Use dynamic scopes based on tags so new machines are auto-included. Why: UMC provides agent-light, tag-driven patch governance with auditable compliance reporting.

8. Enable secure SSH without public IPs

• Deploy AADSSHLoginForLinux via Policy and grant engineers Azure Connected Machine User Login on target RGs through Privileged Identity Management. Instruct engineers to use az ssh arc with just-in-time activation. Why: Arc tunneling removes the need for public ingress or jump hosts, and Entra ID plus PIM delivers least-privilege, time-bound access.

9. Report and audit with Resource Graph and Compliance

• Build ARG workbooks to show Arc inventory by environment, AMA/Dependency Agent coverage, policy compliance trends, and UMC patch compliance by PatchRing. Export compliance evidence monthly. Why: ARG and the Policy/UMC compliance planes centralize evidence and reduce audit overhead.

By combining service principal–based onboarding, Policy-driven extension and guest configuration deployment, Automanage profiles, AMA with DCRs, UMC patching, Arc SSH, and Resource Graph reporting, Contoso achieves secure, consistent, and auditable hybrid server management with minimal manual touch.

← Active Directory Domain Services Security · All domains · Encryption →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →