This chapter covers Azure Arc, a pivotal service for hybrid and multi-cloud management. As part of the Azure Management Governance domain (AZ-900 objective 3.4), this topic tests your understanding of how Azure extends its management capabilities to non-Azure environments. This domain typically accounts for about 15-20% of the exam. By the end of this chapter, you will grasp what Azure Arc is, how it works, its key use cases, and exactly what the AZ-900 expects you to know.
Jump to a section
Imagine you run a large hotel with multiple buildings: a main building, a separate conference center, and a remote annex. Each building has its own lighting system, some from different manufacturers, and each has its own control panel. To manage all lights, you must walk to each panel. Now consider a universal remote that can control every light from a single app on your smartphone, regardless of building or manufacturer. Azure Arc is that universal remote for IT infrastructure. It projects Azure's control plane—the set of management APIs and policies—onto any server, anywhere: on-premises, in other clouds, or at the edge. The mechanism: you install the Azure Connected Machine agent on each non-Azure server. This agent establishes an outbound connection to Azure Arc, registering the server as a resource in Azure Resource Manager. Once registered, Azure can apply Azure Policy, Azure Monitor, and role-based access control (RBAC) to that server as if it were a native Azure VM. Crucially, the agent does not allow Azure to remotely execute code or access data; it only enables management by forwarding resource metadata and compliance telemetry. The hotel manager analogy: the universal remote sends infrared signals to each light's receiver; similarly, Arc sends policy definitions and monitoring configurations to the agent, which enforces them locally. The agent is the receiver, and the Azure portal is the remote's app interface. This is not a VPN or a remote desktop—it is a management plane extension. The lights still have their own local circuits; Arc just gives you a single pane of glass to control them all.
What is Azure Arc and the Business Problem It Solves
Azure Arc is a hybrid and multi-cloud management service that extends Azure Resource Manager (ARM) and Azure management capabilities—such as Azure Policy, Azure Monitor, and role-based access control (RBAC)—to any infrastructure: on-premises servers, other public clouds (AWS, GCP), and edge devices. The core business problem is fragmentation. Organizations often run workloads across diverse environments—a physical server in a branch office, a VM in AWS, Kubernetes clusters on-premises, and SQL databases in a colocation facility. Without a unified management plane, IT teams must use separate tools for each environment, leading to inconsistent policies, security gaps, and operational overhead. Azure Arc solves this by projecting Azure's control plane onto those resources, enabling centralized governance, compliance, and monitoring from the Azure portal.
How It Works: Step-by-Step Mechanism
The mechanism relies on the Azure Connected Machine agent for servers and the Azure Arc-enabled Kubernetes cluster extension for Kubernetes. For servers (Windows or Linux):
Agent Installation: You install the Azure Connected Machine agent on the target machine. The agent is a lightweight service that runs locally.
Registration: The agent initiates an outbound HTTPS connection to Azure Arc endpoints (e.g., https://*.his.arc.azure.com). You authenticate using a managed identity or service principal. The server is then registered as a resource in Azure Resource Manager, receiving a resource ID.
Policy Enforcement: You assign Azure Policy definitions to the Arc-enabled server resource. The agent periodically downloads policy assignments, evaluates the local machine's configuration, and reports compliance back to Azure. For example, a policy might require that Windows Defender be enabled; if it's off, the agent reports non-compliance.
Monitoring: You enable Azure Monitor on the Arc-enabled server. The agent collects performance metrics and log data, sending them to Log Analytics workspaces. You can then view dashboards, set alerts, and run queries across all your servers—both Azure and non-Azure.
RBAC: You assign Azure RBAC roles to the Arc resource, controlling who can manage it. The agent enforces these permissions locally via the local system account that interacts with Azure.
For Kubernetes clusters, the process is similar: you install the Arc-enabled Kubernetes agent (a Helm chart) on the cluster, which registers the cluster as a resource and enables GitOps-based configuration management.
Key Components, Tiers, and Pricing
Azure Arc has several key components:
Azure Arc-enabled servers: Manage Windows and Linux physical and virtual machines outside Azure.
Azure Arc-enabled Kubernetes: Manage Kubernetes clusters (AKS, on-prem, other clouds).
Azure Arc-enabled SQL Server: Manage SQL Server instances running anywhere.
Azure Arc-enabled data services: Run Azure data services (e.g., SQL Managed Instance, PostgreSQL Hyperscale) on any infrastructure with elastic scaling and automated patching.
Pricing: The Azure Arc control plane itself is free. You only pay for the Azure services you use on top, such as Azure Policy (per policy assignment), Azure Monitor (data ingestion and retention), and Defender for Cloud (security monitoring). For data services, there are per-core licensing costs.
Comparison to On-Premises Equivalent
Before Azure Arc, managing on-premises servers required tools like System Center Configuration Manager (SCCM) or Group Policy. SCCM provides on-premises management but lacks cloud integration, global scale, and native Azure Policy. Arc extends Azure's cloud-native governance to on-premises, allowing you to enforce policies consistently across all environments. Unlike SCCM, Arc does not require a local infrastructure server; it uses the cloud as the management hub. This reduces complexity and cost, especially for distributed environments.
Azure Portal and CLI Touchpoints
In the Azure portal, navigate to Azure Arc to see your connected resources. You can view server inventory, check policy compliance, and enable monitoring. The Azure CLI is a primary tool for onboarding:
# Install the Azure Connected Machine agent on a Linux server
azcmagent connect --resource-group "myResourceGroup" --tenant-id "myTenant" --location "eastus" --subscription-id "mySubscription" --correlation-id "myCorrelation"For Kubernetes:
# Connect an existing Kubernetes cluster to Azure Arc
az connectedk8s connect --resource-group "myResourceGroup" --name "myCluster" --location "eastus"These commands trigger the registration process and deploy the necessary agents.
Install the Azure Connected Machine Agent
On each non-Azure server, you download and install the Azure Connected Machine agent. For Windows, this is an MSI; for Linux, a script from Microsoft. The agent runs as a service (Windows) or daemon (Linux) and requires outbound HTTPS access to Azure Arc endpoints. During installation, you specify the Azure subscription, resource group, and location where the server resource will be created. This step is the foundation—without the agent, the server cannot be managed by Arc.
Register the Server with Azure Arc
After installation, you run the `azcmagent connect` command (or use the portal) to authenticate and register the server. The agent creates a managed identity for the server and establishes a secure channel to Azure. The server is assigned a resource ID in Azure Resource Manager, making it visible in the Azure portal under Azure Arc. This registration is a one-time operation; once registered, the server stays connected unless the agent is removed.
Assign Azure Policies to Arc-Enabled Servers
In the Azure portal, you create or select Azure Policy definitions and assign them to the scope that includes the Arc-enabled server resource. The agent periodically (every few hours) downloads the policy assignments and evaluates the server's configuration. For example, a policy might require that the server's firewall is enabled. The agent reports compliance status, and Azure Policy marks the server as compliant or non-compliant. This enables centralized governance across hybrid environments.
Enable Azure Monitor for Arc-Enabled Servers
To collect performance and log data, you install the Azure Monitor agent (AMA) on the Arc-enabled server. This can be done via a policy or manually. The AMA sends data to a Log Analytics workspace, where you can run queries, create dashboards, and set alerts. For example, you can monitor CPU usage across all on-premises servers from a single dashboard in Azure. This step provides visibility into resources that were previously unmonitored.
Configure Role-Based Access Control (RBAC)
Once the server is registered, you can assign Azure RBAC roles to users, groups, or service principals. For example, you can grant a helpdesk team the 'Virtual Machine Contributor' role on the Arc resource, allowing them to restart the server or apply extensions. The agent enforces these permissions by checking the user's Azure token. This ensures that only authorized personnel can manage the server, consistent with Azure's security model.
Scenario 1: Retail Chain with Distributed Branches A national retail chain operates 500+ servers in stores across the country. Each store has a local server for point-of-sale (POS) and inventory management. Previously, IT staff had to travel or use VPN to each server to apply security patches and updates. With Azure Arc, they install the Connected Machine agent on each store server. They then assign Azure Update Management policies to automatically deploy critical patches. Azure Monitor collects performance data, and alerts are set for disk space or CPU spikes. Now, a single team at headquarters can see all servers in the Azure portal, enforce compliance with corporate security policies (e.g., BitLocker enabled), and receive alerts if a server goes offline. Cost: The Arc control plane is free; they pay only for Log Analytics data ingestion (~$2.30/GB per month). The result: 80% reduction in on-site visits and faster patch deployment.
Scenario 2: Multi-Cloud Kubernetes Management
A fintech startup runs microservices on Amazon EKS (AWS) and on-premises Kubernetes clusters. They need consistent security policies and GitOps-based deployments across both environments. They enable Azure Arc on both clusters using az connectedk8s connect. They then apply Azure Policy for Kubernetes, ensuring that all pods have resource limits and that privileged containers are prohibited. They also use Azure Arc-enabled GitOps to automatically sync configurations from a Git repository to both clusters. If a developer pushes a change to the repo, Flux (the GitOps operator) applies it to both clusters automatically. This reduces configuration drift and simplifies compliance audits. The startup pays for Azure Policy assignments and GitOps configuration storage, but avoids the overhead of managing separate CI/CD pipelines.
Scenario 3: SQL Server License Optimization A manufacturing company has 200 SQL Server instances running on-premises and in AWS. They want to use Azure's Hybrid Benefit to reduce licensing costs but need visibility into which instances are covered. They enable Azure Arc-enabled SQL Server on each instance. The Arc agent inventories SQL Server instances, including version, edition, and license type. They then use Azure Policy to enforce that all SQL Servers use Azure Hybrid Benefit where eligible. The policy automatically tags compliant instances. The company saves 40% on SQL Server licenses by moving to a pay-as-you-go model for non-covered instances. Without Arc, they would have to manually track licenses across environments, risking non-compliance.
What goes wrong when set up incorrectly? If the agent is not installed with the correct permissions (e.g., missing outbound HTTPS), the server never registers. If policies are assigned to the wrong scope, some servers may be missed. If the Azure Monitor agent is not deployed, no data is collected. Overly restrictive firewall rules can break the agent's communication, resulting in 'disconnected' status. Also, if RBAC is not configured, anyone with access to the Azure subscription could manage the server, posing a security risk.
Objective 3.4: Describe the benefits and usage of Azure Arc
The AZ-900 exam tests your understanding of Azure Arc at a conceptual level. You won't need to install the agent or write CLI commands, but you must know:
What Azure Arc is: a hybrid/multi-cloud management service that extends Azure management to any infrastructure.
What it can manage: servers (Windows/Linux), Kubernetes clusters, SQL Server, and Azure data services.
Key benefits: centralized governance, consistent policy enforcement, unified monitoring, and compliance across on-premises, multi-cloud, and edge.
How it relates to Azure Resource Manager: Arc-registered resources become ARM resources, enabling RBAC, Policy, and Tags.
Common Wrong Answers and Why Candidates Choose Them
"Azure Arc migrates workloads to Azure." Wrong. Arc does not migrate; it manages resources where they are. Candidates confuse 'extend management' with 'migrate.'
"Azure Arc is a VPN or direct connection to Azure." Wrong. Arc uses an agent that communicates outbound; it does not create a network tunnel. Candidates see 'hybrid' and think of connectivity services like ExpressRoute.
"Azure Arc only works with on-premises servers." Wrong. It also works with other clouds and edge devices. Candidates assume 'hybrid' means only on-premises.
"Azure Arc requires Azure Stack." Wrong. Azure Arc is independent of Azure Stack. Candidates conflate hybrid cloud products.
Specific Terms and Values
The agent is called the Azure Connected Machine agent (for servers).
For Kubernetes, it's Azure Arc-enabled Kubernetes.
The registration process creates a resource in Azure Resource Manager.
Arc supports Azure Policy, Azure Monitor, Azure RBAC, and Azure Defender for Cloud.
Arc is free; you pay only for the Azure services used.
Edge Cases and Tricky Distinctions
Azure Arc does not provide compute or storage; it only manages existing resources. You cannot run Azure VMs on-premises via Arc (that's Azure Stack HCI).
Arc-enabled servers do not require a domain join; they use Azure AD authentication via the agent.
The agent must have outbound connectivity to Azure; inbound ports are not required.
Arc can manage resources in any region where Arc is available, regardless of the resource's physical location.
Memory Trick Think of ARC as Azure Resource Connector. It connects non-Azure resources to Azure's management plane. If a question asks about managing servers in a branch office or AWS, think Arc. If it asks about running Azure services on-premises, think Azure Stack.
Azure Arc extends Azure Resource Manager and management services to any infrastructure: on-premises, multi-cloud, and edge.
The Azure Connected Machine agent is installed on servers to register them with Arc.
Arc-enabled resources appear in the Azure portal and can be managed with Azure Policy, Azure Monitor, RBAC, and Tags.
Azure Arc does not migrate workloads; it manages them where they are.
The Arc control plane is free; you pay only for the Azure services you use (e.g., Log Analytics, Policy).
Arc supports servers (Windows/Linux), Kubernetes clusters, SQL Server, and data services.
Outbound HTTPS connectivity from the agent to Azure is required; no inbound ports are needed.
Azure Arc is distinct from Azure Stack; Arc manages, Stack provides infrastructure.
On the AZ-900 exam, remember that Arc is about centralized management, not migration or connectivity.
Common exam scenario: a company with on-premises servers wants to apply consistent policies and monitoring – the answer is Azure Arc.
These come up on the exam all the time. Here's how to tell them apart.
Azure Arc
Manages existing servers and clusters anywhere (on-prem, other clouds).
No compute or storage provided; uses existing infrastructure.
Lightweight agent-based registration.
Free control plane; pay for Azure services used.
Ideal for governance and monitoring of distributed resources.
Azure Stack HCI
Provides Azure-consistent hyperconverged infrastructure on-premises.
Delivers Azure IaaS and PaaS services locally.
Requires dedicated hardware validated by Microsoft.
Licensed per core (Azure Stack HCI subscription).
Ideal for running Azure VMs and containers on-premises with low latency.
Mistake
Azure Arc allows Azure to remotely execute code on non-Azure servers.
Correct
The agent only reports metadata and enforces policies; it does not allow Azure to execute arbitrary code. The agent itself can run scripts via custom script extensions, but only if explicitly assigned by an admin.
Mistake
Azure Arc requires a VPN or ExpressRoute to function.
Correct
Arc uses outbound HTTPS connections from the agent to Azure. No inbound ports or VPN are required. The agent initiates all communication.
Mistake
Azure Arc can only manage Windows servers.
Correct
Azure Arc supports both Windows and Linux servers, as well as Kubernetes clusters, SQL Server, and data services.
Mistake
Azure Arc is a replacement for Azure Stack.
Correct
Azure Stack provides Azure services on-premises (IaaS/PaaS). Azure Arc extends management to existing resources. They are complementary, not replacements.
Mistake
Azure Arc automatically migrates data to Azure.
Correct
Arc does not move data; it only collects metadata and telemetry. Data stays on the source server unless you explicitly configure data replication.
Yes, you need to install the Azure Connected Machine agent on each server you want to manage with Arc. The agent is available for Windows and Linux and can be installed via a script or manual download. It registers the server with Azure and enables management features like Azure Policy and Azure Monitor.
The Azure Arc control plane itself is free of charge. However, you will incur costs for any Azure services you enable on top of Arc, such as Azure Policy (per assignment), Azure Monitor (data ingestion and retention), and Defender for Cloud (security monitoring). For data services, there are per-core licensing costs.
Yes, Azure Arc can manage servers and Kubernetes clusters running in AWS, Google Cloud, or any other cloud provider. As long as you can install the Azure Connected Machine agent on the server or deploy the Arc-enabled Kubernetes agent on the cluster, you can manage it from Azure.
No, Azure Arc does not require a VPN or ExpressRoute. The agent initiates outbound HTTPS connections to Azure endpoints. As long as the server has outbound internet access to those endpoints, Arc will work. Inbound firewall rules are not needed.
Azure Arc extends Azure management to existing infrastructure, while Azure Stack provides Azure services on-premises. Azure Stack HCI gives you Azure-consistent hyperconverged infrastructure to run VMs, while Arc manages those VMs alongside other non-Azure resources. They are complementary: you can use Arc to manage Azure Stack resources as well.
No, Azure Arc is not a migration tool. It manages servers where they are. For migration, you would use Azure Migrate, which assesses and migrates workloads to Azure. Arc can be used to manage servers during and after migration for a consistent experience.
If the agent loses connectivity to Azure, the server will appear as 'disconnected' in the Azure portal. Policies and monitoring will not be enforced or collected until connectivity is restored. The agent will automatically retry and reconnect when possible. You can also manually re-register the server.
You've just covered Azure Arc — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?