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.

• ✗

  Use Azure Traffic Manager with priority routing to a second App Service instance, use Azure SQL Database backup to a secondary region, and use Azure Storage zone-redundant storage (ZRS).

  Why it's wrong here

  Traffic Manager with priority routing to a second App Service instance handles DNS-level failover, but it does nothing for the state stored in Azure SQL Database or Blob Storage. Azure SQL Database backup to a secondary region is not a built-in capability—backups are always stored in the same region unless you explicitly use geo-restore, which has a recovery point objective (RPO) of up to 1 hour and requires manual initiation. Similarly, zone-redundant storage (ZRS) replicates synchronously across availability zones within the primary region, not across regions, so it provides no protection against a full regional outage. This solution lacks automatic database failover and regional storage redundancy, making it unsuitable for disaster recovery.

• ✗

  Configure App Service auto-scaling, use Azure SQL Database geo-replication with readable secondary, and use Azure Storage read-access geo-redundant storage (RA-GRS).

  Why it's wrong here

  Auto-scaling in App Service handles increased load by adding instances, but it cannot recover from a regional outage because all instances reside in the same region. Azure SQL Database geo-replication with a readable secondary provides async replication and supports manual failover, but it does not offer automatic failover—you must manually promote the secondary, and the RTO depends on your detection and orchestration, often exceeding a few minutes. Read-access geo-redundant storage (RA-GRS) replicates to a secondary region asynchronously and allows read access there, but writes are not synchronously confirmed, and an account failover is manual; this setup is not an automated DR plan. The lack of automatic failover for both the database and storage means this option does not meet strict RTO or RPO requirements.

• ✓

  Configure App Service backup to a secondary region, use Azure SQL Database active geo-replication with auto-failover group, and use geo-redundant storage (GRS) for Blob Storage.

  Why this is correct

  App Service backup to a secondary region ensures that web application content, configuration, and files are recoverable in a different geographic location; the backup can be stored in a paired region and restored to a new App Service instance. Azure SQL Database active geo-replication with an auto-failover group continuously replicates data to a readable secondary database in another region and automatically promotes it during an outage, typically achieving an RTO of about one minute and an RPO of zero for committed transactions. Geo-redundant storage (GRS) replicates blobs asynchronously to a paired region, providing regional resilience and allowing manual or automated failover. This combination covers all layers—compute, database, and storage—with automated or nearly automated failover paths, making it the correct DR architecture.

• ✗

  Configure App Service deployment slots, use Azure SQL Database geo-restore, and use Azure Storage locally-redundant storage (LRS).

  Why it's wrong here

  App Service deployment slots are designed for staging and blue-green deployments, not for disaster recovery; they do not replicate content or configuration across regions, and they rely on the same underlying App Service plan in the same region. Azure SQL Database geo-restore uses geo-replicated backups with an RPO of up to 1 hour, meaning the database can lose up to an hour of committed transactions, and restore is manual, so RTO is highly variable and typically slow. Locally-redundant storage (LRS) replicates data three times within a single data center in a single region, offering no protection against a regional outage. This solution lacks automated failover for any service and has an unacceptably high RPO/RTO for most production workloads, so it fails to meet disaster recovery requirements.

Go deeper

Related to this question