Azure Arc: Managing Hybrid and Multicloud Resources

Azure Arc extends Azure’s management tools — Azure Policy, tagging, role-based access control, and monitoring — to resources running outside Azure, including on-premises datacenters, edge locations, and other public clouds. It does this by projecting each external resource into Azure Resource Manager with its own resource ID, so it can be governed alongside native Azure resources through the same tools. Nothing about the workload itself moves; only the management plane extends outward to reach it.

The core idea: project, don’t migrate

The single most important thing to understand about Azure Arc is what it deliberately does not do. It does not migrate a server, database, or Kubernetes cluster into Azure. It does not physically relocate anything, convert a physical machine into an Azure virtual machine, or require an application be rewritten as a container before onboarding. The workload keeps running exactly where it already sits — an on-premises datacenter, an edge site, a competitor’s cloud — for as long as you want it to.

What Arc does instead is register that resource with Azure Resource Manager, giving it a resource ID just like a native Azure VM or storage account has. Once that resource ID exists, the full weight of Azure’s governance tooling can reach it: Azure Policy assignments, resource tags, RBAC role assignments, and monitoring through Azure Monitor all become available for that non-Azure resource, exactly as they would for something running natively in Azure. This is why Arc is often described as extending Azure’s control plane rather than extending Azure’s compute — it’s a management capability, not a hosting capability.

What Azure Arc can manage

Arc covers three main resource categories outside Azure:

• Servers. Physical or virtual machines running on-premises (including on Hyper-V or VMware), at the edge, or in another public cloud become Azure Arc-enabled servers after you install the Azure Connected Machine agent on them. This agent is the piece of software that actually registers the machine with Azure and continuously reports its status back, and it’s a required prerequisite — without it, Arc has no way to discover or represent that server in Azure at all.
• Kubernetes clusters. Any CNCF-conformant Kubernetes cluster running outside Azure Kubernetes Service — on-premises, at the edge, or on another cloud provider — can be connected as Azure Arc-enabled Kubernetes, appearing in the Azure portal alongside AKS clusters. This includes support for GitOps-based configuration, letting you manage cluster configuration declaratively from a Git repository across every connected cluster regardless of where it physically runs.
• Data services. SQL Server and certain other data workloads running on-premises or in other clouds can be onboarded as Azure Arc-enabled data services, extending Azure-native capabilities such as centralized monitoring, automated compliance assessment, and vulnerability scanning to databases that, for regulatory or data-residency reasons, cannot move to the cloud.

Notably, Arc is scoped to infrastructure and data workloads — it has no resource type for something like a mobile device’s local application data, and it has no relationship to Microsoft 365 mailboxes, which are managed through entirely separate admin tools.

Why organizations reach for Arc

The typical scenario driving Arc adoption looks the same across industries: a company runs workloads split across on-premises hardware, Azure, and at least one other public cloud — going beyond the public, private, and hybrid cloud deployment models Azure supports natively (often from an acquisition or a deliberate multicloud strategy), and leadership wants one consistent governance story — the same policy definitions, the same tagging taxonomy, the same access control model — applied everywhere, without duplicating tooling per environment and without physically consolidating everything into Azure. Healthcare and financial services organizations frequently hit this exact requirement because regulatory data-residency rules prohibit moving certain workloads at all, which rules out a straightforward migration and makes Arc’s “manage in place” model the only fit.

Once a server, cluster, or data service is Arc-projected, a single Azure Policy assignment can evaluate compliance — such as flagging missing required tags — across every environment in the set from one place, instead of maintaining separate governance tooling for on-premises, Azure, and each additional cloud. When that policy needs to apply across many subscriptions at once rather than a single one, it rides the same management group hierarchy used for native Azure governance. Because Arc and Azure Policy are included capabilities of an Azure subscription, this also tends to satisfy a “minimal new licensing spend” constraint that a dedicated third-party multicloud governance suite would not.

What Arc is not a substitute for

Arc is easy to confuse with tools that sound adjacent but solve a different problem. Azure Migrate assesses and moves workloads into Azure — the opposite of Arc’s “leave it where it is” model, and the two are sometimes deliberately contrasted in exam scenarios where migration is explicitly not wanted. Azure Site Recovery replicates workloads for disaster recovery failover, which is unrelated to day-to-day policy and governance. And Azure Reserved Instances, a compute purchasing commitment, have no relationship to Arc registration at all — connecting a server to Arc doesn’t convert its licensing or grant it free compute quota.

How the AZ-900 exam tests this

• “Unified governance without moving workloads.” The exam’s signature Arc scenario describes mixed infrastructure (on-premises, another cloud, sometimes both) and a requirement for the same policy, tags, or RBAC everywhere, with an explicit constraint that nothing gets migrated. Azure Arc is the answer whenever “consistent governance” and “don’t move it” appear together.
• Distinguishing Arc from Azure Migrate. Any answer choice that involves physically moving, relocating, or migrating the workload is disqualified the moment the stem says workloads must stay in place — that’s the fastest way to eliminate Azure Migrate and Azure Site Recovery as distractors.
• The prerequisite for server onboarding. A question may ask what must be installed before a server is projected into Azure — the answer is the Azure Connected Machine agent, not a migration appliance or a backup agent.
• Resource type recognition. Expect questions on which resource types Arc supports (servers, Kubernetes clusters, data services) versus which it doesn’t (native Azure VMs that are already in Azure need no Arc registration at all, and things like Microsoft 365 mailboxes are out of scope entirely).
• “What happens to the workload” checks. After a resource is Arc-enabled, a follow-up question often asks where the workload actually runs. The answer is always: unchanged, in its original location — Arc only extends the management plane.

Quick reference

• Azure Arc projects non-Azure resources (servers, Kubernetes clusters, data services) into Azure Resource Manager so they get a resource ID and can be governed like native Azure resources.
• Arc never migrates or relocates a workload — the resource keeps running exactly where it already is.
• Servers require the Azure Connected Machine agent to be installed before they can be Arc-enabled.
• Once projected, a resource can receive Azure Policy assignments, tags, and RBAC role assignments through Azure’s normal governance tools.
• Azure Arc-enabled Kubernetes supports GitOps-based configuration across clusters regardless of where they run.
• Azure Arc-enabled data services extend monitoring and compliance features to on-premises SQL Server and similar workloads that can’t move for regulatory reasons.
• Don’t confuse Arc with Azure Migrate (which moves workloads) or Azure Site Recovery (which replicates for disaster recovery) — Arc’s entire value is managing resources in place.

Once a hybrid resource is Arc-enabled, the policies you assign to it work the same way they do for native resources — see Azure Policy and governance for how those assignments and compliance evaluations actually work, and Azure RBAC vs. Conditional Access for how access control extends across the same projected resource set. To see how these hybrid-management scenarios show up on the real exam, try AZ-900 practice questions built around Arc’s onboarding and governance patterns.