Skip to main content

Azure Arc-enabled SQL Server & SQL Database in Microsoft Fabric - Use Cases

The April 24, 2026 DP-300 outline added two newer Microsoft data platform options under Domain 1:

"Recommend appropriate use cases for Azure Arc-enabled SQL services"
"Recommend appropriate use cases for Azure SQL Database in Microsoft Fabric"

These are recommendation skills - the exam will give you a scenario and ask which platform fits. This page covers both, side-by-side, with positioning vs Azure SQL DB, MI, and SQL VM.

Part 1 - Azure Arc-enabled SQL services​

What is Azure Arc-enabled SQL?​

Azure Arc-enabled SQL Server projects an existing SQL Server instance - running on-premises, in another cloud (AWS, GCP), or in an edge / disconnected environment - into Azure as a first-class Microsoft.AzureArcData/sqlServerInstances resource. After projection, that instance can use Azure-native services (Defender, Monitor, Backup, Update Manager, Purview, Entra authentication, Best Practices Assessment) without moving the database to Azure.

There is also Azure Arc-enabled data services - a Kubernetes-based set of services (Arc-enabled SQL MI and Arc-enabled PostgreSQL) that you can host on any CNCF-conformant Kubernetes with an Azure control plane. Most exam questions focus on the simpler Arc-enabled SQL Server flavor.

🎯 Exam Focus

"Arc-enabled SQL Server" = surface a non-Azure SQL Server in Azure for management. "Arc-enabled SQL Managed Instance" = run actual SQL MI on your own Kubernetes with Azure control. Make sure you read the question carefully - the use cases differ. :::

Architecture​

How Arc-enabled SQL Server connects
1
1. Host machine
Windows / Linux server with SQL Server
On-prem, AWS, GCP, edge
Has outbound HTTPS to Azure
2
2. Connected Machine agent (azcmagent)
Onboards the OS to Azure Arc
Creates Microsoft.HybridCompute/machines
3
3. SQL Server extension
Auto-installed by Arc onboarding
Discovers each SQL instance + DBs
Reports up to AzureArcData RP
4
4. Azure surface
Azure Portal / CLI / Bicep
Defender for SQL, Monitor, Backup
Best Practices Assessment, Purview

What you get when you Arc-enable a SQL Server​

CapabilityNotes
Inventory & visibility in Azure PortalOne pane for every SQL instance regardless of host cloud
Microsoft Defender for SQLVulnerability assessment, advanced threat protection on non-Azure SQL
Best Practices AssessmentSysadmin-style health checks, served from Azure
Microsoft Entra (Azure AD) authenticationYes, for Arc-enabled SQL Server 2022+
Azure Backup for SQL ServerBackups to a Recovery Services vault from on-prem/cloud SQL
Azure Monitor / Log Analytics integrationSend SQL logs and DMV-based metrics centrally
Azure Update ManagerPatch the OS (and SQL CU via the same agent path)
Microsoft Purview scanningCatalog and classify on-prem databases
Database Watcher (preview)Near-real-time KQL monitoring of Arc-enabled SQL
Azure PolicyAudit / enforce baselines (e.g., TDE on, auditing enabled)
Pay-as-you-go billingOptional - convert perpetual SQL licensing to monthly Azure billing

Use-case recommendation table​

ScenarioRecommend?Why
Hundreds of on-prem SQL Servers needing centralized inventory & threat protectionStrong fitInventory + Defender + Best Practices Assessment everywhere
Customer wants Microsoft Entra logins on AWS RDS for SQLNoRDS is managed by AWS - Arc requires direct OS access. Use Arc on a self-managed SQL on EC2 instead.
Edge sites with intermittent connectivity needing local management + occasional Azure visibilityFitArc agents tolerate disconnection; data syncs on reconnect.
Convert perpetual SQL licensing to Azure monthly billing without migratingFitUse the pay-as-you-go billing option of Arc-enabled SQL Server.
Need a true Azure SQL service with built-in HA and patchingNoThat's Azure SQL DB / MI. Arc surfaces a SQL you operate.
Need ESU (Extended Security Updates) for SQL Server 2014 on-premFitArc-enabled SQL Server supports Azure-billed ESU subscriptions for eligible SQL Server 2014 instances through 2027-07-08.
SQL Server 2012 still on-prem and asking for new ESU coverageNoSQL Server 2012 ESU has ended. Treat it as an upgrade or migration priority, not a new Arc ESU candidate.
Want to run SQL MI in a sovereign-cloud Kubernetes cluster controlled by AzureFitUse Arc-enabled SQL Managed Instance on AKS / OpenShift / Rancher.
🎯 Exam Focus

