4.2.3. Azure Arc for Hybrid and Multicloud Servers
💡 First Principle: Security controls built for Azure resources don't automatically extend to a server sitting on-premises or running in another cloud — Azure Arc closes that gap by projecting non-Azure servers into the Azure resource model, so the same governance and security tooling can reach them.
Onboarding a server to Azure Arc registers it as an Azure resource (with a resource ID, tags, and RBAC scope) even though it physically runs elsewhere — on-premises, in AWS, or in GCP. Once Arc-enabled, that server becomes eligible for the same Azure security tooling used on native Azure VMs: Azure Policy assignment, Defender for Servers onboarding (4.2.4), and Machine Configuration (4.2.5) baseline enforcement.
⚠️ Exam Trap: Azure Arc doesn't move or migrate the server — it remains physically wherever it was, running whatever OS it already runs. A scenario describing "extending Azure security policy to on-premises servers without migrating them to Azure" is describing exactly what Arc is for; assuming Arc requires migration is the trap.
Reflection Question: Why is projecting an on-premises server into the Azure resource model (rather than migrating it) the key idea that makes the rest of this section's tooling (Defender for Servers, Machine Configuration) usable on hybrid infrastructure?
