What happens to your business when the database powering your online store suddenly crashes at 2 PM on Cyber Monday? If you cannot answer that question with a confident 'nothing, because we have high availability', you need to understand HA. For the DP-300 exam, Microsoft wants to know you can design, configure, and verify the correct HA solution for Azure SQL so that your database survives failures without the business noticing.
Jump to a section
A simple way to picture Implementing High Availability for Azure SQL Databases
Your freezer is your primary database, holding fresh burgers, pizza, and ice cream. One day, the power goes out and stays out for hours. If you have only that one freezer, all your food spoils and you are ordering takeout because you have no backup meal plan. That is a single point of failure. Now, imagine you have a second freezer in a different part of your house, plugged into a separate power circuit. When the main freezer fails, you can immediately flip a switch and start using the backup freezer. The food is still frozen and safe. You bought yourself time to fix the first freezer without ever being hungry. In Azure SQL, that second freezer is a secondary replica. When your primary database goes down (main freezer loses power), Azure automatically flips the switch and traffic starts hitting the secondary replica (backup freezer). Your application keeps running, your customers keep buying, and nobody notices anything happened. The key is that the secondary replica is a live, synchronised copy that is ready to take over at a moment's notice. Without it, a database outage means downtime, angry users, lost sales, and a frantic engineer. With it, you get a seamless failover that feels like magic but is actually just a well-designed high availability (HA) configuration.
High availability means your database keeps working even when something breaks. It is not about preventing failures but about surviving them so fast that users never see an error page. In Azure SQL, the main mechanism for this is the concept of replicas.
A replica is a copy of your database that runs on a different physical server, often in a different physical building within the same Azure region (a specific geographic location like 'West Europe' or 'East US'). Azure SQL Database uses a technology called Always On Availability Groups under the hood. It automatically creates one or more secondary replicas. When you write data to the primary replica, that data is synchronously copied to the secondary replica before the write is confirmed as complete. 'Synchronous' means your application waits for the confirmation that both copies have the data before moving on. This guarantees zero data loss if the primary fails.
Why not just use backups instead of replicas? A backup is like a photo of your database from an hour ago. If you restore it, you lose all transactions that happened after that photo was taken. More importantly, restoring a backup takes minutes or hours. A replica is a live mirror. It can take over in seconds. For a business like an airline booking system, where every second of downtime costs thousands of pounds, that difference matters enormously.
Azure SQL offers several service tiers that determine what level of HA you get:
The Basic tier has one replica. No HA. If the server fails, your database is down until Azure fixes it.
The Standard tier has one secondary replica within the same datacenter. If the primary fails, the secondary takes over, but there is a small risk of data loss (the secondary might be a few milliseconds behind).
The Premium and Business Critical tiers have three secondary replicas. Two of them are used for automatic failover, and one can be used for read-only queries (like reporting) without slowing down the primary. These tiers also use premium hardware like SSDs (solid state drives, which are much faster than traditional hard drives) and memory-optimised cores.
The automatic process of switching from primary to secondary is called failover. Azure monitors the health of your primary replica every few seconds. If it detects a problem (like the database process crashing, the server losing power, or the network cable being cut), it triggers a failover. The DNS record (a phonebook that tells your application where to find the database) is updated to point to the secondary replica. Your application needs only to retry the connection once, and it will automatically be routed to the new primary. This is called automatic retry logic and is built into most modern database connection libraries.
For even higher availability, you can use zone-redundant configuration. An Azure region is made up of multiple physical datacentres, called availability zones. A zone is a separate building with its own power, cooling, and network. In the zone-redundant setup, each of your replicas lives in a different zone. A fire in one building will not affect the others. This protects against larger disasters that might take out an entire datacentre, like a power grid failure or a flood.
What about regions? If you need to survive an entire Azure region going offline (rare but possible, for example, a major earthquake), you need geo-replication. This uses asynchronous replication (the copy happens a few seconds after the write) to a secondary replica in a different Azure region hundreds of kilometres away. Geo-replication does not provide automatic failover by default. You have to manually decide when to fail over to the other region, because failing over to a distant region is a big decision with network latency impact. However, you can combine geo-replication with a feature called Auto-Failover Groups, which automates the regional failover but adds extra configuration options like a grace period (how long to wait before declaring the primary region dead) and a readable secondary endpoint.
In summary, high availability is not a single feature. It is a stack of features: synchronous replicas within a datacentre, zone-redundant replicas across buildings, and geo-replicas across regions. The DP-300 exam expects you to know which tier provides which level of protection, and what trade-offs exist between cost, complexity, and data safety.
Select a service tier with HA support
Choose at least the Standard tier (for a single secondary replica) or Premium/Business Critical (for multiple replicas, zone-redundancy, and readable secondaries). The Basic tier has no HA and is not exam-relevant for this objective.
Enable zone-redundancy (optional, within a region)
During database creation or via an update, toggle the zone-redundant setting. This places your replicas into different availability zones (physical buildings). This step costs extra but protects against a building-level disaster.
Configure geo-replication (for cross-region DR)
In the Azure portal, go to your database and select 'Geo-Replication'. Choose a target region and create a secondary replica there. This replica is asynchronously updated. At this point, failover is still manual.
Create an Auto-Failover Group (for automatic cross-region failover)
Under your SQL Server resource, create a failover group. Add the database you want, choose the primary and secondary server, and set a grace period (e.g., 1 hour). This group provides a single connection endpoint and automatic failover after the grace period expires.
Test your failover configuration (disaster recovery drill)
Initiate a manual failover (using the portal, PowerShell, or CLI) during a maintenance window. Verify that the application connects to the new primary. Measure the RTO (time to recover) and adjust the grace period accordingly. Document the results.
Implement application retry logic
Ensure your application's connection code retries failed attempts at least 3 times with exponential backoff (waiting longer between each retry). Many libraries (like ADO.NET or Entity Framework) have built-in retry policies. Without this, HA is useless because the app will throw an error even after failover completes.
Sarah is the sole DBA (database administrator) for a mid-sized e-commerce company selling artisan coffee subscriptions. She has one Azure SQL Database in the Premium tier, deployed in the West Europe region. The database handles customer orders, payments, and inventory. One Tuesday morning, she gets an alert: the primary replica has failed due to a memory corruption issue on the host server.
Step by step, here is what happens and what Sarah does:
At 10:03 AM, Azure detects the primary is unhealthy. It automatically initiates a failover. The secondary replica, which has been synchronously receiving all transactions, becomes the new primary. The DNS records update, and the application retries its connections. By 10:04 AM, the website is fully operational again. Sarah receives an alert email but by the time she reads it, the problem is already resolved. 60 seconds of downtime, no data loss.
Sarah logs into the Azure portal and navigates to the SQL Server resource. She checks the 'Failover groups' blade. There she sees that the failover completed successfully and the new primary replica is healthy. She also sees the old primary is now a secondary replica and is in the process of being repaired by Azure.
She then checks the telemetry. The application had 23 failed connection attempts during the 60-second window. Modern applications have retry logic that handles this automatically, but her team's custom mobile app did not. She opens a ticket with the mobile app developers to add retry logic.
Later that week, Sarah decides to improve her HA setup. She currently only has zone-redundancy (replicas in different buildings within West Europe). She realises that if a natural disaster hits the entire West Europe region, her business would be down for hours. She sets up geo-replication to a secondary region, North Europe. This creates an asynchronous copy of her database in a different country.
She also configures an Auto-Failover Group. This lets her define a grace period of 1 hour. If the primary region goes completely offline for over an hour, Azure will automatically fail over to the North Europe replica. She also makes the geo-secondary readable, so her reporting team can run their big monthly queries on the remote replica without slowing down the live site.
Finally, she runs a disaster recovery drill. She manually triggers a failover to North Europe during a quiet maintenance window. The team tests that the application works from the remote region. She finds that latency increased by 50ms, which is acceptable. She then fails back to West Europe. She documents the entire procedure in her runbook.
Sarah's real-world actions went beyond just configuring a checkbox. She tested, measured, documented, and trained her team. This is the difference between theory and practice. The DP-300 exam will ask you about the configuration options Sarah used: what tier supports geo-replication, what is the difference between zone-redundant and geo-redundant, and what the failover group grace period does.
The DP-300 exam tests 'Implement high availability for Azure SQL' in several distinct ways. You will encounter multiple-choice and multiple-select questions that require you to know specific configuration details. The exam does not ask you to perform actual setups (you are not clicking buttons in the portal), but it does ask you to predict the outcome of configurations.
Here are the exact concepts the exam loves to test:
Service tier capabilities: You must memorise which tier supports which HA option. For example, only Premium and Business Critical tiers support zone-redundant configuration. The Standard tier does not. The Basic tier has no built-in HA. A typical question: 'You need to ensure zero data loss during a failover and minimal latency. Which service tier should you choose?' Answer: Business Critical (because it uses synchronous replication with SSDs).
Failover group vs geo-replication: Traps appear here. Geo-replication gives you a readable secondary but requires manual failover. Auto-Failover Groups give you automatic failover and a namespaced listener endpoint (a single connection string that always points to the current primary). A question might ask: 'You need to fail over to a secondary region automatically if the primary region becomes unavailable. Which feature should you use?' The answer is Auto-Failover Groups, not standalone geo-replication.
Readable secondaries: In Business Critical and Premium tiers, you can offload read-only queries to a secondary replica. This is tested with scenario-based questions. Example: 'Your reporting team queries the database constantly, slowing down transactions. What should you do?' Answer: Enable read scale-out on a secondary replica.
Data loss scenarios: Synchronous replication guarantees zero data loss (RPO = 0). Asynchronous replication (geo-replication) can lose a few seconds of data. The exam will ask you to choose between the two based on a business requirement. If the requirement says 'financial transactions that must not lose a single record', you pick synchronous.
Recovery Time Objective (RTO) and Recovery Point Objective (RPO): You need to know these acronyms. RTO is how long it takes to get back online (time). RPO is how much data you might lose (freshness). The exam gives you a scenario: 'The business can tolerate 5 seconds of downtime but cannot lose any data.' High RTO? Low RPO? You need to match that to the correct tier.
Common traps: The exam loves to offer a trap answer that says 'Always On Availability Groups configured on a virtual machine (IaaS)'. That is a valid HA solution, but the question might specify 'Azure SQL Database (PaaS)', which means you cannot configure the VM-level feature. The exact wording matters. Also, they might try to trick you into thinking that Azure SQL Managed Instance has different HA features than Azure SQL Database. It does not—both use the same underlying platform, but Managed Instance offers auto-failover groups with some extra limitations.
Key definitions to memorise:
Primary replica: The database you write to.
Secondary replica: The copy that can take over.
Failover: The process of switching roles from primary to secondary.
Zone-redundant: Replicas in different physical buildings (availability zones) within one region.
Geo-redundant: Primary in one region, secondary in a different region.
Grace period: The time Azure waits before initiating an automatic geo-failover.
The exam typically includes 2-3 questions on this objective. They are scenario-based, so read the business requirement carefully and map it to the correct feature. Do not overthink. If the scenario mentions 'automatic failover across regions', the answer is Auto-Failover Groups. If it says 'read-only query offloading', the answer is read scale-out on a secondary replica.
High availability in Azure SQL relies on replicas — synchronised copies of your database on separate physical servers that can take over during a failure.
Synchronous replication guarantees zero data loss (RPO = 0) but slightly increases write latency because the primary waits for the secondary to confirm.
Zone-redundant configuration protects against a single datacentre outage, while geo-replication protects against an entire region outage.
Auto-Failover Groups provide automatic regional failover with a configurable grace period, whereas standalone geo-replication requires manual intervention.
Only Premium and Business Critical service tiers support zone-redundant configuration and multiple readable secondary replicas.
The most common exam trap is confusing manual geo-replication with automatic failover groups — memorise the difference.
Read scale-out lets you offload reporting queries to a secondary replica, improving performance on the primary.
Failover causes a brief (30–60 second) disruption, so your application must implement retry logic to handle transient connection errors.
The Basic tier has no built-in HA — you should never use it for production databases that need to stay online.
Always check whether the question refers to 'Azure SQL Database (PaaS)' or 'SQL Server on Azure VMs (IaaS)' — the HA options are different.
These come up on the exam all the time. Here's how to tell them apart.
Zone-Redundant HA (within a region)
Replicas in different physical buildings (availability zones) in one Azure region.
Uses synchronous replication — zero data loss.
Protects against a single datacentre failure (e.g., fire in one building).
Geo-Redundant HA (across regions)
Secondary replica in a different Azure region (e.g., West Europe to East US).
Uses asynchronous replication — possible data loss of a few seconds.
Protects against a region-wide disaster (e.g., earthquake affecting the entire primary region).
Azure SQL Database Business Critical (PaaS HA)
Fully managed by Azure — no OS patching, hardware management, or manual configuration.
Maximum of 4 replicas; synchronous replication within the region.
Automatic failover with no manual scripting required.
SQL Server on Azure VMs with Always On (IaaS HA)
You manage the VMs, apply updates, and configure the Availability Group yourself.
You can have up to 9 replicas (including synchronous and asynchronous).
Failover can be automatic or manual, but you need to set up a Windows Server Failover Cluster and a listener.
Standard Tier (with a single secondary replica)
One secondary replica within the same datacentre (not zone-redundant).
Replication is still synchronous, so zero data loss in a failover.
No support for readable secondaries or read scale-out.
Premium Tier (with multiple secondary replicas and zone-redundancy)
Up to 4 secondary replicas, which can be zone-redundant.
Synchronous replication with higher performance hardware (SSDs, faster CPUs).
Supports read scale-out — offload reporting queries to secondaries without slowing the primary.
Manual Geo-Failover
You must initiate the failover via portal, PowerShell, or CLI when a disaster is declared.
No grace period — failover happens immediately when you trigger it.
You manage the connection string manually — no single endpoint for the application.
Auto-Failover Group (automatic geo-failover)
Azure automatically initiates failover after a configurable grace period (e.g., 1 hour) if the primary region becomes unavailable.
You set a grace period to avoid failing over during a brief network glitch.
Provides a single listener endpoint so the application always connects to the correct primary without changing connection strings.
Mistake
High availability means my database will never go down at all.
Correct
High availability means the database stays available despite a failure, but there is still a very brief period of downtime during the failover (typically 30–60 seconds). Zero downtime is impossible with current technology — the goal is near-zero downtime.
The word 'high availability' sounds like it should mean 'always on'. Beginners assume it is 100% uptime, but it is actually measured in nines (e.g., 99.99%). The exam tests that you understand the difference.
Mistake
I can set up geo-replication and it will automatically fail over to the secondary region if the primary fails.
Correct
Geo-replication alone requires manual failover. To get automatic failover across regions, you must also configure an Auto-Failover Group. The exam explicitly tests this distinction.
The names are similar. Many learners see 'geo-replication' and think it includes automatic failover, because it seems logical. Microsoft chose a different name for the automatic feature.
Mistake
If I use zone-redundant configuration, my database is protected against an entire region going offline.
Correct
Zone-redundant configuration protects against a single datacentre failure within a region, but not against a region-wide disaster (e.g., a major hurricane taking out the whole region). For region-level protection, you need geo-replication across regions.
The word 'zone' implies a wide area, but in Azure a zone is just one building. Beginners confuse 'zone' with 'region' because everyday language uses 'zone' to mean a large area.
Mistake
You can have unlimited secondary replicas in Azure SQL Database.
Correct
The maximum number of secondary replicas depends on the service tier. Basic has 0, Standard has 1, and Business Critical has up to 4 (but one is used for failover). There is a hard limit.
Beginners see that you can add replicas in Azure and assume there is no cap. The exam wants you to know the specific numbers, which vary by tier.
Mistake
Failover is instantaneous and there is zero impact on the application.
Correct
Failover takes time: detecting the failure (a few seconds), updating DNS (DNS propagation can take up to 30 seconds in some cases), and the application needs to retry connections. Brief connection errors are normal. Applications must have retry logic.
The 'magic' of HA is impressive, but it is not magic. Beginners expect perfection. The exam tests that you understand the practical limits.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Zone-redundant places multiple replicas in different physical buildings (availability zones) within the same Azure region. Geo-redundant places a secondary replica in a different Azure region (e.g., from West Europe to North Europe). Geo-redundant protects against region-wide disasters but has higher latency and uses asynchronous replication.
No, the Basic tier has no built-in HA. It uses a single replica. If the server or database fails, it will be unavailable until Azure restores it. For HA, you must use Standard, Premium, or Business Critical tiers.
If you are using zone-redundancy or standard HA within a region (Premium/Business Critical), it uses synchronous replication automatically. If you configure geo-replication to a different region, it uses asynchronous replication. You do not choose — it is determined by the distance between replicas.
Yes, but only in the Premium and Business Critical tiers. You must enable 'Read scale-out' in the connection string by adding 'ApplicationIntent=ReadOnly'. The secondary replica can then handle read-only queries like reports without affecting the primary's performance.
During a geo-failover, the asynchronous secondary replica becomes the new primary. Because replication was asynchronous, you could lose a few seconds of transactions (the data that was written to the old primary but not yet copied). This is why geo-replication has an RPO of up to 5 seconds.
Yes, your application must have retry logic to reconnect after a failover. The failover takes a few seconds and DNS updates take time. Without retry logic, the app will throw a connection error and stop working even though the database is now online.
You've finished Implementing High Availability for Azure SQL Databases. Continue through the DP-300 study guide to build a complete picture of the exam.
Done with this chapter?