ESU through Azure Arc is the current Azure-billed subscription path for eligible SQL Server 2014 instances. It is not the only historical purchase path: customers with the right licensing can also have Volume Licensing ESU coverage, especially for disconnected or transition scenarios. For DP-300, remember the clean rule: SQL Server 2014 = current ESU case; SQL Server 2012 = upgrade or migrate.

Onboarding (high-level)​

# 1. On the SQL host (run as admin), install the Connected Machine agent
Invoke-WebRequest -Uri https://aka.ms/AzureConnectedMachineAgent `
  -OutFile AzureConnectedMachineAgent.msi
msiexec /i AzureConnectedMachineAgent.msi /qn

# 2. Connect to Azure (interactive - service principals supported for at-scale)
& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" connect `
  --resource-group rg-arc-sql `
  --tenant-id    <tenant> `
  --subscription-id <sub> `
  --location     westeurope `
  --cloud        AzureCloud

# 3. Install/enable the SQL Server extension (auto-discovers SQL instances)
az connectedmachine extension create `
  --name WindowsAgent.SqlServer `
  --machine-name <host> `
  --resource-group rg-arc-sql `
  --type WindowsAgent.SqlServer `
  --publisher Microsoft.AzureData `
  --location westeurope

After ~10 minutes the Portal shows Azure Arc -> SQL Server with each instance and database listed.

Limitations & gotchas​

  • Arc-enabled SQL Server requires SQL Server 2012 or later; Defender features and Entra authentication require SQL Server 2022+.
  • The host must be able to make outbound HTTPS to Azure Arc endpoints (or via private link).
  • PaaS-managed SQL (Amazon RDS, Google Cloud SQL) cannot be Arc-enabled - Arc requires OS access.
  • Arc-enabled SQL MI on Kubernetes has a separate licensing/pricing model and requires a connected mode for many features.

Part 2 - Azure SQL Database in Microsoft Fabric​

What it is​

SQL Database in Microsoft Fabric is a fully-managed, OLTP-grade relational database that lives inside a Fabric workspace. It is built on the same Azure SQL Database engine, but provisioned, billed, and surfaced through Fabric - and it automatically replicates its tables into the Fabric OneLake as Delta Parquet for analytics, AI, and Power BI consumption.

It is not a re-skinned Azure SQL DB - it adopts a new Fabric-native experience (capacity-based licensing via F-SKUs, web-based query editor, automatic OneLake mirroring, integration with Fabric items like Notebooks, Data Pipelines, Direct Lake semantic models, Power BI reports).

Architecture​

Fabric SQL DB end-to-end
1
1. Fabric capacity (F-SKU)
Single capacity unit billing
Spans all Fabric workloads
2
2. SQL Database item
Built on Azure SQL DB engine
OLTP-class transactions, T-SQL, AE, RLS
3
3. Auto-mirrored to OneLake
Delta Parquet replicas of every table
Near-real-time, no ETL
4
4. Direct Lake & Power BI
Semantic model reads OneLake directly
Fast, no import refresh

Capabilities & features​

FeatureStatus
Standard T-SQL surface (incl. window functions, JSON, native vectors)Yes
Transactions (ACID) at OLTP scaleYes
Microsoft Entra authenticationYes
Storage encryption with service-managed keysYes
Transparent Data Encryption (TDE) / customer-managed TDE keysNo
Always EncryptedNo
Row-Level Security, Dynamic Data MaskingYes
Automatic OneLake mirroring (Delta Parquet)Yes - built in
Connect via SSMS, Azure Data Studio, ADO.NET, JDBC, ODBCYes
GraphQL API can be created from the Fabric portalYes
Automatic backups & point-in-time restoreYes - managed by Fabric
Geo-Replication / Failover GroupsNo (use Azure SQL DB if cross-region failover is needed)
Customer-managed keys at the database levelNo - use service-managed storage encryption today
SQL Agent jobsNo - use Fabric Data Pipelines or Elastic Jobs
Service Broker, Database Mail, CLRNo
Linked serversTarget-only; do not use for workloads that require outbound linked-server queries

