2.2 Automated Deployment, Azure Arc, and SQL Database in Microsoft Fabric

Choosing an Automated Deployment Method

Quick Answer: For repeatable, auditable, multi-environment deployments choose Bicep or ARM templates because they are declarative and idempotent. Use the Azure portal for one-off manual deployments, Azure PowerShell or the Azure CLI for scripted imperative automation, and reserve deep pipeline design for the dedicated automation chapter.

Every Azure SQL resource — logical servers, databases, elastic pools, managed instances, firewall rules — can be deployed through the Azure Resource Manager (ARM) control plane. The deployment methods differ in how you express intent:

• Azure portal — a guided wizard for single, manual deployments. It is the right answer for quick proof-of-concept work or learning, and it can export the equivalent template at the review step. It is never the right answer for repeatable production deployment.
• ARM templates — declarative JSON describing the desired end state. Deployments are idempotent: applying the same template repeatedly converges to the same result rather than failing on existing resources. Templates live in source control, support parameters for per-environment values, and integrate with what-if to preview changes before applying them.
• Bicep — a concise domain-specific language (DSL) that transpiles directly to ARM JSON. It offers modules for reuse, strong typing, and vastly less boilerplate than raw JSON, with no separate state file to manage because Azure itself is the source of truth. Anything ARM can deploy, Bicep can deploy.
• Azure PowerShell — imperative cmdlets such as New-AzSqlServer and New-AzSqlDatabase. A natural fit when the team already automates in PowerShell or on Windows-centric pipelines.
• Azure CLI — imperative commands such as az sql server create and az sql db create. Cross-platform and the common choice in Linux-based continuous integration and continuous delivery (CI/CD) pipelines.
• REST API, SDKs, and third-party tools such as Terraform — used when you need programmatic control or multi-cloud tooling, though Terraform maintains its own state file, unlike Bicep and ARM.

The exam frames these as scenario picks: existing Bash-based CI/CD pipeline points to the Azure CLI; a requirement for repeatable, versioned infrastructure across dev, test, and prod points to Bicep or ARM; a single quick sandbox database points to the portal.

Azure Arc-Enabled SQL Server

Azure Arc extends the Azure control plane to resources running outside Azure — on-premises, at the edge, or in other clouds. For SQL Server, you install the Azure Connected Machine agent on the host and the Azure extension for SQL Server, which registers each instance as an Azure resource with a resource ID, tags, Azure role-based access control (RBAC), and policy scope. No data moves to Azure; only management metadata flows.

The use cases the exam emphasizes are:

• Central inventory at scale — one Azure view of every SQL Server instance in the estate, with version, edition, and patch level, queryable through Azure Resource Graph.
• Microsoft Entra authentication — SQL Server 2022 and later instances can accept Microsoft Entra ID (formerly Azure Active Directory) identities when Arc-connected, unifying identity management across cloud and on-premises.
• Security and governance — Microsoft Defender for SQL, Azure Policy guest configuration, best practices assessment, and migration readiness assessments.
• Pay-as-you-go billing — instead of purchasing licenses, you can pay for SQL Server per core-hour through Azure, activated via Arc. This is attractive for dev/test, seasonal workloads, or instances without Software Assurance, and it can be turned off when the workload ends.
• Backup and management services — automated backup to Azure and Purview governance integration for supported configurations.

A frequent trap: Azure Arc manages and inventories SQL Server — it is not a replication or migration technology, and it does not convert the instance into azure SQL Managed Instance.

SQL Database in Microsoft Fabric

SQL database in Microsoft Fabric is a software-as-a-service (SaaS) database built on the Azure SQL Database engine but operated as a native Fabric workload. Its defining traits:

• Autonomous by default — it provisions in seconds, auto-scales, and self-manages indexes and performance; there are no service tiers, elastic pools, or DTU/vCore decisions to make.
• Capacity-based billing — consumption is measured in Fabric capacity units (CUs) against your Fabric capacity rather than per-database charges.
• Automatic OneLake mirroring — data replicates into OneLake as Delta tables in near real time, making operational data immediately available to Power BI DirectLake reports, Spark notebooks, and data engineering workloads without extract-transform-load (ETL) pipelines.

Choose Fabric SQL database when the workload lives in the analytics ecosystem: an operational store whose data must feed Fabric analytics with zero ETL, rapid prototyping, or teams that want a database with essentially no knobs. Choose Azure SQL Database instead when you need explicit control — specific service tiers, elastic pools, Hyperscale, granular networking such as private endpoints configured independently, advanced T-SQL surface area, or when the organization has no Fabric capacity investment. The exam contrast is autonomy and analytics integration (Fabric) versus configurability and standalone operation (Azure SQL Database).