Exam Domain 1.3 asks you to implement and manage Azure SQL Managed Instance, which is the bridge between fully managed databases and full control. For DP-300, understanding this service is critical because it is the go-to choice when a company wants to move its existing on-premises SQL Server databases to the cloud without rewriting applications or losing features like SQL Server Agent jobs and cross-database queries.
Jump to a section
A simple way to picture Deploying and Configuring Azure SQL Managed Instance
You are a property developer who wants to build a high-end apartment block, but you don’t want to maintain the roads, sewage pipes, or streetlights yourself.
Your first option is to buy a bare plot of land, hire contractors to lay all the pipes and cables, install the streetlights, and only then start constructing your building. That’s like setting up a virtual machine and installing SQL Server yourself — you manage the operating system, the networking, the storage, and the database engine. It’s possible, but it’s a lot of work.
Your second option is to rent an entire floor in an existing building that already has power, water, and internet connected. You can paint the walls and arrange the furniture, but you don’t touch the main electrical panel or the water mains. That’s like Azure SQL Database — a fully managed single database where Microsoft handles the infrastructure.
Azure SQL Managed Instance is your third option: you buy the entire apartment block, you own the structure and the common areas, but the street outside, the main water pipe, and the high-voltage cables are still managed by the city council. As the owner, you can change the layout of the apartments and install custom lighting in the lobby, but you don’t have to worry about the sewage treatment plant or the power station. In technical terms, you get near-100% compatibility with on-premises SQL Server (like being able to use SQL Server Agent, cross-database queries, and linked servers) without managing the underlying virtual machines, storage, or high-availability patches. That is precisely what Azure SQL Managed Instance gives a database administrator: the control of a full SQL Server instance with the benefits of a managed service.
Azure SQL Managed Instance is a platform-as-a-service (PaaS) offering from Microsoft. PaaS means you do not manage the operating system, the virtual machine, or the physical hardware. You just manage your databases, logins, and configurations inside the instance. Think of it as a pre-configured SQL Server that lives in Microsoft’s data centre and is always on, always patched, and always backed up.
Why does this service exist? Many companies have applications built for an on-premises SQL Server instance. Those applications might use features like SQL Server Agent for scheduled jobs, cross-database queries (queries that read from more than one database at once), or linked servers to connect to other databases. If they moved their databases to Azure SQL Database (the simpler PaaS option), those features would not be available. They would have to rewrite their applications. Migration would be expensive and risky. Azure SQL Managed Instance solves this problem by providing near-100% compatibility with on-premises SQL Server. It supports SQL Server Agent, cross-database queries, linked servers, Service Broker, and even common SQL Server features like CLR (Common Language Runtime) integration.
How does it work? When you deploy a Managed Instance, you first create a virtual network (VNet) in your Azure subscription. A VNet is like a private network segment in the cloud, isolated from the public internet. The Managed Instance is placed inside a subnet (a smaller part of the VNet) that has special configuration rules. This subnet is dedicated to Managed Instances and is automatically configured with network security groups (NSGs) that control traffic. Microsoft handles all the patching, backups, and high-availability by running multiple replicas of the instance across different physical servers in the same Azure region.
Key characteristics of Azure SQL Managed Instance include:
It provides a fully managed SQL Server instance with automatic backups, patching, and high-availability.
It supports native virtual network (VNet) placement, meaning it lives inside your private network and can communicate securely with other Azure services and on-premises networks via VPN or ExpressRoute.
It offers near-100% surface area compatibility with on-premises SQL Server, which means most SQL Server features (like Database Mail, SQL Server Agent, linked servers, and cross-database queries) are available.
You can choose from different service tiers: General Purpose (GP) for cost-optimised workloads with higher latency, and Business Critical (BC) for low-latency, high-performance workloads with multiple readable replicas for disaster recovery.
What does this replace? Traditionally, a company would buy physical servers, install Windows Server, install SQL Server, configure storage, set up backup jobs, and arrange for a disaster recovery plan. With Azure SQL Managed Instance, Microsoft does almost all of that. You just create the instance, connect to it, and start deploying your databases. It also replaces the need for a dedicated database administrator (DBA) to manage operating system patches, disk space, and high-availability failovers.
A real example: Suppose you run a logistics company with a legacy SQL Server 2016 instance that hosts a custom tracking application. The application uses SQL Server Agent to run nightly batch jobs that calculate delivery routes across multiple databases. To move this application to the cloud, you cannot use Azure SQL Database because it does not support SQL Server Agent instances. Instead, you deploy a Managed Instance. You migrate your databases using a tool like the Azure Database Migration Service (DMS) or by manually restoring a backup file. Once the databases are in the Managed Instance, you create the same SQL Server Agent jobs, configure linked servers to your on-premises data sources, and your application runs exactly as before, now in the cloud.
The instance size is defined by a service tier (General Purpose or Business Critical) and storage capacity. You can scale the instance by increasing vCores (virtual cores — the compute power) or adding storage. Microsoft manages the backup retention periods (7 to 35 days) and you can configure long-term retention for up to 10 years. You also get a built-in point-in-time restore capability, which lets you restore a database to any point within the retention window.
Security: Because the Managed Instance is placed inside your VNet, it is not accessible from the public internet by default. You must connect from within the VNet, from an on-premises network via VPN or ExpressRoute, or from a permitted client via a public endpoint that you explicitly configure. Authentication can be done with SQL Server logins or with Microsoft Entra ID (formerly Azure Active Directory) credentials. Microsoft Entra ID authentication allows you to use the same corporate identities you use for Office 365 and other cloud services.
In summary, Azure SQL Managed Instance gives you a lift-and-shift path to the cloud: you move your existing SQL Server instance as-is, with minimal changes, while Microsoft handles the heavy lifting of infrastructure maintenance.
Assess compatibility
Use the Azure SQL Migration Assessment tool to scan your on-premises SQL Server instance. This tool generates a report highlighting features that are unsupported or need changes. This step is critical because it confirms whether Azure SQL Managed Instance is the right target, saving you from migration failures later.
Create a virtual network and dedicated subnet
In the Azure portal, create a virtual network (VNet) with an address space large enough for the subnet. Then create a subnet within that VNet and delegate it to 'Microsoft.Sql/managedInstances'. This delegation tells Azure that only Managed Instances can use this subnet, and it enables automatic configuration of needed networking rules.
Configure network security group and route table
Azure automatically creates a network security group (NSG) and a route table for the subnet. You must ensure that the NSG allows required inbound and outbound traffic for the Managed Instance (e.g., for management endpoints). The route table ensures traffic from the instance can reach Azure services securely. This step is essential for the instance to function correctly.
Deploy the Managed Instance
In the Azure portal, search for 'Azure SQL Managed Instance' and fill in the configuration details: resource group, instance name (must be globally unique), region, SQL admin credentials, compute and storage specifications (vCores and storage size), and the service tier (General Purpose or Business Critical). Select the VNet and subnet you created. Click 'Review + create' to deploy. Deployment can take several hours as Azure provisions the underlying infrastructure.
Connect and validate the instance
Once deployment is complete, retrieve the fully qualified domain name (FQDN) from the overview page. Connect using SQL Server Management Studio (SSMS) from a virtual machine inside the same VNet, or via a VPN if connecting from on-premises. Run a test query to confirm the instance is operational. Do not try to connect from the internet unless you have explicitly enabled the public endpoint.
An IT professional, usually a database administrator (DBA) or a cloud architect, uses Azure SQL Managed Instance when their company has made the strategic decision to migrate to the cloud but cannot afford to rewrite applications.
Let us walk through a realistic scenario. You work at ‘Northwind Traders’, a wholesale company with 30 databases running on two on-premises SQL Server 2016 instances. The company’s board has approved a cloud-first strategy, so you need to migrate these databases to Azure within six months. The catch: the company’s main enterprise resource planning (ERP) application relies heavily on SQL Server Agent jobs that run at midnight to move data between databases, and the application also uses linked servers to pull data from a legacy FoxPro database still running on-premises.
Step 1: Assessment. You use the Azure SQL Migration Assessment tool to scan your on-premises instances and list all incompatibilities. The report shows that around 95 percent of features are compatible, but a few linked server configurations and SQL Server Agent jobs need minor adjustments. You decide that Azure SQL Managed Instance is the right target because it supports these features natively.
Step 2: Infrastructure preparation. You log into the Azure portal and create a resource group (a container for related resources). You then create a virtual network with a dedicated subnet for the Managed Instance. This subnet must be delegated to ‘Microsoft.Sql/managedInstances’. You also configure a route table and a network security group (NSG) to control traffic. This is critical because the Managed Instance is inside your private network, and you need to ensure it can communicate with your on-premises servers via a site-to-site VPN.
Step 3: Deploy the instance. In the Azure portal, you choose ‘Create a resource’, search for ‘Azure SQL Managed Instance’, and fill in the details: resource group, instance name, region, credentials for the SQL admin login, compute + storage specifications (e.g., 8 vCores, 500 GB storage, General Purpose tier). You also select the VNet and subnet. The deployment takes a few hours because Azure is provisioning the infrastructure and setting up high-availability replicas in the background.
Step 4: Connect and validate. Once the deployment shows as ‘Ready’, you get a fully qualified domain name (FQDN) like ‘northwind.xxxx.database.windows.net’. To connect, you cannot just use SQL Server Management Studio (SSMS) from your home computer because the instance is in a private VNet. You either connect from a virtual machine inside the same VNet, or you set up a point-to-site VPN or an Azure Bastion host. You test the connection from a jump box VM that you spin up in the same VNet. You run a quick query to verify the instance is operational.
Step 5: Migration. You use the Azure Database Migration Service (DMS) to perform an online migration with minimal downtime. DMS reads the source databases from your on-premises SQL Server and streams them to the Managed Instance. You configure a time window for the final cutover: during a weekend maintenance window, you stop the application, sync the last changes, and switch the connection string to point to the new instance.
Step 6: Post-migration. You re-create the SQL Server Agent jobs, adjust the linked server connection strings to point to the on-premises FoxPro server via the VPN, and run the application. Everything works. You then configure backup settings: the instance already has automated backups, but you enable long-term retention for compliance purposes, keeping backups for 10 years. You also set up alerts for CPU usage and storage space using Azure Monitor.
The DBA in this scenario has successfully moved 30 databases with minimal code changes, saved the company from expensive application rewrites, and now manages the instance entirely through the Azure portal, without ever touching an operating system patch or a physical disk.
The DP-300 exam focuses on your ability to decide when Azure SQL Managed Instance is the correct solution, how to deploy it, how to configure networking, and how to migrate databases to it. Expect questions that test your understanding of its features and limitations compared to Azure SQL Database and SQL Server on Azure Virtual Machines.
Key exam topics and patterns:
Identifying the right service choice: The exam loves to present a scenario where a company uses SQL Server Agent jobs, cross-database queries, linked servers, or Service Broker. If the scenario includes any of these, the correct answer is almost always Azure SQL Managed Instance, not Azure SQL Database. Azure SQL Database does not support SQL Server Agent (it only has Elastic Jobs, which is different) and does not allow cross-database queries natively.
Networking requirements: You must understand that a Managed Instance is deployed into a dedicated subnet and that this subnet cannot have any other resources. The subnet must be delegated and have a route table and NSGs. The exam may ask what happens if you try to create an instance in a subnet that already has resources — it will fail. They may also ask about the public endpoint: by default, the instance has no public endpoint; you must explicitly enable it if you need to connect from the internet.
Service tiers and performance: General Purpose vs. Business Critical. General Purpose uses remote storage (slower, but cheaper) and has a single primary replica. Business Critical uses local SSDs for low latency and has four replicas total (one primary, three secondaries) for high availability and read-scale. The exam may ask you to recommend a tier based on latency requirements or recovery point objective (RPO).
Migration tools and methods: Expect questions about the Azure Database Migration Service (DMS) for online migrations with minimal downtime. Also know about offline migration using a .bak file restore. The exam may test whether you know that the Managed Instance can restore a full backup from an on-premises SQL Server, but only if the backup file is stored in Azure Blob Storage (a cloud storage service for large objects like files and backups). The backup must also be taken from a SQL Server version that is compatible (SQL Server 2012 and above).
Trap patterns: A common trap is confusing the features of Azure SQL Database with those of Managed Instance. For example, the exam might describe a scenario that requires SQL Server Agent jobs, and one answer option says ‘Use Azure SQL Database’. That is a distractor. Another trap is assuming that because Managed Instance is PaaS, you can change the underlying operating system configuration — you cannot. The exam may also test that the instance name must be globally unique across all of Azure, not just within your subscription.
Authentication: The exam checks your knowledge of Microsoft Entra ID authentication integration. You must know that you can set an Microsoft Entra ID admin for the Managed Instance, and that authentication can be either SQL logins or Microsoft Entra ID principals. They might ask which authentication method to use for a company that already uses Microsoft Entra ID for all employees — the answer is Microsoft Entra ID authentication for easier identity management.
Definitions to memorise:
VNet (virtual network): A private network in Azure.
Subnet delegation: Assigning a subnet to a specific Azure service (like Managed Instance).
General Purpose tier: Cost-optimised, uses remote storage, RPO of 10-15 minutes.
Business Critical tier: Performance-optimised, uses local SSD storage, RPO of less than 5 minutes.
DMS (Database Migration Service): Tool for online migrations with near-zero downtime.
Point-in-time restore (PITR): Restore a database to any time within the backup retention window.
Public endpoint: An optional way to connect to the instance over the internet (requires additional firewall rules).
The exam also tests you on limitations: Managed Instance has a maximum storage size (currently up to 16 TB for General Purpose and 4 TB for Business Critical). You cannot change the server-level collation (the rules for sorting and comparing text data) after creation. You cannot move the instance between VNets without redeploying. These are all potential exam scenarios.
Finally, be ready for scenario-based questions that ask: ‘A company has a legacy application that uses SQL Server Reporting Services (SSRS). Can they use Managed Instance?’ The answer is no — SSRS is not supported in Managed Instance. For SSRS, you need SQL Server on a virtual machine. Knowing what is not supported is as important as knowing what is supported.
Azure SQL Managed Instance is a PaaS service that provides near-100% compatibility with on-premises SQL Server, including SQL Server Agent, cross-database queries, and linked servers.
A Managed Instance must be deployed into a dedicated subnet within a virtual network, and that subnet cannot contain any other resources.
By default, Azure SQL Managed Instance has no public endpoint; you can enable one but it requires explicit firewall rules.
The two service tiers are General Purpose (cost-optimised with remote storage) and Business Critical (performance-optimised with local SSD storage and multiple readable replicas).
Use the Azure Database Migration Service (DMS) for online migrations with minimal downtime from on-premises SQL Server to Azure SQL Managed Instance.
Azure SQL Managed Instance supports point-in-time restore to any point within the backup retention window (7–35 days) and long-term backup retention up to 10 years.
Microsoft Entra ID authentication is supported, allowing you to use corporate identities instead of SQL logins.
You cannot change the server-level collation, the VNet, or the subnet after the instance is deployed without redeploying.
These come up on the exam all the time. Here's how to tell them apart.
Azure SQL Instance
Supports SQL Server Agent jobs across multiple databases.
Supports cross-database queries and linked servers.
Isolated inside a private virtual network by default.
Azure SQL Database
Only supports Elastic Jobs (different from SQL Server Agent).
Each database is isolated; cross-database queries are limited.
Has a public endpoint by default with firewall rules.
General Purpose Tier
Uses remote storage (slower, cost-optimised).
Single primary replica; recovery point objective (RPO) of 10-15 minutes.
Recommended for dev/test or lower workload requirements.
Business Critical Tier
Uses local SSD storage (low latency, high performance).
Four replicas total (one primary, three secondaries) for high availability.
Recommended for production workloads with strict latency and RPO requirements.
Azure SQL Managed Instance
PaaS: Microsoft manages OS patches, backups, and high availability.
Near-100% SQL Server feature compatibility (except SSRS and SSIS).
Scaling is limited to vCores and storage within the service tier.
SQL Server on Azure VM
IaaS: You manage everything including the OS and SQL Server.
Full compatibility with all SQL Server features, including SSRS and SSIS.
Full control over VM size, storage, and configuration, but more management overhead.
Mistake
Azure SQL Managed Instance is the same as SQL Server on a virtual machine.
Correct
Azure SQL Managed Instance is a PaaS service where Microsoft manages the OS, patching, and backups. SQL Server on a virtual machine is IaaS where you manage everything including the OS and SQL Server itself.
Both run SQL Server, and beginners see 'instance' in the name and assume it must be a VM. The key difference is who manages the underlying infrastructure.
Mistake
I can connect to Azure SQL Managed Instance from anywhere on the internet using just a username and password.
Correct
By default, the instance is isolated in a private VNet and cannot be reached from the public internet. You must connect from within the VNet, via VPN, or explicitly enable the public endpoint and configure firewall rules.
People are used to Azure SQL Database, which has a public endpoint by default with firewall rules. They assume Managed Instance works the same way.
Mistake
Azure SQL Managed Instance supports all SQL Server features, including Reporting Services and Integration Services.
Correct
It does not support SQL Server Reporting Services (SSRS) or SQL Server Integration Services (SSIS) in the traditional sense. SSIS packages can run but require Azure Data Factory or a separate SSIS integration runtime. SSRS is not supported at all.
The phrase 'near-100% compatibility' leads people to think it is 100%. The exam tests the specific features that are not available.
Mistake
Once I deploy an Azure SQL Managed Instance, I can change its subnet or VNet whenever I want.
Correct
You cannot change the subnet or VNet after deployment. If you need a different network configuration, you must redeploy the instance and migrate the databases again.
Beginners think network configuration is easy to adjust like a setting, not realising the instance is deeply tied to its subnet at the infrastructure level.
Mistake
Azure SQL Managed Instance is always cheaper than running SQL Server on virtual machines.
Correct
It can be more expensive for high-performance needs because you pay for the PaaS premium. For heavy workloads with many vCores, a reserved VM instance might be cheaper, but you pay more in management effort.
People assume managed services are always cheaper, but the cost depends on workload size, licensing, and operational overhead.
Mistake
I can use the same backup retention policies as on-premises SQL Server.
Correct
Backup retention is configured in Azure and ranges from 7 to 35 days for point-in-time restores. Long-term retention (up to 10 years) is available but must be set up separately and uses a different pricing model.
On-premises DBAs are used to managing their own backup schedules and tape rotations, and they expect the same level of control in the cloud.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure SQL Database is a single database PaaS offering with limited compatibility (no SQL Server Agent, no cross-database queries). Azure SQL Managed Instance is a full SQL Server instance in the cloud with near-100% feature compatibility, including SQL Server Agent, linked servers, and cross-database queries.
By default, no. The instance is inside a private virtual network. You need to connect from a machine within that VNet, via a VPN, or by enabling the public endpoint and adding your IP address to the firewall rules.
Typically between 2 to 6 hours. It depends on the region, the selected service tier, and the amount of storage. Plan your deployment well in advance of any migration deadline.
Yes, you can use the Azure Database Migration Service (DMS) for an online migration with minimal downtime. DMS continuously syncs changes from the source to the target until you are ready for a cutover.
No, SSRS is not supported in Azure SQL Managed Instance. If you need SSRS, you must deploy SQL Server on a virtual machine in Azure.
You will receive an error when trying to insert data or when automatic backups fail. You must scale up the storage in the Azure portal. The instance does not automatically expand storage.
You've finished Deploying and Configuring Azure SQL Managed Instance. Continue through the DP-300 study guide to build a complete picture of the exam.
Done with this chapter?