AZ-305 Design business continuity solutions Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Azure SQL Database active geo-replication with auto-failover group

  Why this is correct

  For a critical application running on Azure SQL Database, active geo-replication with an auto-failover group provides the most suitable business continuity. The replication is asynchronous, keeping a second readable database in a different Azure region with an RPO of up to 5 seconds. The auto-failover group continuously monitors health and initiates automatic failover with a target RTO of 1 minute, minimizing downtime. This combination meets the strict RPO/RTO requirements while also allowing the secondary to serve read-only queries.

• ✗

  Azure SQL Database geo-restore

  Why it's wrong here

  Geo-restore uses a geo-redundant backup of the database to recover in a paired region, but these backups are typically available with an RPO measured in hours and an RTO that can also span hours while the backup is restored. It is a manual disaster-recovery fallback, not a continuous replication mechanism, so it cannot meet the low data-loss tolerance of the scenario. Relying on geo-restore would mean accepting significant data loss and prolonged downtime.

• ✗

  Azure SQL Database copy

  Why it's wrong here

  The database copy operation simply creates a one-time, point-in-time copy of the source database, either on the same or a different server. After the copy is created, no further changes are propagated, so the copy quickly becomes stale and there is no automatic failover capability. This option is suitable for testing, development, or migration scenarios, but it does not provide the ongoing replication or automated recovery demanded by a critical production application.

• ✗

  Azure SQL Managed Instance failover group

  Why it's wrong here

  This option points to Azure SQL Managed Instance, not the Azure SQL Database service in the scenario; failover groups are a valid feature for Managed Instance, but the solution must target Azure SQL Database. Although SQL Database has its own failover-group capability, you cannot use a Managed Instance failover group to protect a single database in the SQL Database service. The platform mismatch makes this choice incorrect regardless of the RPO/RTO properties it would provide.