Azure Arc and Azure Local as a Hybrid Control Plane

What Arc actually projects

The Arc resource model from the inside: servers, Kubernetes, data services and Azure Local as projected resources. Which data flows in which direction, and what stays local? Clarified on the data flow diagram, not the marketing picture.

Resource topology for your organization

Management groups, subscriptions, resource groups, tags and RBAC: an exercise on your own case. The concrete decision: where do you separate production from test, and who may do what at the Arc level?

Onboarding in the lab

Each team connects Azure Local instances and further systems to Arc, in the version available at the time. Along the way the team logs which endpoints, accounts and permissions the onboarding actually demands.

Arming RBAC

Role design in practice: operations team, security team, auditor. Testing with three identities whether the boundaries hold. Whoever sees or can do too much gets adjusted.

Day result: documented resource model

Each team has onboarded its systems into Arc and documented a resource model with RBAC layout as a diagram, verified with real test accesses.

Policy as guardrail, not brake

Azure Policy on Arc resources: audit versus deny, initiatives, exemptions with expiry dates. Selection exercise: which ten policies belong in your starting set, and which single one of them is set to deny?

Laying the GitOps foundation

Configuration as code with Flux on Arc-enabled Kubernetes: repository structure, environment separation, approval paths. The fundamental question gets decided: what must never again be changed via the portal?

Exercise: change via pull request

Each team changes a workload configuration exclusively through a pull request and watches the GitOps chain deliver it. Then the counter-test: a manual change on the system is detected as drift and rolled back.

Azure Local under Arc in daily operations

Updates, monitoring and capacity views on Azure Local through the Arc layer, in the version available at the time. An honest balance: what the control plane covers well today and where local tooling is still required.

Day result: running policy and GitOps chain

Each team has assigned ten policies, delivered a change via pull request and demonstrably detected and corrected a configuration drift. Repositories and policy definitions leave with the team as artifacts.

Connected and disconnected without ideology

The two operating models in sober comparison: data flows, update paths, feature scope, operational effort. Azure Local Disconnected Operations framed honestly: access-restricted, subject to an eligibility check, not freely orderable, feature scope in the version available at the time.

The criteria catalog

Building a decision grid: regulatory constraints, latency and autonomy requirements, staffing, supportability, cost. Every criterion gets a weight and a measurable verification question.

Case work: your organization in the decision picture

Each team applies the catalog to its own starting position from the prework and produces a recommendation: connected, initiate the disconnected eligibility check, or a mixed model. The recommendation is defended in front of the group.

The eligibility reality and plan B

Walking the real path towards Disconnected Operations: prerequisites, review process, time horizon. For each team a plan B is recorded in case the check fails or takes too long.

Day result: reasoned operating model recommendation

Each team has a documented decision picture with a weighted criteria catalog, a recommendation for its own organization and a list of open verification points with owners.