Use-case recommendation table​

ScenarioRecommend?Why
Net-new analytics-ready SaaS app where Power BI reports must reflect new data within secondsStrong fitMirrored OneLake + Direct Lake = no ETL, sub-minute freshness.
Existing OLTP system with linked servers, SQL Agent jobs, Service BrokerNoFabric SQL DB lacks those features - stay on Azure SQL DB / MI.
Data engineer prototyping a relational store inside Fabric, alongside Lakehouses and NotebooksFitNative Fabric item, billed against the same capacity.
Strict regulatory requirement for customer-managed TDE keys todayNoUse Azure SQL DB with customer-managed keys in Azure Key Vault.
Need Active Geo-Replication & Auto-Failover Groups for an RPO <= 5 s, multi-regionNoUse Azure SQL DB or MI failover groups.
Building a new application that combines OLTP, AI vector search, and Power BI dashboardsStrong fitVector data type + OneLake + Direct Lake all in one Fabric workspace.
Lift-and-shift of a 4 TB legacy on-prem SQL Server with stored procs + agent jobsNoChoose Azure SQL Managed Instance.
🎯 Exam Focus

Fabric SQL Database shares the Azure SQL Database engine, but not every Azure SQL Database feature is available. The exam trap is treating it as a drop-in replacement for Azure SQL DB or SQL MI. If the scenario needs TDE/customer-managed database keys, Always Encrypted, failover groups, SQL Agent, Service Broker, or outbound linked-server behavior, pick another SQL platform.

Why "automatic OneLake mirroring" is the killer feature​

Mirroring continuously writes a Delta Parquet replica of every table into OneLake without requiring you to build a pipeline:

  • Direct Lake semantic models in Power BI can query the Delta files without an import refresh - dashboards reflect transactional changes within seconds.
  • Notebooks (Spark, Python) can query the same data without contending for the OLTP engine.
  • Cross-item analytics (joining the SQL DB with Lakehouse tables) is a single SQL statement against the SQL analytics endpoint.

Compared to the historical pattern (Change Data Capture -> ADF -> Lakehouse -> semantic model refresh), Fabric SQL DB removes 3 layers of plumbing.

Provisioning - quick walk-through​

In a Fabric workspace:

  1. Create item -> SQL Database.
  2. Pick a name; pick the workspace's capacity (F-SKU).
  3. The DB is provisioned in ~1 minute. A connection string is shown for SSMS / drivers.
  4. Open the web-based query editor to run T-SQL.
  5. Open the mirror item that's auto-created in OneLake to verify Delta files exist.
  6. Build a semantic model in Direct Lake mode pointing at the mirror.

Decision matrix - Azure SQL DB vs Azure SQL MI vs Fabric SQL DB vs SQL VM​

NeedBest fit
Modern OLTP + native analytics + Power BI in one platformFabric SQL DB
Maximum SQL Server compatibility (CLR, Service Broker, MSDTC, agent jobs)Azure SQL MI
Standard PaaS OLTP at scale, with cross-region failover groups, BYOKAzure SQL DB
Full OS control, custom tempdb config, third-party SQL extensionsSQL Server on Azure VM
Surface a non-Azure SQL Server for governance & threat protectionArc-enabled SQL Server
Run SQL MI on customer-controlled Kubernetes (sovereign / edge)Arc-enabled SQL MI
🏢 Real-World DBA Note

Oracle DBA parallel:

  • Arc-enabled SQL Server is the conceptual cousin of Oracle Cloud@Customer (control plane in Oracle Cloud, data plane in your DC).
  • Fabric SQL DB with auto-mirroring is the closest thing Microsoft has built to Oracle's Autonomous Database + Autonomous Data Warehouse in a single dual-purpose engine - but on Microsoft's Lakehouse-first OneLake architecture. :::

