Azure Database for MySQL Flexible Server Business Continuity

AZ-305 By islever Editorial Last updated

Short answer

C Implement Geo-redundant backup to enable recovery from a paired region during a regional outage.

Question

You plan to deploy an Azure Database for MySQL flexible server named Server1 to the East US Azure region.
You need to implement a business continuity solution for Server1. The solution must minimize downtime in the event of a failover to a paired region.
What should you do?
  1. Create a read replica.
  2. Store the database files in Azure premium file shares.
  3. Implement Geo-redundant backup. Correct Answer
  4. Configure native MySQL replication.

Key Takeaways

Geo-redundant backup is the designated DR solution for regional failures; read replicas are for scaling and require manual intervention, lacking automated failover capabilities.

Learn how to implement business continuity for Azure Database for MySQL flexible servers using Geo-redundant backups to minimize downtime during regional failovers.

Common mistake: Choosing A (Create a read replica). Candidates often assume cross-region replicas provide automatic failover like SQL Managed Instance, but MySQL Flexible Server read replicas are for read scaling and do not offer automated disaster recovery.

Expert Analysis

The question asks for a business continuity solution that minimizes downtime during a failover to a paired region. The key constraint is 'minimize downtime'.

Option A (Create a read replica) creates a cross-region replica. However, Azure Database for MySQL flexible servers do not support automated failover to read replicas. Failover requires manual promotion. Furthermore, the comments highlight that read replicas are primarily for scaling read workloads, not disaster recovery with minimal downtime. While faster than restoring from backup, the lack of automation and potential data lag makes it less ideal for 'business continuity' in the strictest sense of automated RTO/RPO guarantees provided by backups in this specific context.

Option C (Implement Geo-redundant backup) ensures backups are stored in a paired region. In the event of a regional failure, you can restore the database from these geo-redundant backups. This is the officially supported method for disaster recovery when the primary region is unavailable. Although restoration takes time, it is the only option listed that provides a robust, geo-redundant mechanism for recovering service in a paired region without relying on potentially lagging or manually managed replicas. The comments strongly favor C because GRB is designed specifically for regional outages, whereas read replicas are not a substitute for backups in this architecture.

Options B and D are incorrect: Premium file shares do not store database files directly, and native MySQL replication is not an Azure-managed business continuity feature for flexible servers.

Therefore, implementing Geo-redundant backup is the correct approach to ensure availability in a paired region.

Official Reference

https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-business-continuity

This link opens the official vendor documentation in a new tab.

Exam Strategy

Distinguish between High Availability (HA) and Disaster Recovery (DR). HA features (like zone redundancy) handle local failures instantly. DR features (like Geo-redundant backup) handle regional outages. For Azure PaaS services, always check if the service supports automated failover to a secondary region. If not, the backup strategy becomes the primary DR mechanism.

Frequently Asked Questions

Why isn't a read replica used for automated failover?

Read replicas in Azure Database for MySQL Flexible Server are asynchronous and intended for offloading read traffic. They do not support automated failover; promoting a replica is a manual process.

How does Geo-redundant backup help with downtime?

It stores backups in a paired region. If the primary region fails, you can restore the database in the paired region, ensuring data availability even if the source region is completely inaccessible.

More AZ-305 FAQ →

Community Votes

A
50%
C
47%
D
3%

50% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 47 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 30 of 47

  1. Dumber 👍 32
    It tend to differ.. Answer A seems to be possible as well. It is faster then a restore. https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-read-replicas#cross-region-replication-in-geo-paired-region You can create a read replica in a different region from your source server. Cross-region replication can be helpful for scenarios like disaster recovery planning or bringing data closer to your users. Azure database for MySQL Flexible Server allows you to provision read-replica in the Azure supported [geo-paired region]
  2. NotMeAnyWay 👍 20 Answered C
    C. Implement Geo-redundant backup. The Geo-redundant backup (GRB) feature in Azure Database for MySQL allows automatic backups to be stored in a different geographic region (geography). In the event of a region-wide service disruption, you can restore the database from the geo-redundant backup, which helps minimize downtime. Other options do not provide business continuity in case of regional failures. Option A, creating a read replica, primarily helps with read-heavy workloads and not for disaster recovery. Option B, storing the database files in Azure premium file shares, might improve performance but does not specifically provide a disaster recovery solution. Option D, configuring native MySQL replication, isn't supported directly within Azure Database for MySQL. Instead, you would use Azure's built-in business continuity features, such as Geo-redundant backup.
  3. nchebbi 👍 9 Answered C
    The answer should be C: Geo-redundant backup: Read replica are not meant for business continuity, failing over is manual which doesn't meet the requirement of minimizing downtime. "There's no automated failover between source and replica servers. Read replicas is meant for scaling of read intensive workloads and isn't designed to meet high availability needs of a server. Stopping the replication on read replica to bring it online in read write mode is the means by which this manual failover is performed." https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-read-replicas#failover
  4. hidefo6963 👍 9
    Looks like this is the answer (A), not C. Create a read replica, then manually failover it in the case of disaster. The answer C is a Backup, restoring it will take much longer
  5. wooyourdaddy 👍 6
    This answer seems to be supported by this link as well: https://learn.microsoft.com/en-us/azure/mysql/single-server/concepts-read-replicas#paired-regions which states: If you're using cross-region replicas for disaster recovery planning, we recommend you create the replica in the paired region instead of one of the other regions. Paired regions avoid simultaneous updates and prioritize physical isolation and data residency.
