The DP-300 exam repeatedly tests your ability to choose the right Azure SQL deployment model for a given scenario. Azure SQL Database, Azure SQL Managed Instance, and SQL Server on Azure VM may sound like variations of the same service, but they differ fundamentally in management responsibility and feature support. Think of it as the difference between booking a hotel room, leasing an entire office floor, and buying a building outright. Once you commit to a deployment model, switching means a full migration project, so the initial choice matters.
Azure SQL Database — The Hotel Room Model
When you stay in a hotel, you manage only your room. The building structure, elevators, and electrical systems are the hotel's responsibility. Azure SQL Database works the same way. Microsoft handles the OS, SQL Server engine patching, backups, and high availability, while you focus on schema design, query performance, and access control.
Three service tiers are available: General Purpose for standard workloads, Business Critical with in-memory replicas and a readable secondary, and Hyperscale with distributed storage that scales to 100 TB. The Serverless compute tier pauses automatically during idle periods to save cost. For multi-tenant SaaS architectures, Elastic Pool lets hundreds of databases share a single compute pool. What Azure SQL Database cannot do is equally important: SQL Server Agent, cross-database queries, CLR assemblies, and Service Broker are not supported.
Azure SQL Managed Instance — The Leased Office Floor Model
Leasing an entire office floor lets you arrange the interior however you want. The building shell and elevators stay the landlord's responsibility. Azure SQL Managed Instance follows this pattern. Microsoft manages the OS and infrastructure, but at the instance level you get near-complete SQL Server feature parity.
SQL Server Agent, cross-database queries, CLR assemblies, Service Broker, Linked Servers, and Database Mail all work in Managed Instance. Compatibility is approximately equivalent to SQL Server 2019, making it the natural destination for lift-and-shift migrations from on-premises SQL Server with minimal code changes. Managed Instance deploys into a dedicated VNet subnet with native VNet integration, enabling direct connectivity from on-premises via ExpressRoute or Site-to-Site VPN. Instance Pool lets multiple smaller Managed Instances share a compute pool to reduce cost.
SQL Server on Azure VM — The Building Owner Model
Owning a building means you can knock down walls or run a server room in the basement. You have complete control, but every repair is your responsibility. SQL Server on Azure VM gives full control over the OS and SQL Server version, but patching, backups, and monitoring fall entirely to your team.
This model is needed when OS-level access is required for a third-party tool, when a specific older SQL Server version must be maintained, or when a Windows Server Failover Cluster with Failover Cluster Instance or a manually configured Always On Availability Group is needed. Azure Hybrid Benefit lets existing on-premises licenses reduce cost.
Azure Arc-enabled SQL Server — Hybrid Extension
Imagine connecting remote warehouse inventory systems to headquarters in real time, regardless of where each warehouse is located. Azure Arc-enabled SQL Server plays a similar role. SQL Server instances running on-premises or in other clouds connect to the Azure control plane, enabling Azure Policy, Microsoft Defender for SQL, and Azure Monitor to be applied uniformly across all of them.
Infrastructure responsibility still belongs to the on-premises or remote team. It is IaaS in nature, but Azure management tooling and security policies extend beyond Azure boundaries. When an exam scenario mentions hybrid SQL management through the Azure control plane, Azure Arc-enabled SQL Server is the answer.
Hyperscale and Serverless — Specialized Tiers
A library that grows beyond 100,000 volumes eventually needs automated storage systems rather than ordinary shelves. Azure SQL Database Hyperscale is built for a similar situation. Storage scales automatically up to 100 TB, snapshot-based backups complete almost instantly, and read scale-out is supported.
Serverless addresses the opposite scenario: a workload that is busy in the morning and completely idle at night, such as an internal business application used only during office hours. Compute pauses automatically when there is no activity, reducing costs during idle periods. Both tiers exist within Azure SQL Database but solve very different problems — keeping them as separate mental categories helps on the exam.
Choosing Between Models
When deciding whether to buy or lease a car, the most important question is how you plan to use it. Choosing an Azure SQL deployment model works the same way. A few targeted questions narrow the options quickly.
SQL Server Agent, CLR, or cross-database queries needed? Choose Managed Instance — PaaS with instance-level features. OS control or a specific SQL Server version required? Choose SQL Server on Azure VM. Minimize overhead with a single database? Choose Azure SQL Database. Manage on-premises or multi-cloud SQL through Azure? Choose Azure Arc-enabled SQL Server.
When deciding between Managed Instance and Azure SQL Database, SQL Server Agent is the single deciding question. If it is required, choose Managed Instance. If not, Azure SQL Database is simpler and cheaper. Also remember: Azure SQL Database and Managed Instance include automatic backups by default; SQL Server on Azure VM does not.
!Choosing an Azure SQL deployment model
Common Exam Traps
Ordering from a menu by photo alone sometimes leads to surprises. Azure SQL deployment models work the same way when chosen by name rather than by features.
The most common trap is assuming PaaS means full feature parity. SQL Server Agent and CLR work in Managed Instance, which is PaaS, but not in Azure SQL Database, which is also PaaS. The moment SQL Server Agent appears as a hard requirement in an exam scenario, eliminate Azure SQL Database before reading further.
The second trap is confusing Elastic Pool with Instance Pool. Elastic Pool groups multiple Azure SQL Databases into a shared compute pool. Instance Pool groups multiple Managed Instances into a shared compute pool. Both use the word 'pool,' but the pooled resource is different.
Exam Key Takeaways
"Minimize operational overhead + single database" -- Azure SQL Database
"SQL Server Agent required + stay on PaaS" -- Azure SQL Managed Instance
"OS access needed / specific SQL version required" -- SQL Server on Azure VM
"Multi-tenant SaaS + cost optimization" -- Azure SQL Database + Elastic Pool
"Over 100 TB + fast snapshots + read scale-out" -- Azure SQL Database Hyperscale
"Intermittent workload + auto-pause" -- Azure SQL Database Serverless
"Manage on-premises SQL from Azure control plane" -- Azure Arc-enabled SQL Server
"Cross-database queries + lift-and-shift migration" -- Azure SQL Managed Instance
"Elastic Pool vs Instance Pool" -- pool of Databases (Elastic Pool) vs pool of Managed Instances (Instance Pool)
"Automatic backup without extra configuration" -- Azure SQL Database and Managed Instance yes, SQL Server on Azure VM no
Azure SQL Database = fully managed single DB PaaS, Azure SQL Managed Instance = instance-compatible PaaS, SQL Server on Azure VM = full-control IaaS