Overview
Domain 5 carries 20–25% of DP-300 and has three functional groups. Planning covers recommending an HA/DR strategy from RPO and RTO, evaluating hybrid and Azure-specific options, and planning tests. Backup and restore covers strategy, native backup and restore, point-in-time restore, long-term retention, T-SQL commands and backup to and restore from cloud storage.
The configuration group covers active geo-replication, Always On availability groups on Managed Instance and Azure VMs as listed by Microsoft, failover groups, failover cluster instances on Azure VMs, log shipping, and monitoring and troubleshooting HA/DR. Most questions turn on two facts: what each platform supports, and how much data loss and downtime the business accepts.
How it's tested
Expect a business requirement such as a five-second RPO, a one-hour RTO or seven years of monthly backups, plus a platform. You choose the HA/DR feature, backup setting or restore method, and sometimes the step that fixes a broken replica or failover.
-
Targets to features
RPO, RTO, region scope and automatic failover needs decide between built-in HA, geo-replication, failover groups and AGs.
-
Restore the right way
Accidental deletes, corruption or audits point to point-in-time restore, geo-restore or long-term retention backups.
-
Platform fit
VMs need clustering choices, Managed Instance uses failover groups, and Azure SQL Database adds active geo-replication.
A finance app on Azure SQL Database needs automatic regional failover without changing connection strings. Active geo-replication offers readable secondaries but failover is per database and the endpoint changes. A failover group provides read-write and read-only listener endpoints that follow the primary, and a Microsoft-managed failover policy can trigger regional failover. So the failover group meets the connection string requirement while still replicating asynchronously.
Functional groups 3
Official functional groups from the Microsoft outline, in outline order.
5.1 Plan an HA/DR strategy for database solutionsRPO and RTO based design, hybrid and Azure-specific options, and testing procedures.
- What it means
- This group covers recommending an HA/DR strategy from recovery point and recovery time objectives, evaluating HA/DR for hybrid deployments, evaluating Azure-specific HA/DR solutions, and planning a testing procedure for an HA/DR solution.
- What to understand
- RPO is the acceptable data loss and RTO the acceptable downtime. Azure SQL Database and Managed Instance include built-in high availability, with zone redundancy for higher resilience. Business Critical uses Always On replicas internally. For regional disasters, choose geo-replication or failover groups, or rely on geo-restore when hours of RTO are acceptable. Hybrid designs include the Managed Instance link for DR between SQL Server and Managed Instance, and distributed availability groups between sites. Testing should use planned failovers, restores to new databases and documented runbooks, measured against targets.
- How it shows up
- Expect RPO and RTO numbers with a platform and budget, and a choice of the minimal feature that meets them.
- Common confusion
- Treating geo-restore as a low RTO option; it restores from geo-replicated backups and can take hours.
5.2 Plan and perform backup and restore of a databaseBackup strategy, native backup and restore, point-in-time restore, long-term retention, T-SQL and cloud storage.
- What it means
- This group covers recommending a backup and restore strategy, performing backups and restores with native tools, restoring to a point in time, configuring long-term backup retention, backing up and restoring with T-SQL, and backing up to and restoring from cloud storage.
- What to understand
- Azure SQL Database and Managed Instance take automated full, differential and log backups, with point-in-time restore retention from 1 to 35 days and backup storage redundancy options of LRS, ZRS or GRS. Long-term retention keeps weekly, monthly or yearly full backups for up to 10 years. Restores always create a new database. Managed Instance supports COPY_ONLY native backups to URL. On VMs, use BACKUP DATABASE ... TO URL with a SAS credential or managed identity, automated backup through the SQL IaaS Agent extension, or Azure Backup. Restore sequences need the full, latest differential and the log chain.
- How it shows up
- Expect a request to recover from an accidental delete, meet multi-year retention, or complete a T-SQL backup to URL.
- Common confusion
- Expecting a point-in-time restore to overwrite the existing database; it creates a new one that you rename or swap.
5.3 Configure HA/DR for database solutionsActive geo-replication, availability groups, failover groups, FCIs, log shipping, monitoring and troubleshooting.
- What it means
- This group covers configuring active geo-replication, Always On availability groups on SQL Managed Instance and Azure virtual machines, failover groups, Always On failover cluster instances on Azure VMs, and log shipping, plus monitoring and troubleshooting an HA/DR solution.
- What to understand
- Active geo-replication creates up to four readable secondaries per Azure SQL database, with manual per-database failover. Failover groups manage groups of databases on Azure SQL Database or all user databases on Managed Instance, with listener endpoints and a failover policy. On VMs, availability groups need a Windows cluster, quorum witness and a listener, using a distributed network name or Azure Load Balancer unless subnets differ per replica. FCIs share storage through Azure shared disks, Premium file shares or Storage Spaces Direct. Log shipping restores log backups to a warm standby. Monitor with replica state DMVs, the AG dashboard and replication lag metrics.
- How it shows up
- Expect a feature choice by platform, a listener or quorum design, or a lagging secondary to diagnose.
- Common confusion
- Trying to configure active geo-replication on Managed Instance, which uses failover groups for cross-region DR.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
RPO and RTO
Allowed data loss and allowed downtime.
- Remember
- Drive every HA/DR choice.
- Tested as
- Design questions.
- Trap
- Mixing up which is which.
-
Zone redundancy
Replicas spread across availability zones.
- Remember
- Protects against a zone failure.
- Tested as
- Resilience questions.
- Trap
- Expecting regional protection.
-
Point-in-time restore
Restore to any moment within retention.
- Remember
- Creates a new database; 1 to 35 days.
- Tested as
- Accidental change questions.
- Trap
- Expecting in-place overwrite.
-
Long-term retention
Weekly, monthly or yearly full backups kept up to 10 years.
- Remember
- Configured per database.
- Tested as
- Compliance questions.
- Trap
- Raising PITR retention instead.
-
Geo-restore
Restore from geo-redundant backups in another region.
- Remember
- Higher RTO and RPO than replication.
- Tested as
- Low-cost DR questions.
- Trap
- Using it when minutes of RTO are required.
-
Active geo-replication
Readable secondaries for one Azure SQL database.
- Remember
- Up to four secondaries, manual failover.
- Tested as
- Azure SQL Database DR questions.
- Trap
- Choosing it on Managed Instance.
-
Failover group
Group failover with stable listener endpoints.
- Remember
- Works on Azure SQL Database and Managed Instance.
- Tested as
- Connection string stability questions.
- Trap
- Forgetting logins and jobs on MI secondaries.
-
Availability group on VMs
Replicas with a listener across VMs.
- Remember
- Needs cluster, quorum and listener design.
- Tested as
- IaaS HA questions.
- Trap
- Ignoring the listener connectivity option.
-
Failover cluster instance
Instance-level failover with shared storage.
- Remember
- Azure shared disks, Premium file shares or S2D.
- Tested as
- Instance protection questions.
- Trap
- Expecting readable secondaries.
-
Log shipping
Scheduled log backup, copy and restore to a standby.
- Remember
- Simple, manual failover.
- Tested as
- Low-complexity DR questions.
- Trap
- Expecting automatic failover.
-
Backup to URL
Native SQL Server backup into Azure Blob Storage.
- Remember
- Needs a SAS credential or managed identity.
- Tested as
- T-SQL backup questions.
- Trap
- Wrong credential name format.
-
COPY_ONLY backup
Backup that does not disturb the backup chain.
- Remember
- Required for user backups on Managed Instance.
- Tested as
- MI backup questions.
- Trap
- Omitting it on Managed Instance.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Cross-region DR options
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Active geo-replication | Per-database readable secondaries | Azure SQL Database only, manual failover | Expecting a fixed listener |
| Failover group | Grouped failover with listeners | Stable endpoints, SQL Database and MI | Assuming synchronous replication |
| Geo-restore | Restore from geo-redundant backups | Cheapest, slowest recovery | Using it for low RTO |
SQL Server on VM HA options
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Availability group | Database-level replicas | Readable secondaries, no shared storage | Forgetting instance objects like logins |
| Failover cluster instance | Instance-level failover | Shared storage, single copy of data | Expecting protection against storage loss |
| Log shipping | Restored log backups on a standby | Simple, minutes of data loss | Expecting automatic failover |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Geo-replication on MI
- What candidates pick
- Configure active geo-replication on Managed Instance.
- Why it looks right
- It is a well-known Azure SQL DR feature.
- Why it's wrong
- Managed Instance supports failover groups for cross-region DR, not active geo-replication.
Clue to watch for The platform is Managed Instance.
-
Longer PITR for compliance
- What candidates pick
- Set point-in-time retention to 7 years.
- Why it looks right
- It seems like one setting.
- Why it's wrong
- PITR retention maxes at 35 days; long-term retention keeps backups up to 10 years.
Clue to watch for Retention measured in years.
-
Geo-restore for low RTO
- What candidates pick
- Rely on geo-restore for a 5-minute RTO.
- Why it looks right
- It needs no extra replicas.
- Why it's wrong
- Geo-restore can take hours and loses recent data; replication meets tight targets.
Clue to watch for RTO in minutes.
-
FCI for storage failure
- What candidates pick
- Use a failover cluster instance to survive storage loss.
- Why it looks right
- Clustering sounds fully redundant.
- Why it's wrong
- FCIs share one copy of storage; availability groups keep separate copies.
Clue to watch for Requirement mentions storage or data copy failures.
-
Listener not needed
- What candidates pick
- Point the app at the primary server name for an AG on VMs.
- Why it looks right
- It works until failover.
- Why it's wrong
- A listener redirects connections after failover so apps follow the new primary.
Clue to watch for Requirement for automatic client redirection.
-
In-place restore
- What candidates pick
- Restore over the production database to recover deleted rows.
- Why it looks right
- It sounds faster.
- Why it's wrong
- Azure SQL restores create a new database; copy rows back or swap names.
Clue to watch for Accidental delete in Azure SQL Database.
Answer framework
Apply these steps to design, configure and test HA/DR for a DP-300 scenario.
- Write down RPO, RTO, region scope and whether failover must be automatic and transparent to applications, plus how long backups must be kept for compliance.
- Identify the platform, since Azure SQL Database, Managed Instance and VMs each support different HA/DR features.
- Select the lowest-cost feature meeting the targets: built-in HA, zone redundancy, geo-restore, geo-replication, failover groups, AGs, FCIs or log shipping, keeping budget and operational effort in view.
- Set backup retention and long-term retention to cover recovery and compliance, and confirm backup storage redundancy.
- Test with planned failovers and restores, monitor replica health and lag, and sync logins, jobs and credentials to secondaries so the application works immediately after failover.
Practice question
Want more like this? The DP-300 practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with a platform feature grid for HA/DR. Rows: built-in HA, zone redundancy, active geo-replication, failover groups, availability groups, FCIs, log shipping, point-in-time restore, long-term retention and geo-restore. Columns: Azure SQL Database, Managed Instance and SQL Server on Azure VMs. Add RPO and RTO ranges and whether failover is automatic. This grid answers most design questions on its own.
Then practice the operations. Restore an Azure SQL database to a point in time and notice the new database name. Configure a long-term retention policy and view the available backups. Create a failover group, connect through its listener and run a planned failover. On a SQL Server VM, back up to URL with a credential and restore the chain with T-SQL.
If time allows, follow a Microsoft Learn tutorial to build an availability group on Azure VMs, paying attention to the listener options and quorum witness. Finish by reviewing how logins, jobs and keys are kept consistent on secondaries.
FAQ
How much of DP-300 is Domain 5, Plan and configure a high availability and disaster recovery (HA/DR) environment?
Microsoft weights it at 20–25%, tied for the largest share, across three functional groups: planning HA/DR, backup and restore, and configuring HA/DR.
What is the difference between geo-replication and failover groups?
Active geo-replication is per database on Azure SQL Database with manual failover. Failover groups manage multiple databases, provide stable listener endpoints and also work on Managed Instance.
How long are automated backups kept?
Point-in-time restore retention is configurable from 1 to 35 days, with 7 as the default. Long-term retention keeps selected full backups for up to 10 years.
Can I restore over an existing Azure SQL database?
No. Point-in-time and geo-restores create a new database, which you can rename or use to copy data back.
Do availability groups on Azure VMs need a load balancer?
Not always. A distributed network name or a multi-subnet deployment removes the need for an Azure Load Balancer for the listener.
What backup options exist for SQL Server on Azure VMs?
Automated backup through the SQL IaaS Agent extension, Azure Backup for SQL Server, and native BACKUP TO URL commands.
Other Data & Analytics certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 5 knowledge
You have covered HA/DR planning, backup and restore, geo-replication, failover groups and VM clustering. Test whether you can match recovery targets to the right feature.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the DP-300 AI tutor Get any concept explained your way