2.4 Hybrid SQL Server and IaaS Patching

The Hybrid SQL Server Landscape

Quick Answer: In a hybrid estate, SQL Server runs in three places: on-premises, on Azure Arc-enabled hosts projected into Azure, and on SQL Server on Azure VMs managed by the SQL Server IaaS Agent extension. Patching each has its own automation, but the goal is the same: apply cumulative updates and security fixes inside a defined maintenance window without taking the workload down.

The DP-300 exam treats patching as a deployment-lifecycle responsibility that shifts with the hosting model. On Azure SQL Database and SQL Managed Instance, Microsoft applies updates transparently inside platform maintenance windows (with configurable maintenance windows in the General Purpose and Business Critical tiers). On SQL Server on Azure VMs and on Arc-enabled on-premises instances, you own patching — and the exam tests the automation that makes that tractable.

SQL Server IaaS Agent Extension

The SQL Server IaaS Agent extension is a free extension that registers the VM with the SQL VM resource provider. Registration can run in two modes. Lightweight mode only reports edition and license metadata and never touches the SQL Server service; it is the default for marketplace images and requires no restart. Full mode installs the agent that unlocks all management features and requires a one-time restart of the SQL Server service during installation. Many portal capabilities and licensing benefits are gated on full-mode registration.

Once the extension runs in full mode, it enables the three features the exam tests for this domain:

• Automated patching — you define a maintenance window (day of week, start time, and duration). During the window the extension installs SQL Server updates that Microsoft Update marks applicable, including cumulative updates and critical security updates; patches outside the window are skipped. You can also disable automated patching to take full manual control, which is the right answer when a change advisory board must approve every update.
• Automated backup — scheduled full, differential, and log backups to Azure storage with configurable retention, eliminating the need for a custom backup script on standalone VMs.
• License management — the extension exposes a license type property that you can switch between Pay-As-You-Go (PAYG) and Azure Hybrid Benefit (AHUB) at any time as a metadata change, with no downtime and no redeployment.

License Type: PAYG vs Azure Hybrid Benefit

Two licensing models apply to SQL Server on Azure VMs. Pay-As-You-Go (PAYG) bundles the SQL Server license into the per-second VM price — zero procurement, highest steady-state cost, and the default for marketplace images that include licensing. Azure Hybrid Benefit (AHUB) lets you apply existing SQL Server licenses with active Software Assurance (or a qualifying subscription) and pay only the base compute rate, which can cut the SQL Server portion of the bill substantially for long-running production VMs. A third option, License-only (no AHUB, no PAYG billing for SQL Server), applies when the VM is used for dev/test under certain subscriptions that include free SQL Server licensing.

The operational fact the exam tests: through the SQL IaaS Agent extension you can change the license type at any time with no downtime and no redeployment — it is a metadata change on the registration. You do not need to rebuild the VM from a bring-your-own-license image. The exam frequently pairs this with a cost-optimization scenario where a company acquired Software Assurance mid-life and wants to apply it to an existing PAYG VM.

Cumulative Updates vs General Distribution Releases

SQL Server patching terminology matters on the exam. A Cumulative Update (CU) bundles all fixes released since the last baseline (service pack or base release) — fixes are cumulative, so installing the latest CU gets you everything. Microsoft recommends staying current with CUs for production systems and publishes a predictable CU cadence. A General Distribution Release (GDR) contains only critical security fixes and is the channel chosen when a workload must stay on the most conservative update path; GDRs do not include the functional and non-security fixes that CUs carry. A Service Pack was the old baseline-plus-rollup vehicle; modern SQL Server has largely moved to the CU model, and SQL Server 2022 onward does not ship service packs at all.

The decision rule the exam wants: choose the CU channel when you need the latest fixes and can validate them in a test environment; choose the GDR channel when policy mandates security-only updates. Either way, patch inside a maintenance window and validate that failover-aware steps are followed when the instance participates in an availability group.

Maintenance Windows on PaaS and IaaS

On Azure SQL Database and SQL Managed Instance, Microsoft patches the engine on a schedule. You can choose the platform-provided maintenance window in the General Purpose and Business Critical tiers so patches land outside your peak hours rather than the default window — a feature specifically aimed at production workloads that cannot tolerate unplanned failovers during business hours. On SQL Server on Azure VMs, you own the maintenance window through the IaaS Agent extension's automated patching configuration: pick a day of week, a start time, and a duration, and the extension installs only updates marked applicable during that window. If a scenario describes failovers or brief downtime happening at unpredictable times, the answer is to configure a maintenance window that aligns with the application's off-peak period.

Azure Arc-Enabled SQL Server Patch Management

Azure Arc-enabled SQL Server extends patch management to instances running on-premises or in another cloud. After the Azure Connected Machine agent and the Azure extension for SQL Server are installed, each instance appears as an Azure resource. From Azure you can then:

• View the installed SQL Server version, edition, and patch level alongside Azure-hosted instances in a single inventory.
• Run best-practices assessments and migration readiness checks.
• Apply cumulative updates centrally where supported, and track compliance through Azure Update Manager, which schedules update installations across Arc-connected machines.
• Activate pay-as-you-go billing per core-hour for instances that lack Software Assurance, instead of buying licenses outright.

The exam contrast to draw: Azure Arc does not convert an on-premises instance into SQL Managed Instance, and it does not move any data to Azure. It projects the instance into Azure for management, inventory, identity (Microsoft Entra authentication on SQL Server 2022 and later), and patch orchestration. When a scenario says the databases must stay on-premises but patching and inventory need to be centralized in Azure, Arc is the answer.

Failover-Aware Patching for Always On Availability Groups

When the SQL Server instance participates in an Always On availability group (AG), patching must preserve availability. The rolling patch sequence the exam expects:

1. Patch a synchronous-commit secondary replica first. Install the CU, restart the SQL Server service, and let the replica resynchronize.
2. Fail over the AG so the patched secondary becomes the primary. This is a planned manual failover; confirm the new primary is healthy before continuing.
3. Patch the former primary (now a secondary). Install the CU and restart; it resynchronizes as a secondary.
4. Optionally fail back to the original primary if your disaster-recovery topology requires a specific primary.

This rolling approach keeps at least one replica serving the workload throughout. It requires the AG to have at least two replicas with synchronous-commit mode and automatic failover (or a planned manual failover). For a single-replica deployment there is no failover-aware option — patching incurs downtime. A failover cluster instance (FCI) on Azure VMs is patched one node at a time: patch the passive node, fail the FCI over, then patch the now-passive former active node. The same principle applies: keep one node serving while the other is patched.

Patching Decision Matrix

A final trap: automated patching on a VM installs updates Microsoft Update marks applicable, but it does not coordinate failover for you. For an AG, you still perform the rolling failover sequence manually (or automate it with PowerShell) before each node's patch window. The IaaS Agent extension's automated patching is a single-instance convenience, not an AG-aware orchestrator.