Plan and configure high availability and disaster recovery practice questions

Deploy the database in the Business Critical tier with zone-redundant configuration in West US

Why wrong: Incorrect. Zone-redundant configuration within the same region does not protect against a full regional outage.

Enable geo-zone-redundant backup storage and perform point-in-time restore

Why wrong: Incorrect. Geo-zone-redundant backup storage and point-in-time restore have much higher RTO (hours) and cannot meet 5-second RPO.

Configure Active Geo-Replication with a readable secondary in East US

Why wrong: Incorrect. Active Geo-Replication requires manual failover, which typically takes several minutes, failing the RTO of 30 seconds.

Implement Azure Site Recovery to replicate the VM to a secondary region.

Why wrong: Azure Site Recovery can replicate VMs, but RPO may be up to a few minutes and RTO can be longer due to VM boot time and application recovery. It might not guarantee RTO of 30 minutes.

Set up log shipping to a secondary SQL Server in a different region and perform manual failover.

Why wrong: Log shipping copies and restores transaction log backups to a secondary SQL Server asynchronously; the secondary is left in a restoring state until failover. Although you can take log backups every few minutes to approach a small RPO, a manual failover requires you to run a script, set the database online, and repoint the application or DNS, which typically takes far longer than 30 minutes. You also risk data loss because the primary's last log backup may not yet have reached the secondary.

Increase the frequency of transaction log backups to every 5 minutes and use geo-restore.

Why wrong: Merely increasing transaction log backup frequency reduces the time between backups, which improves RPO but does not shorten the time to restore those backups to the geo-restored database. Geo-restore creates a new database from a geo-redundant backup stored in a paired region; because the copy and restore are asynchronous and involve copying large backup blobs, the operation can take hours or even longer than a day for large databases. Additionally, manual redirection of apps and potential data inconsistency mean this is a backup-based DR option, not a high-availability one, so it cannot meet an RTO of 30 minutes.

The recovery model is set to Full instead of Simple.

Why wrong: Incorrect. Azure SQL Database always uses the full recovery model and does not support changing it to simple. Recovery model does not affect geo-replication seeding.

The primary database SalesDB is not zone-redundant.

Why wrong: Incorrect. Zone redundancy is not a prerequisite for geo-replication. Geo-replication can be configured on databases without zone redundancy.

The secondary database is being used as a read-only replica.

Why wrong: Incorrect. Using the secondary as a read-only replica does not prevent seeding. The secondary is normally readable after seeding completes, but the seeding process itself is not affected by read-only usage.

Active Geo-Replication with a secondary in East US 2

Why wrong: Active Geo-Replication is not supported for SQL Managed Instance.

Enable geo-redundant backup storage and restore to West US

Why wrong: Geo-restore has RPO of hours, not seconds.

Set up a Failover Group with manual failover to a secondary in West US

Why wrong: Manual failover is not automatic.

Configure Log Shipping to a secondary VM

Why wrong: Log shipping requires manual failover, not automatic.

Deploy a Failover Cluster Instance using Azure Shared Disks

Why wrong: Requires shared storage, which is not desired.

Use Database Mirroring with automatic failover

Why wrong: Database mirroring is deprecated and not recommended.

Restore a geo-redundant backup to the secondary region

Why wrong: Restoring a backup takes too long for a drill.

Configure Active Geo-Replication to the secondary region

Why wrong: Active Geo-Replication is not supported for Hyperscale.

Create a named replica in the secondary region and fail over manually

Why wrong: Named replicas are for read scale-out, not disaster recovery.

Azure Files share for witness

Why wrong: Optional, not required.

Azure SQL Database

Why wrong: Not relevant for SQL Server on VMs.

VPN gateway between regions

Why wrong: Not required.

Recovery Point Objective (RPO) of 1 second

Why wrong: Both have RPO of 5 seconds.

Support for SQL Server Authentication

Why wrong: Both support SQL Server Authentication.

The availability group listener is not configured correctly

Why wrong: Listener issues do not cause replica disconnection.

The primary instance encountered a critical error and failed over automatically

Why wrong: PENDING_FAILOVER indicates a manual or forced failover, not automatic.

The cluster has lost quorum

Why wrong: Quorum loss would show different symptoms; both replicas would be affected.

Add a second secondary replica to the auto-failover group in the same region.

Why wrong: During a regional outage, all replicas in the same region are affected.

Increase the service objective of the secondary replica in the auto-failover group to a higher DTU or vCore to handle the read load.