Show 25 more comments
  1. xitzee 👍 4
    Except you are wrong. It may help with ready-heavy workload but at th esame time it is replica to which you are able to failover. Which definetely minimazes downtime in case of outage. Read replicas ARE disaster recovery solutions
  2. peacegrace 👍 3 Answered A
    The correct answer is A. Create a read replica. Why? For Azure Database for MySQL – Flexible Server, the recommended and supported high-availability / disaster recovery solution that minimizes downtime during a regional failover is to create a cross-region read replica in a paired region (for example, East US → West US, East US 2 → Central US, etc.). Key points that make read replica the best choice here: When you create a cross-region read replica in Flexible Server, Azure sets up asynchronous replication to the paired region. In the event of a regional outage or when you trigger a planned failover, you can promote the read replica to become the new primary with just a few clicks or via CLI/API. Failover typically completes in minutes (often under 5–10 minutes), which is the fastest and lowest-downtime DR option available for MySQL Flexible Server. It is specifically designed and fully managed by Azure for this disaster recovery scenario.
  3. Lazylinux 👍 3 Answered C
    I have to agree with C as per below While it's a rare event, if you want to recover from a region-level failure, you can perform database recovery by creating a new server using the latest geo-redundant backup available under the same subscription to get to the latest data. A new flexible server is deployed to the selected region. The time taken to restore depends on the previous backup and the number of transaction logs to recover. RPO in most cases would be <1 h and RTO would vary. https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-business-continuity
  4. ElectricPants 👍 3 Answered A
    Read replicas in Azure Database for MySQL allow for near real-time replication to another region, which can be promoted to a standalone server if there’s a primary region failure. This minimizes downtime by providing a standby server in a paired region. Geo-redundant backup (Option C) provides data protection but does not enable quick failover with minimal downtime.
  5. chillzz 👍 3 Answered C
    High availability seems only avaliable in the same zone https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-high-availability To failover to another region, you would use a geo-redunant backup https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-business-continuity
  6. yonie 👍 3 Answered C
    The service backups can be configured as geo-redundant at create time. https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-business-continuity
  7. uncledana 👍 3 Answered A
    both A and C are correct but A is the better option and time efficient.
  8. josola 👍 2
    Several discussions indicate that "read replicas" are a failover solution. Yes, they are IF you don't mind some data loss or delay in spinning your new database. In other words, it's not a business continuity solution as the question requires. Then as the paragraphs below indicate "A" isn't the right answer. "There's no automated failover between source and replica servers. Read replicas is meant for scaling of read intensive workloads and ISN'T DESIGNED TO MEET HIGH AVAILABILITY NEEDS OF A SERVER. Stopping the replication on read replica to bring it online in read write mode is the means by which this manual failover is performed." "If you failover to the replica, the lag at the time you delink the replica from the source indicates how much data is lost." Then answer is C. https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-read-replicas#failover
  9. grf0 👍 2 Answered A
    Per docs: With Geo-restore feature, a new server is created using the backup data that is replicated from another region. The overall time it takes to restore and recover depends on the size of the database and the amount of logs to recover. The overall time to establish the server varies from few minutes to few hours. With read replicas, transaction logs from the primary are asynchronously streamed to the replica. In the event of a primary database outage due to a zone-level or a region-level fault, failing over to the replica provides a shorter RTO and reduced data loss. https://learn.microsoft.com/en-us/azure/mysql/single-server/concepts-business-continuity
  10. SDiwan 👍 2 Answered C
    "While it's a rare event, if you want to recover from a region-level failure, you can perform database recovery by creating a new server using the latest geo-redundant backup available under the same subscription to get to the latest data. A new flexible server is deployed to the selected region. The time taken to restore depends on the previous backup and the number of transaction logs to recover. RPO in most cases would be <1 h and RTO would vary." Source: https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-business-continuity
  11. rgnanav 👍 2 Answered C
    https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-business-continuity While it's a rare event, if you want to recover from a region-level failure, you can perform database recovery by creating a new server using the latest geo-redundant backup available under the same subscription to get to the latest data. A new flexible server is deployed to the selected region. The time taken to restore depends on the previous backup and the number of transaction logs to recover. RPO in most cases would be <1 h and RTO would vary.
  12. rishiraval007 👍 2 Answered A
    A. Create a read replica Explanation For Azure Database for MySQL Flexible Server, creating a read replica in the paired region is the correct business continuity solution that minimizes downtime in the event of a failover to a paired region. A read replica in the paired region maintains a continuously synchronized copy of Server1's data in the target region. In the event of a regional outage, the read replica can be promoted to a standalone server quickly, minimizing downtime and data loss during the failover process.
  13. AdventureChick 👍 2 Answered A
    Read replica based on this page for MySQL business continuity: https://learn.microsoft.com/en-us/azure/mysql/single-server/concepts-business-continuity Geo-restore - creates a new server using backup data replicated from another region. The overall restore time depends on the DB size & logs. Restore is: a few minutes to a few hours. Read replicas - T-logs from the primary are asynchronously streamed to the replica. For a Zone or Region failure, failing over to the replica = a shorter RTO and reduced data loss
  14. cloudexpert12221222 👍 2 Answered A
    As specified in the docs https://learn.microsoft.com/en-us/azure/mysql/single-server/concepts-backup, "performing restore (from a backup) creates a new server from the original server's backups and restores all databases in the server. Restore is currently NOT supported if the original server is in stoped state." I guess that then you should create a read replica and, if there is a failure in the origin zone, stop the replication and change the conn string from the apps to point to the new server.
  15. ahhatem 👍 2 Answered A
    While C would work, doing a full restore from backup would obviously take much longer than simply promoting the geo-replica to master. from the documentation: https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-read-replicas#cross-region-replication "You can create a read replica in a different region from your source server. Cross-region replication can be helpful for scenarios like disaster recovery planning or bringing data closer to your users."
  16. maxustermann 👍 2 Answered A
    Read only replica is supported on flexible server: https://learn.microsoft.com/en-us/azure/mysql/flexible-server/how-to-read-replicas-portal?source=recommendations Also: Azure Database for MySQL - Single Server is on the retirement path. We strongly recommend for you to upgrade to Azure Database for MySQL - Flexible Server. https://learn.microsoft.com/en-us/azure/mysql/single-server/concepts-read-replicas
  17. marcellov 👍 2 Answered A
    As we are talking about business continuity and failover, a read replica seems more appropriate. "You can create a read replica in a different region from your source server. Cross-region replication can be helpful for scenarios like disaster recovery planning or bringing data closer to your users." https://learn.microsoft.com/en-us/azure/mysql/single-server/concepts-read-replicas#cross-region-replication
  18. OrangeSG 👍 2 Answered C
    Answer A is wrong because read replica is only applicable to "Azure Database for MySQL - Single Server", while the question said "You plan to deploy an Azure Database for MySQL flexible server" Refer to Microsoft document: Read replicas in Azure Database for MySQL https://learn.microsoft.com/en-us/azure/mysql/single-server/concepts-read-replicas
  19. arnitjoe 👍 2 Answered C
    A read replica would offer read only access to the database during a failover. That is still an outage if the database requires writes. Since the question doesn't specify that the DB is read only, A would be wrong and an incomplete solution. Same with B and D. Only C is a complete solution.
  20. hwoccurrence 👍 2
    Although promotion of a replica is manual, the question only asks to minimize downtime; it doesn’t require automatic fail-over. A geo-restore meets the SLA for data protection, but it can’t beat the near-instant cut-over you get by keeping a warm replica ready to promote.
  21. C_M_M 👍 2 Answered C
    Correct Azure MySql server -flexible only has zonal redundancy by default. YOu must enable geo-redundancy by yourself if you plan to use it for pair-region disaster recovery https://learn.microsoft.com/en-us/azure/mysql/flexible-server/how-to-move-regions
  22. Msaad7 👍 2 Answered D
    D. Configure native MySQL replication
  23. josola 👍 2
    No, read well.
  24. gpais 👍 1 Answered A
    Architectural Breakdown: • Minimizing Downtime (RTO): A cross-region read replica deployed in the geo-paired region keeps a continuously running compute instance that asynchronously synchronizes database transactions. In the event of a primary regional outage, failing over involves promoting the read replica to a standalone primary server. This process is very fast (typically taking only a few minutes), thereby minimizing application downtime. • Why Geo-redundant Backup (Option C) is less ideal: While geo-redundant backups are excellent for general disaster recovery, recovering from them requires a Geo-restore operation. Geo-restore must provision an entirely new database server and copy all data from the backup files over the network, which leads to a significantly higher and unpredictable Recovery Time Objective (RTO)—potentially taking hours depending on the size of the database. • Options B and D are incorrect: Storing files on premium file shares is not a supported pattern for Flexible Server business continuity across regions, and native replication is manual and unmanaged compared to Azure's native read-replica feature.
  25. peacegrace 👍 1 Answered A
    MySQL flexible server Why? For Azure Database for MySQL – Flexible Server, the recommended and supported high-availability / disaster recovery solution that minimizes downtime during a regional failover is to create a cross-region read replica in a paired region (for example, East US → West US, East US 2 → Central US, etc.). Key points that make read replica the best choice here: When you create a cross-region read replica in Flexible Server, Azure sets up asynchronous replication to the paired region. In the event of a regional outage or when you trigger a planned failover, you can promote the read replica to become the new primary with just a few clicks or via CLI/API. Failover typically completes in minutes (often under 5–10 minutes), which is the fastest and lowest-downtime DR option available for MySQL Flexible Server. It is specifically designed and fully managed by Azure for this disaster recovery scenario.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Practice All AZ-305 Questions

Access 95 questions with complete answers and detailed explanations.

View Full AZ-305 Practice Test →

← Back to AZ-305 Study Guide