Azure Arc-Enabled Applications

Azure Arc is a hybrid and multi-cloud management platform that extends Azure Resource Manager (ARM) control plane and services to resources running outside of Azure. This includes physical servers, virtual machines (VMs), Kubernetes clusters, and data services running on-premises, at the edge, or in other public clouds (e.g., AWS, GCP). The primary goal is to provide a consistent management experience across all environments, enabling organizations to use Azure tools like Azure Policy, Azure Monitor, Azure Defender, and role-based access control (RBAC) on non-Azure resources.

For the AZ-204 exam, you need to understand how Azure Arc enables developers to deploy and manage applications consistently. Specifically, Arc allows you to:

Azure Arc operates on a model where an agent or service is installed on the target resource, which then establishes an outbound connection to Azure. This ensures that no inbound ports need to be opened in firewalls, enhancing security.

For servers (Arc-enabled servers): - The Azure Connected Machine agent is installed on Windows or Linux machines. - The agent registers the machine as an Azure resource in a specified resource group and region (the region is where the resource metadata is stored, not the physical location). - The agent periodically (every 5 minutes by default) sends heartbeat and metadata to Azure. It also listens for policy assignments and configuration changes from Azure. - Azure Policy can be applied to these machines using guest configuration extensions. For example, you can enforce that a specific software is installed or that certain firewall rules are active.

For Kubernetes clusters (Arc-enabled Kubernetes): - You deploy the Arc-enabled Kubernetes agent on the cluster (using a Helm chart). - The agent connects to Azure Resource Manager and registers the cluster. - You can then deploy Azure Arc-enabled services like App Service on Azure Arc or Azure Functions on Azure Arc onto the cluster. - GitOps is used to manage configurations: a Git repository holds desired state YAML files, and Flux (a GitOps operator) syncs the cluster to that state.

Register a server with Azure Arc using Azure CLI:

az connectedmachine register \
  --resource-group myResourceGroup \
  --name myMachine \
  --location eastus \
  --subscription mySubscription

This command downloads and installs the agent, registers the machine, and creates a resource in Azure.

Verify server registration:

az connectedmachine list --resource-group myResourceGroup --output table

Connect a Kubernetes cluster to Azure Arc:

az connectedk8s connect --name myCluster --resource-group myResourceGroup --location eastus

This deploys the Arc agent Helm chart to the cluster.

Verify cluster connection:

az connectedk8s show --name myCluster --resource-group myResourceGroup

Enable GitOps on an Arc-enabled Kubernetes cluster:

az k8s-configuration create \
  --name myConfig \
  --cluster-name myCluster \
  --resource-group myResourceGroup \
  --operator-instance-name flux \
  --operator-namespace flux-system \
  --repository-url https://github.com/myorg/myconfig \
  --scope cluster \
  --cluster-type connectedClusters

For AZ-204, you are expected to:

Azure Arc is a powerful tool for extending Azure management to any infrastructure. It uses agents that connect outbound to Azure, enabling consistent policy, monitoring, and application deployment. For the exam, focus on the onboarding process, GitOps configuration, and the scenarios where Arc is the correct choice (hybrid management, not migration).

Scenario 1: Retail Chain with Edge Locations A global retailer has hundreds of stores, each with local servers running inventory management applications. They want to enforce consistent security policies (e.g., disk encryption, antivirus) and collect performance metrics centrally without replacing on-premises hardware. They deploy Azure Arc on each store server. Using Azure Policy, they enforce that all servers have BitLocker enabled and Windows Defender running. Azure Monitor collects logs and metrics, alerting the central IT team if any server goes offline or has high CPU usage. The challenge: store servers may have intermittent internet connectivity. Arc agents handle this gracefully by queuing policy updates and sending them when online. If a server is offline for more than 30 days, it is marked as 'disconnected' in Azure. The team uses Azure Update Management to schedule patching during off-hours.

Scenario 2: Financial Services with Hybrid Kubernetes A bank runs a Kubernetes cluster on-premises for sensitive payment processing, but also uses AKS in Azure for development. They want a unified view of all clusters and consistent RBAC policies. They connect the on-premises cluster to Azure Arc. Now they can see both clusters in the Azure portal, apply Azure Policy to ensure containers are running with restricted privileges, and use Azure Monitor for container insights. They use GitOps to deploy configurations: a Git repo holds manifests for both clusters, and Flux syncs changes. When a developer pushes a new deployment, it rolls out to both clusters automatically. The bank also deploys Azure App Service on Azure Arc to run a legacy web app on-premises, benefiting from Azure's autoscaling and monitoring without migrating to the cloud.

Scenario 3: Manufacturing with IoT Edge A manufacturer has factory floor devices running IoT Edge modules. They want to manage these devices alongside their cloud resources. They use Azure Arc to onboard the IoT Edge devices as Arc-enabled servers. This allows them to apply policies, monitor device health, and deploy updates from Azure. They also use Azure Arc-enabled Kubernetes to run containerized workloads on edge gateways. The key consideration: edge devices have limited resources, so the Arc agent must be lightweight. Microsoft provides a lightweight agent for these scenarios. Misconfiguration often occurs when firewall rules block the outbound HTTPS connections required by the agent, causing the devices to show as disconnected.