Why wrong: Scaling up does not add additional read replicas; the secondary still has limited capacity.

Change the database to the Hyperscale tier, which supports multiple readable replicas and automatic failover.

Why wrong: Hyperscale does not support auto-failover groups with the same RTO/RPO and changes the architecture.

Enable read-scale out on the secondary database.

Why wrong: Read-scale out is optional and not required for automatic failover.

Set the secondary database to have the same service tier as the primary.

Why wrong: Service tiers can differ; not a requirement for automatic failover.

Configure zone redundancy on the primary database.

Why wrong: Zone redundancy provides HA within a region, not for geo-failover.

Navigate to Automatic tuning settings, then select the Azure SQL Database, then enable the desired options, then save changes.

Why wrong: This is incorrect because you need to select the database before accessing its automatic tuning settings; navigation to the settings is done from the database blade.

Select the Azure SQL Database, then enable the desired options, then navigate to Automatic tuning settings, then save changes.

Why wrong: This is incorrect because you must navigate to the automatic tuning settings before you can enable any options; enabling options without being in the correct settings page is not possible.

Enable the desired options, then select the Azure SQL Database, then navigate to Automatic tuning settings, then save changes.

Why wrong: This is incorrect because you cannot enable options before selecting the database or accessing the settings; the steps are completely out of logical order.

Create a job, define steps, schedule, connect to the instance, then enable and start.

Why wrong: This is incorrect because you cannot create a job before connecting to the instance; the connection is required first.

Connect to the instance, define steps, create a job, schedule, then enable and start.

Why wrong: This is incorrect because you must create the job before defining steps; steps belong to a job.

Connect to the instance, create a job, schedule, define steps, then enable and start.

Why wrong: This is incorrect because the schedule should be set after defining steps, otherwise the job would run without steps.

Transparent Data Encryption (TDE): Encrypts data in use on client side

Why wrong: Incorrect — TDE encrypts data at rest, not in use. This definition describes Always Encrypted.

Always Encrypted: Encrypts data at rest

Why wrong: Incorrect — Always Encrypted encrypts data in use on the client side, not at rest. This definition describes TDE.

4060: Login failed for user 'username'.

Why wrong: Incorrect — login failure is error 18456, not 4060. Error 4060 is about database access.

18456: Cannot open database requested by the login.

Why wrong: Incorrect — database open failure is error 4060, not 18456. Error 18456 is login failure.

The failover policy is set to Automatic, but the grace period is too long.

Why wrong: Grace period is acceptable; the issue is backup redundancy.

The secondary managed instance mi2 is in the same region as the primary.

Why wrong: Secondary is in westus, primary in eastus; different regions.

The read-only endpoint failover policy is Disabled, which prevents read-only traffic after failover.

Why wrong: Read-only failover policy is not required for automatic failover.

The long-term retention policy interferes with point-in-time restore.

Why wrong: Incorrect. Long-term retention policies do not interfere with point-in-time restore; they operate independently.

The requested restore point is outside the 7-day retention period.

Why wrong: Incorrect. The requested date is within the 7-day retention period, so this is not the cause of error 406.

The automated backup frequency is 12 hours, so point-in-time restore is not supported.

Why wrong: Incorrect. Azure SQL Database supports point-in-time restore regardless of full/differential backup frequency because transaction log backups are taken frequently (every 5-10 minutes).

The automatic failover policy requires a quorum that is not met.

Why wrong: Quorum issues would affect all replicas, not just SQL2.

The listener is not configured correctly for SQL2.

Why wrong: Listener configuration does not affect replica synchronization.

The secondary replica SQL2 has an incompatible database version.

Why wrong: Version incompatibility would prevent the replica from joining, but the error indicates a connection timeout.

The geo-replication will continue seamlessly after the restore.

Why wrong: Geo-replication is disrupted when the primary database is restored to a different point.

The restore will fail because the database is in a geo-replication relationship.

Why wrong: Restore is allowed but will break replication.

The secondary database will automatically be restored to the same point in time.

Why wrong: The secondary is not automatically restored.

The secondary database is lagging behind the primary by a significant amount.

Why wrong: Lagging would show PENDING or less than 100% complete.

The secondary database is in the process of initial seeding and is not yet fully synchronized.

Why wrong: Initial seeding would show a replication state of SEEDING and percentComplete less than 100.

The replication link is broken and needs to be re-created.

Why wrong: A broken link would show a state like SUSPENDED or ERROR.