This chapter covers Azure Arc, a critical hybrid and multi-cloud management solution that extends Azure's control plane to any infrastructure. For the AZ-305 exam, understanding Azure Arc is essential for designing governance, security, and operational consistency across on-premises, edge, and multi-cloud environments. Approximately 10-15% of exam questions in the 'Design identity, governance, and monitoring solutions' domain touch on Azure Arc scenarios, often focusing on its capabilities, prerequisites, and use cases.
Jump to a section
Imagine you are a property manager overseeing 50 buildings across different cities. Each building has its own security system, lighting control, and HVAC—each with a different brand and interface. To manage them, you would need to visit each building physically or use multiple apps. Now, consider a universal remote control that can communicate with any brand's system using a standard protocol. This remote doesn't replace the local systems; it just sends commands and receives status updates via a common language. Azure Arc works similarly: it projects Azure's control plane (the remote) onto servers, Kubernetes clusters, and databases running anywhere—on-premises, in other clouds, or at the edge. The remote (Arc) installs a lightweight agent on each resource, which establishes an outbound connection to Azure over HTTPS (port 443). From then on, you can apply Azure policies, enable Azure Monitor, or deploy Azure services as if the resource were native to Azure. The local system still runs its own OS and applications, but now Azure can 'see' and manage it centrally. This removes the need for VPNs or direct network connectivity; the agent only needs outbound internet access. The universal remote analogy breaks down when considering that Arc also enables running Azure services locally (like Azure Arc-enabled data services), which actually deploy containers on the local cluster—more like the remote also shipping replacement parts that work with the local system.
What is Azure Arc and Why Does It Exist?
Azure Arc is a bridge that extends Azure Resource Manager (ARM) to resources outside of Azure. Traditionally, Azure could only manage resources that were natively deployed within Azure subscriptions. This created a management gap for organizations with on-premises servers, edge devices, or workloads running on other public clouds (AWS, GCP). Azure Arc solves this by projecting existing non-Azure resources into ARM, making them appear as first-class Azure resources. This enables consistent governance, policy enforcement, monitoring, and security across all environments.
From an exam perspective, Azure Arc supports four main resource types: - Azure Arc-enabled servers: Manage Windows and Linux physical servers or virtual machines running outside Azure. - Azure Arc-enabled Kubernetes: Manage Kubernetes clusters running anywhere (on-premises, edge, other clouds). - Azure Arc-enabled data services: Run Azure SQL Managed Instance and Azure PostgreSQL Hyperscale on any Kubernetes cluster. - Azure Arc-enabled VMware vSphere and System Center VMM (preview): Manage virtual machines running on these platforms.
The exam focuses heavily on the first two, especially the architecture and prerequisites.
How Azure Arc Works Internally
#### 1. Agent Installation and Registration
For Azure Arc-enabled servers, the process begins by installing the Azure Connected Machine agent on the target machine. This agent is a lightweight service that runs on the OS and communicates outbound to Azure. The agent can be installed via script (PowerShell or Bash), using Azure Policy (at scale), or manually.
Key components of the agent: - Hybrid Instance Metadata Service (HIMDS): A local endpoint that provides metadata about the machine, similar to Azure Instance Metadata Service (IMDS) for Azure VMs. - Guest Configuration (GC) service: Applies Azure Policy guest configurations. - Extension management: Enables installation of Azure VM extensions (e.g., Log Analytics agent, Dependency agent, Custom Script Extension) on the Arc-enabled machine.
During registration, the agent performs an outbound HTTPS connection to https://*.his.arc.azure.com and related endpoints. It authenticates using either a device login (interactive) or a service principal (non-interactive). The agent then creates a resource of type Microsoft.HybridCompute/machines in the specified Azure subscription and resource group.
#### 2. Control Plane Communication
Once registered, the agent maintains a persistent outbound connection to Azure using WebSocket over HTTPS (port 443). This connection is used for:
Heartbeat (every 5 minutes by default)
Policy evaluation requests
Extension deployment commands
Status reporting
The agent never listens on inbound ports; all communication is initiated from the machine. This is critical for security—no firewall rules need to open inbound access to the on-premises machine. The only requirement is outbound HTTPS access to specific Azure endpoints (listed in official documentation).
#### 3. Azure Resource Manager Integration
From ARM's perspective, the Arc-enabled server appears as a regular Azure resource. You can:
Apply Azure Policy initiatives (e.g., enforce encryption, install agents)
Enable Azure Monitor (by installing the Log Analytics extension via Arc)
Use Azure Security Center / Defender for Cloud
Tag the resource
Use Azure RBAC to control access
All of this happens without the machine being inside an Azure virtual network. The agent translates ARM API calls into local actions.
#### 4. Extensions
Azure Arc-enabled servers can host Azure VM extensions. These extensions are deployed via the agent, which downloads the extension package from Azure and installs it locally. Commonly used extensions: - Log Analytics Agent: Sends logs and performance data to a Log Analytics workspace. - Dependency Agent: Used by Azure Monitor for VMs to map dependencies. - Custom Script Extension: Runs scripts on the machine. - Azure Policy Guest Configuration: Applies OS-level configurations.
Extensions are managed just like on Azure VMs—you can add, update, or remove them via Azure portal, CLI, or PowerShell.
Key Components, Values, and Defaults
Agent version: The Connected Machine agent version is regularly updated. Check the latest version in documentation.
Heartbeat interval: Default 5 minutes. If Azure doesn't receive a heartbeat for 15 minutes, the resource status changes to 'Disconnected'. After 30 days of no heartbeat, the resource is automatically removed (soft delete).
Supported OS: Windows Server 2012 R2 and later, Ubuntu 16.04/18.04/20.04, CentOS 7, RHEL 7/8, SUSE 12/15, and others. Always verify the latest list.
Resource provider: Microsoft.HybridCompute must be registered in the subscription before onboarding.
Network endpoints: Outbound HTTPS to *.his.arc.azure.com, *.guestconfiguration.azure.com, *.agentservice.azure.com, and others. Full list in official docs.
Service principal: Required for non-interactive onboarding. Must have 'Azure Connected Machine Onboarding' role at the subscription or resource group level.
Configuration and Verification Commands
Onboarding a single server using PowerShell (Windows):
# Download agent
$msi = "https://aka.ms/AzureConnectedMachineAgent"
Invoke-WebRequest -Uri $msi -OutFile AzureConnectedMachineAgent.msi
# Install silently
msiexec /i AzureConnectedMachineAgent.msi /qn
# Connect to Azure
Connect-AzConnectedMachine -ResourceGroupName "myResourceGroup" -SubscriptionId "subscriptionId" -Location "eastus"Onboarding a Linux server:
# Download and install agent
dpkg -i azcmagent_*.deb
# Connect to Azure
azcmagent connect --resource-group "myResourceGroup" --tenant-id "tenantId" --location "eastus" --subscription-id "subscriptionId"Verify connection status:
azcmagent showOutput includes machine name, status (Connected/Disconnected), agent version, and last heartbeat.
Using Azure CLI to list Arc-enabled servers:
az connectedmachine list --resource-group "myResourceGroup"Interaction with Related Technologies
Azure Policy: Arc-enabled servers can be targeted by Azure Policy initiatives for guest configuration. For example, a policy can enforce that the Log Analytics agent is installed on all Arc servers.
Azure Monitor: After installing the Log Analytics extension via Arc, you can collect performance counters, event logs, and use VM insights.
Microsoft Defender for Cloud: Arc servers can be onboarded to Defender for Cloud to get security recommendations and threat detection.
Azure Update Management: You can manage updates for Arc servers using Azure Automation Update Management or Azure Update Manager.
Azure Automanage: Supports Arc-enabled servers for best practices configuration.
For Azure Arc-enabled Kubernetes, the architecture differs: a cluster extension (like Azure Arc agent) is deployed as a Helm chart into the cluster. This agent connects to Azure and enables GitOps, policy enforcement, and monitoring. The exam expects you to know that Arc-enabled Kubernetes requires a supported Kubernetes distribution (e.g., AKS on Azure Stack HCI, Google Kubernetes Engine, Amazon EKS, OpenShift) and that the cluster must be reachable from the Arc agent (outbound connectivity).
1. Install the Connected Machine Agent
On each target server, download and install the Azure Connected Machine agent. For Windows, use the MSI package; for Linux, use the appropriate package (DEB or RPM). The installation creates the 'himds' service and the 'gc_service' service. The agent registers itself as a Windows service or systemd unit. No inbound ports are opened; the agent only initiates outbound HTTPS connections.
2. Register the Machine with Azure
Run the 'azcmagent connect' command (or equivalent PowerShell cmdlet) to register the machine. This command requires a subscription ID, resource group, location, and authentication method (interactive device login or service principal). The agent sends an HTTPS request to the Azure Arc onboarding endpoint, which creates a resource of type 'Microsoft.HybridCompute/machines' in ARM. The machine is now visible in the Azure portal under 'Azure Arc > Servers'.
3. Heartbeat and Status Monitoring
After registration, the agent sends a heartbeat to Azure every 5 minutes by default. This heartbeat includes the machine's status, resource utilization, and agent health. Azure updates the 'status' property of the Arc resource. If no heartbeat is received for 15 minutes, the status changes from 'Connected' to 'Disconnected'. After 30 days of disconnection, the resource is automatically deleted (soft delete, recoverable within 30 days).
4. Apply Azure Policy and Extensions
Once the machine is connected, you can assign Azure Policy initiatives that target Arc-enabled servers. The guest configuration agent on the machine evaluates policies and reports compliance. You can also install Azure VM extensions (e.g., Log Analytics agent) via the portal, CLI, or Azure Policy. The extension management service on the agent downloads and installs the extension package, then reports the installation status.
5. Manage and Govern at Scale
With the machine onboarded, you can use Azure's management tools consistently. For example, you can use Azure Update Manager to scan for missing updates and schedule installations. You can enable Defender for Cloud to assess security posture. You can use Azure Monitor to collect logs and metrics. All actions are performed through ARM, and the agent translates them into local commands. This enables a single pane of glass for all servers, regardless of location.
Enterprise Scenario 1: Retail Chain with On-Premises Servers
A global retail company has 500 store locations, each with a local Windows server running point-of-sale (POS) applications. These servers are not connected to Azure because of network restrictions. The company wants to enforce a security baseline (e.g., enable BitLocker, install antivirus, ensure Windows Update is configured) across all stores. Using Azure Arc, they install the Connected Machine agent on each store server via a Group Policy startup script. They create an Azure Policy initiative with guest configuration policies that audit and remediate the security settings. The agents report compliance to Azure, and the IT team can see all 500 servers in a single view. They also deploy the Log Analytics agent extension via Arc to collect POS application logs. When a server goes offline (e.g., due to a network outage), the agent stops sending heartbeats, and Azure marks it as disconnected. After 30 days, the resource is removed, alerting the team to investigate.
Enterprise Scenario 2: Multi-Cloud Kubernetes Management
A financial services firm runs workloads on AWS EKS, Google GKE, and on-premises OpenShift clusters. They want a unified view for compliance and GitOps. They enable Azure Arc on each cluster by installing the Arc agent Helm chart. This requires the cluster to have outbound internet access to Azure endpoints. Once connected, they use Azure Policy to enforce that all clusters have certain labels and that no privileged containers run. They also set up Azure Monitor for containers to collect metrics and logs from all clusters. The GitOps configuration (using Flux) is deployed via Arc-enabled Kubernetes, ensuring that each cluster's desired state is maintained from a central Git repository. The challenge is managing network connectivity—each cluster must be able to reach Azure, which may require proxy configuration or firewall rules. If a cluster loses connectivity, it becomes disconnected and cannot receive policy updates.
Enterprise Scenario 3: Running Azure Data Services on Premises
A healthcare organization needs to run Azure SQL Managed Instance on-premises due to data residency requirements. They deploy a Kubernetes cluster on-premises (e.g., using Azure Stack HCI) and enable Azure Arc on it. Then they deploy Azure Arc-enabled data services (SQL Managed Instance) onto that cluster. This allows them to use Azure's SQL features (automatic backups, patching, high availability) while keeping data on-premises. The data services run as containers on the local Kubernetes cluster, but management happens through Azure. Billing is metered and reported to Azure. The key requirement is that the cluster must have persistent outbound connectivity to Azure for billing and management. If connectivity is lost for more than 30 days, the data services may go into a degraded mode and eventually stop functioning. This scenario tests the candidate's understanding of the dependency on Azure connectivity.
What AZ-305 Tests on Azure Arc
AZ-305 objective 4.3: 'Design a hybrid and multi-cloud solution' includes Azure Arc as a key technology. The exam expects you to:
Identify scenarios where Azure Arc is the appropriate solution (vs. Azure Stack Hub, Azure Stack HCI, or VPN/ExpressRoute).
Understand the prerequisites for onboarding servers and Kubernetes clusters.
Know the capabilities: policy enforcement, monitoring, extensions, and data services.
Recognize that Azure Arc does NOT require inbound firewall rules; only outbound HTTPS is needed.
Know that Azure Arc-enabled servers can run any Azure VM extension that is supported (e.g., Log Analytics, Dependency, Custom Script).
Common Wrong Answers and Why
'Azure Arc requires a VPN or ExpressRoute connection to Azure.' This is false. Arc uses outbound HTTPS only. Candidates choose this because they assume hybrid connectivity always requires a private network. The correct answer is that Arc works over the public internet (or through a proxy).
'Azure Arc can manage on-premises resources without installing any agent.' This is false. An agent is required for servers and Kubernetes clusters. The only exception is Azure Arc-enabled VMware vSphere (preview) which uses a different connector.
'Azure Arc replaces Azure Stack Hub for on-premises workloads.' This is a common confusion. Azure Stack Hub runs Azure services in your datacenter; Azure Arc extends management to existing infrastructure. They are complementary, not replacements.
'Azure Arc-enabled data services require a direct connection to Azure SQL Database.' Wrong. They run locally on Kubernetes and only require connectivity to Azure for management and billing.
Specific Numbers and Terms on the Exam
Heartbeat interval: 5 minutes.
Disconnection threshold: 15 minutes (status changes to Disconnected).
Resource removal: After 30 days of no heartbeat.
Required ports: Outbound TCP 443 (HTTPS).
Resource provider: Microsoft.HybridCompute for servers; Microsoft.Kubernetes for clusters.
Agent name: Azure Connected Machine agent (for servers).
Onboarding roles: 'Azure Connected Machine Onboarding' role (for service principal).
Edge Cases and Exceptions
Proxy servers: Arc agent supports HTTP/HTTPS proxy. The proxy must allow the specific Azure endpoints.
Private endpoints: Azure Arc can use Azure Private Link to connect over a private network, but this is optional and requires additional configuration.
Disconnected mode: Arc-enabled data services can operate in a degraded mode for up to 30 days without connectivity, but then they stop.
Multiple subscriptions: A single server can only be connected to one subscription at a time.
How to Eliminate Wrong Answers
If a question asks about managing on-premises servers without modifying them, look for options that involve installing an agent—if no agent is mentioned, it's likely wrong. If a question mentions inbound ports, it's wrong for Arc. If a question says Arc can run Azure IaaS VMs on-premises, that's wrong (that's Azure Stack Hub). Use the mechanism: outbound-only communication, agent-based, ARM projection.
Azure Arc extends Azure Resource Manager to any infrastructure using outbound HTTPS only.
The Azure Connected Machine agent must be installed on every Arc-enabled server.
Heartbeat is sent every 5 minutes; status changes to Disconnected after 15 minutes of no heartbeat.
Resources are automatically removed after 30 days of disconnection.
Azure Arc supports servers, Kubernetes clusters, and data services (SQL Managed Instance, PostgreSQL).
Azure Arc does NOT require inbound firewall rules; only outbound port 443.
Azure Arc-enabled data services run locally on Kubernetes, not in Azure.
These come up on the exam all the time. Here's how to tell them apart.
Azure Arc
Extends Azure management to existing infrastructure (on-prem, other clouds).
No need to run Azure hardware; works on any compatible server.
Agent-based; requires outbound HTTPS connectivity.
Supports servers, Kubernetes, and data services.
Billing is pay-as-you-go for data services only; management is free.
Azure Stack Hub
Runs Azure IaaS and PaaS services in your datacenter on certified hardware.
Requires Azure Stack Hub integrated systems (specific hardware).
Runs a full Azure environment locally; can operate disconnected.
Supports Azure VMs, App Service, Functions, etc.
Billing is based on capacity (subscription).
Mistake
Azure Arc requires a direct network connection to Azure via VPN or ExpressRoute.
Correct
Azure Arc only requires outbound HTTPS (port 443) to specific Azure endpoints. It works over the public internet and can use a proxy. VPN/ExpressRoute are optional for private connectivity.
Mistake
Azure Arc can manage any on-premises resource, including physical network switches.
Correct
Azure Arc currently supports servers (Windows/Linux), Kubernetes clusters, data services, and (in preview) VMware vSphere and SCVMM. It does not manage network devices or non-compute resources.
Mistake
Azure Arc-enabled servers can be managed without any agent installation.
Correct
Every Arc-enabled server requires the Azure Connected Machine agent to be installed. Without the agent, the server cannot register or communicate with Azure.
Mistake
Azure Arc is only for on-premises servers and cannot manage servers in other clouds.
Correct
Azure Arc can manage servers and Kubernetes clusters running in AWS, GCP, or any other cloud, as long as they have outbound internet access to Azure.
Mistake
Azure Arc-enabled data services run in Azure and connect to on-premises databases.
Correct
Arc-enabled data services (SQL Managed Instance, PostgreSQL Hyperscale) run locally on a Kubernetes cluster on-premises or at the edge. They do not run in Azure.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The only requirement is outbound HTTPS (port 443) to specific Azure endpoints. The full list includes `*.his.arc.azure.com`, `*.guestconfiguration.azure.com`, `*.agentservice.azure.com`, and others. No inbound ports are needed. If a proxy is used, the agent must be configured to use it. Optionally, you can use Azure Private Link for private connectivity, but this is not required.
Yes, as long as the server can make outbound HTTPS connections to the required Azure endpoints. The agent initiates all communication, so NAT and firewalls that allow outbound traffic work fine. The agent does not need to be reachable from the internet.
The agent stops sending heartbeats. After 15 minutes, the server's status in Azure changes to 'Disconnected'. It remains manageable (you can still see it) but you cannot deploy new extensions or apply policies. After 30 days of disconnection, the resource is automatically deleted from Azure. The server itself continues to run locally unaffected.
You can use Azure Policy with the 'Configure machines to receive a Log Analytics agent' or similar initiative that includes the 'Deploy Azure Connected Machine agent' policy. Alternatively, use a service principal with the 'Azure Connected Machine Onboarding' role and run a script (e.g., via Group Policy, SCCM, or Ansible) to install the agent and run the connect command.
Yes. Azure Arc-enabled Kubernetes supports any CNCF-certified Kubernetes cluster, including Amazon EKS, Google GKE, and self-managed clusters. The cluster must have outbound internet access to Azure and you must install the Arc agent Helm chart. Once connected, you can apply policies, use GitOps, and monitor using Azure Monitor for containers.
Azure Arc is the foundation that brings non-Azure resources into ARM. Azure Automanage is a service that automatically applies best practices (like enabling backup, update management, etc.) to Azure VMs and Arc-enabled servers. Automanage leverages Arc for non-Azure machines. So you need Arc first, then you can enable Automanage.
No. The Azure Connected Machine agent requires Windows Server 2012 R2 or later, or a supported Linux distribution. Windows Server 2008 R2 is out of support and cannot be used with Arc. You would need to upgrade or migrate the workload.
You've just covered Azure Arc for Hybrid and Multi-Cloud — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?