Anti-Patterns​

  • "Arc replaces migration." It doesn't. Arc projects an existing SQL Server into the Azure control plane (Defender, Monitor, Entra auth, BPA, Backup). It does not move data, change runtime, or give you PaaS. Cost is added, not replaced.
  • "Arc-enable Amazon RDS for SQL Server." Impossible. Arc requires the Connected Machine agent on the OS. RDS is AWS-managed. You can only Arc a self-managed SQL Server on EC2.
  • "Fabric SQL DB is just Azure SQL DB inside Fabric." Same engine, different container. Fabric SQL DB is provisioned at Fabric capacity (CU-based), auto-mirrors to OneLake (T+1 second), and has no portal-style firewall management. If your billing is in vCore SQL DB, you can't switch to Fabric without a separate provisioning model.
  • "Arc-enabled SQL MI on K8s = the same as managed SQL MI." No. Arc-MI runs on your Kubernetes (typically AKS / OpenShift / Tanzu), with you owning HA, upgrades, networking, certs. The Azure portal manages billing + compliance, not lifecycle.
  • "Defender for SQL via Arc is free." It's a paid plan billed per-server per-month. Arc registration itself is free; the value-add services aren't.
  • "Auto-mirroring from Fabric SQL DB to OneLake is replication." It's a near-real-time copy for analytics. There's no failover path. Don't treat OneLake delta tables as a DR target.
⚠️ Watch Out

Arc-enabled SQL Server inventory is per-machine, not per-instance. A box with 3 SQL instances counts as 3 SQL servers in inventory but is 1 Arc machine. Defender pricing follows the SQL count.

Migration Between Options​

From -> ToPathCost
On-prem SQL Server -> Arc-enabled SQL ServerInstall Connected Machine agent + SQL Server extensionFree agent; pay only for opted-in services
Arc-enabled SQL Server -> Azure SQL MIMI Link (online) or DMS / backup-restore (offline)One-way to PaaS; lose host control, gain managed lifecycle
Arc-enabled SQL Server -> SQL VM in AzureBackup/restore or AG seeding to a new VMLift-and-shift; keep host control, drop on-prem footprint
Azure SQL DB (vCore) -> Fabric SQL DBExport/import or BACPAC; no in-place conversionNew provisioning model; recompute Fabric capacity sizing
Fabric SQL DB -> Azure SQL DB (vCore)BACPAC exportReverse path; lose auto-mirroring to OneLake
Arc-enabled SQL MI on K8s -> Azure SQL MIBackup-to-URL + LRS or DMSDrop K8s ownership; gain Azure-managed HA
SQL Server in EC2 -> Arc-enabled SQL ServerConnected Machine agent works cross-cloudFree; gain Defender/Monitor/Entra without leaving AWS

Most expensive move: Fabric <-> vCore. No in-place path; rebuild + cutover.

Real Scenarios​

  1. Fortune-500 with 800 SQL Servers across 4 clouds -> Arc-enable everything + Defender for SQL + Best Practices Assessment. Driver: single security plane, governance reporting. Trade-off: Defender per-server cost x 800.
  2. ISV with sovereign-cloud requirement (Germany) -> Arc-enabled SQL MI on customer K8s in country. Driver: data residency + Azure billing. Trade-off: customer owns Kubernetes lifecycle.
  3. Net-new SaaS analytics product on Fabric -> Fabric SQL DB with auto-mirroring + Power BI Direct Lake. Driver: zero-ETL analytics. Trade-off: Fabric capacity (CU) sizing is its own discipline.
  4. EC2 SQL Server, want Entra auth without rehosting -> Arc-enable + configure Entra auth via Arc. Driver: kill local AD-only auth. Trade-off: still on EC2, AWS bill unchanged.
  5. Customer on Cloud@Customer for Oracle, evaluating Microsoft equivalent -> Arc-enabled SQL MI on AKS deployed at the customer DC. Driver: control-plane-in-cloud, data-plane-on-prem story. Trade-off: AKS operational maturity required.

Flashcards​

What does Azure Arc-enabled SQL Server let you do?
Click to reveal answer
Project an existing SQL Server (on-prem, AWS, GCP, edge) into Azure as a first-class resource and use Azure-native services like Defender for SQL, Monitor, Backup, Entra auth, and Best Practices Assessment without migrating the database.
1 / 6

Practice quiz​

Q1/5
0 correct
An organization has 500 SQL Servers spread across on-premises data centers and AWS EC2. They need centralized vulnerability assessment, patch compliance, and Microsoft Defender for SQL coverage without migrating the databases. What should you recommend?

Sources & further reading​

Last verified against Microsoft Learn: 2026-05-12.