Skip to main content

Database Deployment Automation — ARM, Bicep, PowerShell & CLI

Automating database deployment ensures consistency, repeatability, and auditability. No manual portal clicks in production — everything as code.

Infrastructure as Code (IaC) Options

ToolTypeBest ForLearning Curve
ARM TemplatesJSON declarativeLegacy deployments, complex dependenciesHigh
BicepDSL (compiles to ARM)All new Azure deploymentsLow-Medium
TerraformHCL declarativeMulti-cloud, team standardizationMedium
PowerShell (Az module)Imperative scriptingQuick tasks, automation runbooksLow
Azure CLIImperative CLIBash-friendly, CI/CD pipelinesLow
🎯 Exam Focus

DP-300 focus: You need to understand ARM/Bicep for declarative deployments, and PowerShell/CLI for imperative operations. Know the difference: declarative = "this is what I want" (ARM/Bicep/Terraform), imperative = "do this step by step" (PowerShell/CLI).

ARM Templates vs Bicep

AspectARM TemplateBicep
FormatJSONDSL (cleaner syntax)
ReadabilityVerbose, nestedClean, concise
ModulesNested templatesNative module support
ParametersJSON param files.bicepparam files
IntellisenseLimitedFull VS Code support
OutputJSON ARM templateCompiles to ARM JSON
Microsoft recommendationLegacy✅ Recommended
🏢 Real-World DBA Note

Always use Bicep for new deployments. ARM JSON templates are still supported but Bicep is Microsoft's recommended approach. Bicep files are 60-80% shorter than equivalent ARM JSON and have full VS Code IntelliSense.

What Can You Deploy?

ResourceBicep/ARMPowerShell/CLI
Logical SQL Server
Azure SQL Database
Elastic Pool
Managed Instance
Failover Group
Firewall Rules
Private Endpoint
SQL VM (IaaS)
VNet + NSG
Auditing + ATP

Deployment Patterns

Pattern 1: Full Environment (Bicep)

Deploy a complete environment in one command:

  • VNet + Subnet + NSG
  • Logical SQL Server + Databases
  • Firewall rules + Private Endpoint
  • Auditing → Log Analytics
  • Failover Group (cross-region)

This is the recommended production pattern — everything defined in code, version-controlled, repeatable.

Pattern 2: Database-Level Changes (PowerShell/CLI)

Day-to-day operations after initial deployment:

  • Scale vCores up/down
  • Change backup retention
  • Add/remove databases from elastic pool
  • Configure auto-tuning
  • Manage firewall rules

Pattern 3: CI/CD Pipeline (Azure DevOps / GitHub Actions)

Automated deployment on every code push:

  1. Developer commits Bicep/SQL script to Git
  2. Pipeline validates (what-if / plan)
  3. Approval gate for production
  4. Deploy infrastructure changes
  5. Deploy schema changes (DACPAC/SSDT)

Schema Deployment Tools

ToolWhat It DoesBest For
SSDT (SQL Server Data Tools)Visual Studio project for database schemaSchema version control, diff-based deploy
DACPACCompiled schema packageCI/CD pipeline schema deployment
SqlPackage.exeCLI tool to deploy DACPACsAutomation, cross-platform
dbup / Flyway / LiquibaseMigration-based schema changesIncremental migration scripts
EF Core MigrationsORM-based schema management.NET application teams
🎯 Exam Focus

DACPAC (Data-tier Application Package) is a key DP-300 concept. It contains a database schema definition and can be used to deploy schema changes or extract/import database structures. SqlPackage.exe is the CLI tool for DACPAC operations.

Azure DevOps Pipeline for SQL

A typical pipeline:

StageWhat Happens
BuildCompile SSDT project → produce DACPAC
ValidateRun what-if against target DB (dry run)
Deploy to DevAuto-deploy DACPAC to dev environment
TestRun integration tests against dev DB
Deploy to StagingDeploy to staging with approval gate
Deploy to ProdManual approval → deploy to production

Key Deployment Concepts

Idempotency

Declarative deployments (Bicep/ARM) are idempotent — running the same template twice produces the same result without errors. This is critical for reliable automation.

What-If / Preview

Always preview changes before deploying:

  • Bicep/ARM: az deployment group what-if
  • Terraform: terraform plan
  • DACPAC: SqlPackage /Action:DeployReport

State Management

ToolState
ARM/BicepAzure manages state (resource-level)
Terraform.tfstate file (you manage — use remote backend)
PowerShell/CLINo state (imperative = you track manually)
⚠️ Watch Out

Never deploy infrastructure changes from a developer's laptop to production. Always use a CI/CD pipeline with approval gates, audit logging, and rollback capability. Treat database deployments with the same rigor as application deployments.


Flashcards

What is the difference between declarative and imperative deployment?
Click to reveal answer
Declarative (Bicep/ARM/Terraform): 'This is what I want' — the tool figures out how. Imperative (PowerShell/CLI): 'Do this step by step' — you control the sequence.
1 / 5

Quiz

Q1/5
0 correct
Your team needs to deploy identical Azure SQL environments for dev, staging, and production. What approach should you use?