Plan and configure a high availability and disaster recovery environment practice questions

Increase the backup retention period to 35 days.

Why wrong: Increasing backup retention extends point-in-time restore history but does not change the replication RPO for geo-disaster recovery.

Enable zone redundancy on the database.

Why wrong: Enabling zone redundancy provides resilience against zone failures within a region, but does not affect geo-replication across regions.

Increase the DTU or vCore count.

Why wrong: Increasing DTU or vCore count improves performance but does not change replication mode or reduce geo-replication RPO.

The failover group uses Microsoft Entra ID authentication, which adds latency.

Why wrong: Incorrect: Authentication method does not affect failover time.

The secondary database is configured with asynchronous commit, causing delay.

Why wrong: Incorrect: Failover groups use synchronous commit for data synchronization.

The secondary database is not seeded and needs to be restored.

Why wrong: Incorrect: The secondary is already created and seeded.

Create a failover group between two servers in different regions.

Why wrong: Failover groups are for managed instances, not single databases.

Use geo-restore of the latest backup.

Why wrong: Geo-restore has a longer RTO (typically hours) and potential data loss.

Configure copy-only backups to a secondary region.

Why wrong: Copy-only backups are not a disaster recovery solution; they are for ad-hoc backups.

Initiate a forced failover from the new primary to the old primary.

Why wrong: Incorrect. A forced failover during synchronization could cause data loss if transactions are not fully replicated. It is not the recommended failback method.

Perform a forced failover again to switch back.

Why wrong: Incorrect. Simply repeating a forced failover without ensuring synchronization is not the proper procedure and risks data loss.

Delete the failover group and recreate it with the original primary as primary.

Why wrong: Incorrect. Deleting and recreating the failover group would cause data loss and is an unnecessary destructive action.

Configure active geo-replication to a secondary server in West US.

Why wrong: Active geo-replication must be configured proactively.

Create a copy-only backup and manually transfer it to West US.

Why wrong: Copy-only backup is not a standard DR procedure and would be slower.

Perform a point-in-time restore to a new database in West US.

Why wrong: Point-in-time restore is limited to the same region.

DTU consumption

Why wrong: DTU consumption is related to resource usage.

Data IO percentage

Why wrong: Data IO percentage is a performance metric.

Deadlocks

Why wrong: Deadlocks are unrelated to replication lag.

General Purpose

Why wrong: General Purpose uses asynchronous replicas, which have higher RPO and slower failover, not meeting the requirements.

Azure SQL Database (single)

Why wrong: Azure SQL Database (single) is a different product (not Managed Instance) and its high availability options do not match the specified RPO/RTO for Managed Instance.

Hyperscale

Why wrong: Hyperscale is a service tier for single databases, not Managed Instance, and its architecture is not designed for the specified RPO and RTO.

Change backup storage to locally-redundant (LRS) and rely on point-in-time restore.

Why wrong: Doesn't provide cross-region DR.

Enable zone redundancy on the primary instance.

Why wrong: Only protects within region.

Scale the instance to a higher service tier to improve restore performance.

Why wrong: Geo-restore time depends on backup size, not tier.

Enable zone redundancy on the current General Purpose database.

Why wrong: Enabling zone redundancy on General Purpose provides high availability across zones but does not provide a readable secondary for read scale-out. The application needs to offload read traffic, which zone redundancy alone cannot achieve.

Configure a readable secondary on the current General Purpose database.

Why wrong: The General Purpose service tier does not support readable secondaries. A readable secondary is only available in Business Critical or Hyperscale tiers. Therefore, this option is not feasible.

Create a secondary database in a different region and use active geo-replication.

Why wrong: Creating a secondary database in a different region (active geo-replication) is intended for disaster recovery, not for high availability within the same region. It does not help with minimizing downtime during planned maintenance or offloading read traffic within the region.

Deploy a General Purpose tier database with geo-replication.

Why wrong: Incorrect. General Purpose tier geo-replication is asynchronous, meaning potential data loss (RPO > 0).

Deploy a Hyperscale tier database with zone redundancy.

Why wrong: Incorrect. Hyperscale tier does not support synchronous replication for auto-failover groups; its geo-replication is asynchronous, and zone redundancy is within-region only.

Deploy a Serverless tier database with active geo-replication.

Why wrong: Incorrect. Serverless tier is not designed for mission-critical workloads and lacks the required availability and replication features.

Set up log shipping from West Europe to North Europe.

Why wrong: Log shipping is not a built-in feature of Managed Instance.

Configure active geo-replication between the instances.

Why wrong: Managed Instance does not support active geo-replication; it uses failover groups.

Create a failover group, but note the secondary is not readable.

Why wrong: The secondary in a failover group is readable when using Business Critical tier.

RTO of 5 minutes, RPO of 1 second.

Why wrong: Business Critical tier with failover groups offers an RTO of approximately 30 seconds and RPO of 0, not 5 minutes and 1 second.

RTO of 30 seconds, RPO of 5 seconds.

Why wrong: While the RTO of 30 seconds is accurate, the RPO of 5 seconds is not zero; Business Critical provides zero data loss.

RTO of 1 hour, RPO of 5 minutes.

Why wrong: Both the RTO (1 hour) and RPO (5 minutes) are significantly higher than the actual values for Business Critical tier.

Configure auto-failover groups between regions.

Why wrong: Auto-failover groups are not supported for Hyperscale.

Use geo-restore of automated backups.

Why wrong: Geo-restore has a higher RPO and does not provide a readable secondary.

Create a failover group with manual failover.

Why wrong: Failover groups are not supported.

Hyperscale tier with geo-replication and auto-failover group.

Why wrong: Auto-failover groups are not supported for Hyperscale.

Hyperscale tier with zone redundancy.

Why wrong: Zone redundancy provides availability within region, not automatic failover across regions.

General Purpose tier with active geo-replication.

Why wrong: General Purpose has asynchronous replication, RPO > 5 seconds.

Set up log shipping to a secondary VM.

Why wrong: Log shipping does not provide automatic failover.

Use database mirroring with automatic failover.

Why wrong: Database mirroring is deprecated and not supported on Azure VMs.

Deploy a Windows Server Failover Cluster Instance (FCI) using Azure Shared Disks.

Why wrong: FCI requires shared storage, which adds complexity.

Configure a failover group to another region.

Why wrong: Failover groups provide cross-region, not zonal, availability.

Deploy the instance in General Purpose tier with zone redundancy.

Why wrong: General Purpose tier does not support zone redundancy.

Use a Hyperscale tier instance with zone redundancy.

Why wrong: Hyperscale is not available for Managed Instance.

SELECT * FROM sys.dm_continuous_copy_status;

Why wrong: This DMV is deprecated.

SELECT * FROM sys.dm_database_copies;

Why wrong: This DMV is for copy operations, not geo-replication.

SELECT * FROM sys.dm_replication_status;

Why wrong: This DMV is for transactional replication.

Scale up the primary database to a higher service objective.

Why wrong: Scaling up does not reduce failover downtime.

Terminate all active connections to the primary database.

Why wrong: Connections are automatically terminated during failover.

Disable automatic failover on the failover group.

Why wrong: Automatic failover is not related to planned failover.

Failover group listener.

Why wrong: The listener is automatically provisioned; not a separate configuration step.

An elastic pool.

Why wrong: Elastic pools are optional; databases can be standalone.

Database mirroring.

Why wrong: Database mirroring is deprecated.

Always On availability groups.

Why wrong: Availability groups are for SQL Server on VMs.

Log shipping.

Why wrong: Log shipping is not supported in Azure SQL Database.