The DP-300 exam's automation section asks "which tool belongs to which deployment model." The dividing line between SQL Server Agent on Managed Instance and Elastic Jobs on Azure SQL Database is the exam's central axis. ARM/Bicep, Azure PowerShell, Azure CLI, and Azure Automation each occupy a distinct role, and knowing when to reach for each one separates correct answers from common traps.
SQL Server Agent — The In-House Executive Assistant
Imagine a dedicated executive assistant who knows the CEO's schedule inside and out and handles every task — but never travels to branch offices. That is SQL Server Agent. It runs exclusively on Azure SQL Managed Instance and SQL Server on Azure Virtual Machines. Azure SQL Database does not support it at all, and this boundary is the most tested fact about SQL Server Agent on the DP-300.
The core building blocks are four components. A is the unit of work. are individual tasks that execute in sequence inside a Job, each selecting a type: T-SQL, PowerShell, SSIS package, or CmdExec. A defines when the Job runs, and an is the person who receives notifications.
Database Mail closes the notification loop. Configure an SMTP profile, link it to an Agent Alert, and a failing Job automatically sends an email to the Operator. All metadata — Jobs, Schedules, Alerts, Operators — lives in the system database. Proxy accounts let specific Job Steps run under least-privilege credentials, though they apply only to external subsystems (CmdExec, PowerShell, SSIS) — not to T-SQL steps.
Elastic Jobs — The Regional Supervisor
Managing one office is straightforward. Distributing the same checklist to a hundred branches and collecting results simultaneously is a different challenge. Elastic Jobs runs T-SQL scripts across multiple Azure SQL Databases, Elastic Pools, and servers in parallel. It works exclusively within the Azure SQL Database ecosystem — Managed Instance and SQL on VM are not supported targets.
Three components make up an Elastic Jobs setup. The is a dedicated Azure SQL Database storing job definitions and execution history. The defines the collection of databases — individual databases, Elastic Pools, or whole servers — that a job runs against, with precise include/exclude control. The is the managed execution engine that orchestrates everything.
Picture a multi-tenant SaaS product with dozens of tenant databases that each need a new column added monthly. With SQL Server Agent you would access each database individually. Elastic Jobs registers all tenant databases in a target group and fires one job that runs on every database at once. Failures are recorded per database, so you retry only the ones that failed.
ARM Templates and Bicep — Building from Blueprints
When a construction crew follows the same blueprints every time, every building comes out identical. If they improvise, subtle differences accumulate. ARM templates and Bicep are the blueprints for Azure infrastructure.
An ARM template declares Azure resources in JSON. You declare "these resources should exist in this configuration" and Azure Resource Manager analyzes dependencies and deploys in the correct order. The key advantage is idempotency — running the same template multiple times always yields the same end state. A partial failure followed by a retry only creates the missing resources. Templates integrate directly into GitHub Actions or Azure Pipelines as deployment steps.
Bicep is the official domain-specific language for ARM. It expresses the same definitions with roughly 40% fewer lines and compiles to ARM JSON at deploy time. The functional result is identical. DACPAC packages database schema only; BACPAC packages both schema and data. Both appear in deployment automation scenarios alongside ARM and Bicep.
Azure PowerShell and Azure CLI — On-Site Command Tools
If ARM templates declare what should exist, Azure PowerShell and Azure CLI issue immediate, imperative commands: "create this resource right now."
The PowerShell module provides cmdlets such as , , and . PowerShell's object pipeline and conditional constructs suit complex automation logic. The Azure CLI's command group delivers the same capabilities cross-platform — the same commands run on Windows, macOS, and Linux, making them natural for Linux-based CI/CD agents and GitHub Actions runners.
Both tools support non-interactive authentication via Service Principals or Managed Identities. Setting a default resource group with removes the need for in every subsequent command; the setting persists in across Cloud Shell sessions.
Azure Automation — Orchestration Across the Hybrid World
When on-premises servers still exist but you need the same automation policies applied everywhere, Azure Automation bridges that gap.
are PowerShell or Python scripts scheduled in the cloud or triggered by events. The role extends execution to on-premises servers or VMs in other clouds, letting the same Runbook run inside a firewall-protected datacenter. Unlike SQL Server Agent or Elastic Jobs, Azure Automation is an external orchestrator managing resources from outside the SQL instances. Additional capabilities include for patch tracking, for configuration drift, and for declarative server state management.
Decision Guide — When to Use Which Tool
A good toolbox has both a hammer and a screwdriver, but using the hammer on a screw is a mistake. Knowing each tool's boundary is the core skill for both the DP-300 and real-world automation.
: Managed Instance and SQL on VM only. In-instance T-SQL jobs, nightly maintenance, Database Mail alerts : Azure SQL Database only. Simultaneous T-SQL execution across multiple DBs, Pools, and Servers : All Azure resources. Declarative IaC, environment consistency, GitHub Actions integration : All Azure resources. Imperative scripting, CI/CD pipeline steps : Cloud and on-premises. Runbook scheduling, Hybrid Worker, DSC
Common Exam Traps — Where Candidates Go Wrong
"Deploy a schema change to multiple Azure SQL Databases simultaneously" is a classic trap. SQL Server Agent cannot cross instance boundaries — the correct answer is Elastic Jobs.
The reverse is equally tricky: "schedule a nightly index rebuild on Managed Instance" paired with Elastic Jobs is wrong, because Elastic Jobs supports only Azure SQL Database. For repeated environment deployments, ARM/Bicep is the right pick. For a single immediate change to an existing resource, one Azure CLI command suffices. Combining declarative and imperative tools is the real-world pattern the exam reflects.
Exam Key Takeaways
"Nightly index maintenance job on Managed Instance" -- SQL Server Agent "Install SQL Server Agent on Azure SQL Database" -- Not possible (Database is unsupported) "Run ALTER TABLE on 100 tenant databases at once" -- Elastic Jobs "Job execution history storage" -- msdb (Agent) / Job database (Elastic Jobs) "Declarative IaC with idempotency guarantee" -- ARM template / Bicep "What Bicep compiles into" -- ARM JSON "Automate SQL server creation in GitHub Actions" -- Azure PowerShell or Azure CLI "Execute a Runbook on an on-premises SQL Server" -- Azure Automation Hybrid Runbook Worker "Database Mail SMTP profile, sp_send_dbmail" -- SQL Server Agent notifications (MI/VM only) "DACPAC vs BACPAC" -- DACPAC = schema only, BACPAC = schema + data
SQL Server Agent = Managed Instance and SQL on VM exclusive, Elastic Jobs = Azure SQL Database only