Exam AZ-305 topic 3 question 20 discussion

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]

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.

Keywords are "must minimize downtime"

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."

I go with the option C

If you see "paired region", the answer will probably involve geo-redundancy.

"C" is correct. It is all here in "Geo-redundant backup" "The service backups can be configured as geo-redundant at create time. Enabling Geo-redundancy replicates the server backup data files in the primary region’s paired region to provide regional resiliency. Geo-redundant backup storage provides at least 99.99999999999999% (16 nines) durability of objects over a given year." https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-business-continuity

C is correct

Option B not A. Why not A? read below :- https://learn.microsoft.com/en-us/previous-versions/azure/mysql/single-server/concepts-read-replicas#when-to-use-a-read-replica

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.

As per Microsoft : The standalone server can't be made into a replica again. Before you stop replication on a read replica, ensure the replica has all the data that you require.`` then having a read replica for a disaster recovery with the intention to make it again a read replica after original server recovery will not be an optimal option. thus i would go for Option C. https://learn.microsoft.com/en-us/previous-versions/azure/mysql/single-server/concepts-read-replicas

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

C Enabling Geo-redundancy replicates the server backup data files in the primary region’s paired region to provide regional resiliency. https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-business-continuity

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.

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

"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

D. Configure native MySQL replication