Deploy and Configure Azure SQL
Learn automated deployment methods for Azure SQL — Azure Portal, ARM templates, Bicep, PowerShell, and CLI. Plus hybrid SQL Server solutions and patching strategies.
Deploying Azure SQL resources
Think of deployment like building a house.
You can build it by hand (Azure Portal — clicking buttons), or you can hire a builder with blueprints (templates and scripts). The portal is great for your first time. But when you need to build the same house 50 times across different cities, you want blueprints.
That’s what ARM templates, Bicep, PowerShell, and Azure CLI do — they’re your blueprints. Write once, deploy everywhere, and know every house is identical.
Deployment methods compared
| Method | Type | Idempotent? | Best For |
|---|---|---|---|
| Azure Portal | Interactive (GUI) | No | Learning, one-off deploys, troubleshooting |
| ARM templates | Declarative (JSON) | Yes | Enterprise IaC, CI/CD pipelines, compliance |
| Bicep | Declarative (compiles to ARM) | Yes | Modern IaC — cleaner syntax than ARM JSON |
| Azure PowerShell | Imperative (scripting) | No (unless coded) | Procedural tasks, conditional logic, admin automation |
| Azure CLI | Imperative (command-line) | No (unless coded) | Cross-platform scripting, Bash environments |
| Terraform | Declarative (HCL) | Yes | Multi-cloud, existing Terraform teams |
Declarative vs imperative — what does the exam care about?
Declarative (ARM, Bicep, Terraform): You describe the desired end state. The engine figures out what to create, update, or skip. These are idempotent — run them twice, same result.
Imperative (PowerShell, CLI): You describe the steps to take. You control the sequence. NOT inherently idempotent — running twice might create duplicates unless you add checks.
The exam loves asking: “Which deployment method ensures the environment matches a defined state?” → Answer: ARM/Bicep (declarative, idempotent).
Deploying each platform
Azure SQL Database
Priya deploys a new Azure SQL Database for ScaleWave:
- Create a logical server (server-level firewall, admin login, Azure region)
- Create a database on that server (choose tier: DTU or vCore, size, backup redundancy)
- Optionally add it to an elastic pool for shared resources
Key settings at deployment:
- Compute tier: Provisioned (always-on) or Serverless (auto-pause)
- Service tier: General Purpose, Business Critical, or Hyperscale
- Backup redundancy: Locally redundant (LRS), zone-redundant (ZRS), or geo-redundant (GRS)
Azure SQL Managed Instance
Kenji deploys MI for NorthStar’s migration:
- Create a virtual network and dedicated subnet (MI lives inside your VNet)
- Deploy the Managed Instance (choose tier, vCores, storage, time zone)
- First deployment can take 4-6 hours (subsequent operations are faster)
Key differences from SQL Database deployment:
- MI requires a dedicated subnet — no other resources can share it
- MI is deployed at the instance level, not individual database level
- You can deploy multiple databases within one MI after creation
SQL Server on Azure VMs
Kenji also deploys a SQL VM for the legacy reporting server:
- Choose a VM image (Windows + SQL Server pre-installed from Azure Marketplace)
- Configure VM size (memory-optimised recommended for SQL workloads)
- Configure storage (Premium SSD or Ultra Disk, separate data/log/tempdb disks)
- Register with the SQL IaaS Agent extension for Azure portal management
SQL IaaS Agent extension — why it matters
The SQL IaaS Agent extension registers your SQL VM with Azure, unlocking:
- Automated backups and patching via the Azure portal
- Integration with Microsoft Defender for SQL
- License management (pay-as-you-go or Azure Hybrid Benefit)
- Storage configuration best practices
Without the extension, your SQL VM is just a generic VM to Azure — you lose all SQL-specific management features.
Hybrid SQL Server solutions
Not everything moves to Azure at once. Hybrid architectures bridge on-premises and cloud:
| Hybrid Solution | What It Does |
|---|---|
| Azure Arc-enabled SQL Server | Manage on-prem SQL instances from Azure portal (covered in Module 1) |
| SQL Server on Azure VMs + VPN/ExpressRoute | SQL on VMs connected to on-prem network via site-to-site VPN or ExpressRoute |
| Azure SQL MI + VNet peering | MI in Azure VNet peered with on-prem network for seamless connectivity |
| Distributed Availability Groups | Span an AG across on-prem and Azure VM SQL instances for DR |
| Log shipping | Ship transaction logs from on-prem to Azure (one-way, async) |
Kenji’s hybrid approach: NorthStar migrates databases in waves. During migration, some databases stay on-prem while others run in MI. A site-to-site VPN connects both environments. Applications see all databases as if they were on the same network.
Patching and updates — who does what?
This is a favourite exam topic. Know who is responsible for patching on each platform:
| Platform | OS Patching | SQL Engine Patching | You Manage? |
|---|---|---|---|
| SQL Database | Microsoft | Microsoft | No — fully automatic |
| Managed Instance | Microsoft | Microsoft | No — you pick a maintenance window |
| SQL on Azure VMs | You (or Azure Update Manager) | You (or automated patching) | Yes — schedule via SQL IaaS extension |
Azure Update Manager for SQL VMs
For SQL VMs, Azure Update Manager (formerly Update Management) automates OS and SQL patching:
- Define maintenance windows (day, time, duration)
- Apply patches during low-traffic periods
- Reboot policy: always, never, or if required
- Works across multiple VMs simultaneously
The SQL IaaS Agent extension integrates with Azure Update Manager to provide SQL-specific patching visibility and scheduling.
Tomas’s learning moment: His mentor Sam says: “The more managed the service, the less patching you do. SQL Database = zero effort. MI = pick a window. SQL VM = you own the schedule and the risk.”
Priya needs to deploy 15 identical Azure SQL databases across three Azure regions for a new product launch. Which deployment method should she choose?
Kenji's SQL Server on an Azure VM needs the latest cumulative update applied during a weekend maintenance window. What should he configure?
🎬 Video coming soon
Next up: Scale, Performance, and Compression — configure each Azure SQL platform for optimal scale, plus table partitioning and data compression.