DP-300 Practice Question: Plan and configure a high availability and disaster recovery environment
Your Azure SQL Database is configured with a failover group between two regions. The primary database experiences a catastrophic failure that prevents any connectivity. You need to initiate a failover to the secondary region. However, the failover group status shows 'Primary is down'. What should you do?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Run a forced failover accepting potential data loss.
A forced failover (also called an unplanned failover) is used when the primary database is completely unavailable, and you accept potential data loss. Option A is incorrect because a planned failover requires both the primary and secondary to be online to ensure zero data loss. Option B is incorrect because waiting for the primary to come back online is not an appropriate action when immediate failover is required due to catastrophic failure. Option C is incorrect because you cannot remove the primary database from a failover group when it is down; the failover group must be failed over as a whole.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Run a planned failover to ensure zero data loss.
Why it's wrong here
A planned failover requires both servers reachable so the primary can be demoted and all transactions synchronised, guaranteeing zero data loss. With the primary down, that handshake cannot occur, so the operation fails; forced failover is the mechanism designed for this unplanned scenario, accepting possible data loss.
- ✗
Wait for the primary to come back online and then failover.
Why it's wrong here
Waiting leaves the application offline indefinitely, defeating the purpose of a geo-redundant failover group. The 'Primary is down' status exists precisely so administrators can proceed with a forced failover without waiting; delaying is only sensible when the outage is expected to be brief and data loss must be avoided.
- ✗
Remove the primary database from the failover group and then failover.
Why it's wrong here
Removing the primary from the failover group does not trigger a geo-failover and risks orphaning the secondary's replication link; the group already permits forced failover when the primary is unreachable. Removal is intended for permanently decommissioning a partner, not for recovering service during an outage.
- ✓
Run a forced failover accepting potential data loss.
Why this is correct
A forced failover promotes the secondary to primary despite the failover group reporting 'Primary is down', which blocks a normal planned failover. Because the primary is unreachable, asynchronous replication means some committed transactions may not have reached the secondary, so accepting potential data loss is unavoidable to restore write availability.
Go deeper
Related to this question
Learn chapter
Overview of Azure Data Platform Options
Key term
Azure SQL Performance Tuning
Azure SQL Performance Tuning is the process of optimizing the speed and efficiency of queries and database operations in Microsoft Azure SQL Database or SQL Managed Instance to reduce latency and improve throughput.
About these practice questions
Courseiva writes every DP-300 question from scratch — 574 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DP-300 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DP-300 exam.