CCNA Plan and configure a high availability and disaster recovery environment Questions

After automatic failover occurs, the database is now hosted in the secondary region. When the primary region is restored, you must initiate a manual failover to make the primary region the new primary again. This ensures minimal data loss because the failover group synchronizes data during the manual failover.

Option B is incorrect because Azure SQL Database does not support automatic failback; you must manually fail over. Option C is incorrect because restoring from geo-redundant backup would result in data loss and is not necessary. Option D is incorrect because deleting and recreating the failover group could cause data loss and is not the recommended procedure.

Options D and E are correct. The Business Critical service tier provides synchronous replicas that automatically failover on node failure, ensuring high availability within a single region. Zone redundancy, when enabled in the Business Critical tier, places replicas across different availability zones, adding resilience to zone-level failures.

Option A (Hyperscale read replicas) are for read scaling, not high availability. Option B (active geo-replication) is for disaster recovery across regions, not single node failure. Option C (auto-failover group) is for managing failover of multiple databases, not directly for compute node resilience.

Active geo-replication creates a readable secondary database in a different region that can be used for reporting. Option A is wrong: auto-failover groups do not automatically provide a readable secondary; they are designed for failover, and while you can configure a readable secondary, active geo-replication is the primary method for cross-region read-scale. Option B is wrong because zone-redundant backup storage provides redundancy for backups, not a readable secondary.

Option D is wrong because geo-restore creates a new database from a backup and is not a continuously available readable replica.

A failover group with a secondary in another region provides automatic failover with low RPO (<1 hour) and RTO (<2 hours), and using the General Purpose tier is cost-effective. Option B is wrong because zone redundancy provides high availability within a single region, not disaster recovery across regions. Option C is wrong because geo-restore from geo-redundant backups has an RTO of several hours (typically 7-12 hours), which exceeds the required 2 hours.

Option D is wrong because upgrading to Business Critical tier is more expensive and not necessary for the RPO/RTO requirements; geo-replication is already available in General Purpose through failover groups.

Auto-failover groups with active geo-replication provide the lowest RPO (typically <5 seconds) and RTO (under 1 minute) for regional outages by enabling continuous data synchronization and automated failover across paired regions. Option A is incorrect because zone-redundant configuration only protects against zonal failures within a single region, not a full regional outage. Option C is wrong because long-term retention backups are for archival purposes and have much higher RPO/RTO.

Option D is incorrect because geo-restore from geo-redundant backups has an RPO of at least 1 hour and an RTO of several hours to days, failing to meet the strict requirements.

A failover group to a secondary region provides disaster recovery with an RPO of 5 minutes and RTO of 1 hour, meeting the regional outage requirements. Option D is correct because the Business Critical tier with zone redundancy offers zero data loss and automatic failover within 30 seconds for planned maintenance within a region. Option A is incorrect because long-term backup retention with geo-redundant storage does not provide automatic failover or meet the RPO/RTO targets.

Option B is incorrect because active geo-replication is not supported for Azure SQL Managed Instance. Option E is incorrect because the General Purpose tier does not support zone redundancy, so it cannot meet the zero data loss and fast failover requirements.

Options C and D can meet the RTO of 1 hour and RPO of 15 minutes. Active geo-replication (D) provides asynchronous replication to a secondary region with an RPO typically seconds to minutes, and failover can be initiated manually within minutes, meeting both targets. Auto-failover groups (C) build on active geo-replication and add automatic failover, also meeting the requirements.

Option A (PITR with geo-redundant backup storage) cannot reliably meet the 1-hour RTO because restoring from backups can take several hours depending on database size and activity. Option B (LTR) is for archival and not suitable for fast recovery. Option E (zone redundancy) provides high availability within a region, not disaster recovery across regions.

When the failover group has an automatic failover policy and the primary region experiences an outage, the automatic failover will only occur after the grace period (typically 1 hour) expires. Since only 30 minutes have passed, the failover has not yet triggered automatically. To force an immediate failover, you can use the Switch-AzSqlDatabaseFailoverGroup cmdlet with the -AllowDataLoss parameter, which initiates a forced failover that may result in data loss.

Option A is incorrect because changing the failover policy to Manual does not force a failover; it only changes the policy for future failovers. Option B is incorrect because setting secondaryType to Standby is not relevant to initiating a failover. Option D is incorrect because waiting for the grace period to expire would eventually result in automatic failover, but the requirement is to force failover immediately.

Failover groups for Azure SQL Managed Instance allow you to configure the secondary instance to allow read-only connections, enabling it to serve read-only workloads. This minimizes data loss by using automatic replication with a Recovery Point Objective (RPO) of less than 1 second. Option A (zone redundancy) provides high availability within a region, not disaster recovery across regions.

Option C (log shipping) is not a built-in feature for managed instances and does not support automatic failover. Option D (active geo-replication) is not supported for managed instances; failover groups are the recommended solution.

Failover groups for Azure SQL Managed Instance provide automatic failover to a secondary instance in a paired region, and the secondary is readable for read-only workloads, meeting the requirements. Option B is incorrect because 'auto-failover groups' is a term used for Azure SQL Database, not SQL Managed Instance; SQL MI uses failover groups, which also provide automatic failover. Option A is incorrect because geo-zone-redundant storage is a storage redundancy option, not a disaster recovery configuration for SQL MI.

Option C is incorrect because active geo-replication is available for Azure SQL Database, not for SQL Managed Instance.

The JSON configuration shows zoneRedundant set to true and the service tier is General Purpose. As of current Azure SQL Database documentation, zone redundancy is supported for the General Purpose tier (vCore purchasing model) in many regions. Therefore, the configuration is valid.

Option D correctly states that the database is in General Purpose tier and supports zone redundancy. Option A is incorrect because highAvailabilityReplicaCount is 0, not 1. Option B is incorrect because zone redundancy is available for General Purpose.

Option C is incorrect because backupStorageRedundancy is Geo (geo-redundant), not locally-redundant.

Azure Site Recovery (ASR) can replicate the Azure VM to a secondary region with a replication frequency as low as 5 minutes, meeting the RPO of 5 minutes. Upon failover, the RTO can be less than 15 minutes if the VM is properly configured and failover is regularly tested. Option A (Always On Availability Groups with synchronous commit) can achieve low RPO, but across regions, synchronous commit introduces significant latency and requires at least three replicas (including a witness) for automatic failover, making it complex and potentially unable to meet the RTO consistently.

Option C (daily backups) has an RPO of 24 hours, failing the 5-minute requirement. Option D (geo-redundant storage) provides storage-level replication but does not ensure application-consistent recovery or VM compute availability; auto-failover for storage does not fail over the VM itself. Therefore, ASR is the best choice for the specified RPO and RTO in a region failure scenario.

Hyperscale databases support zone redundancy, which automatically places database replicas in different availability zones, ensuring availability during a single zone failure without manual intervention. Option A is incorrect because failover groups with a secondary in a different zone are used for SQL Managed Instance or other service tiers, not for Hyperscale zone redundancy. Option C is incorrect because active geo-replication is for disaster recovery across regions, not for zone-level failures.

Option D is incorrect because auto-failover groups are for SQL Managed Instance or other tiers, and zone redundancy is the native solution for Hyperscale.

To achieve the 99.99% SLA for Azure SQL Managed Instance, you must use the Business Critical service tier (which provides local redundancy) and deploy the instance as zone-redundant (which protects against zone failures). Option A (automated backups with long-term retention) is for data durability and recovery, not availability. Option D (geo-replication) is for disaster recovery, not high availability within a region.

Option E (General Purpose) offers a lower SLA (99.99% only with zone redundancy, but still not the highest available; typically 99.99% is achieved with Business Critical and zone redundancy). Therefore, B and C are the correct choices.

It meets all requirements: upgrading the primary to Business Critical provides synchronous replication with an RPO of 2-5 seconds, and configuring a failover group with a readable secondary in West Europe using Business Critical ensures the secondary can serve read traffic from Europe and failover can occur within 1 hour. The listener endpoint simplifies application connection management. Option A is incorrect because General Purpose tier has an RPO of 5-30 minutes, which cannot meet the 5-second requirement, and a same-region secondary does not serve European read traffic.

Option C is incorrect because zone-redundancy only protects within a region, not across regions, and a General Purpose secondary would have higher RPO. Option D is incorrect because a readable secondary in the same region does not serve read traffic from Europe, and geo-restore has an RTO of hours, not 1 hour.

The output shows zoneRedundant is true and replicationRole is Primary. Zone redundancy means the database has replicas in different availability zones within the same region, and replicationRole being Primary indicates this database is the primary in its replication relationship. Therefore, option B is correct.

Option A is incorrect because active geo-replication involves a secondary in a different region, not just zone redundancy. Option C is incorrect because Hyperscale databases have a different architecture; zoneRedundant may be supported but the output does not specify Hyperscale. Option D is incorrect because a readable secondary replica is not indicated; zone redundancy does not necessarily imply a readable secondary.

With automatic failover configured and a grace period of 1 hour, Azure SQL Database will wait for the grace period to expire before initiating failover. If the primary region remains unreachable after 1 hour, automatic failover occurs. Option A is incorrect because failover does not happen immediately; it waits for the grace period.

Option B is incorrect because manual failover is possible but not required; automatic failover will proceed after the grace period. Option D is incorrect because the secondary database is not deleted or re-created; it is already provisioned and will become the primary upon failover.

Active geo-replication provides near-real-time asynchronous replication to a secondary region, and with Business Critical, you can configure a readable secondary that can be failed over manually or automatically with minimal data loss. Option A is wrong because failover groups are built on top of geo-replication but do not guarantee minimal data loss by themselves; they rely on the replication mode. Option B is wrong because auto-failover groups include geo-replication but the question asks for the specific feature to implement.

Option D is wrong because zone redundancy protects against zonal failures within a region, not regional failures.

After a manual failover, the former secondary becomes the new primary. The old primary, if still available, becomes a secondary. To restore DR capability with a new secondary in Central US, you must first remove the existing geo-replication link between the current primary and the old primary (the orphaned secondary).

Without removing this link, you cannot add another secondary. Once the link is removed, you can create a new geo-secondary in Central US from the current primary. Therefore, option D is correct.

Option A is incorrect because deleting the old primary is unnecessary and could be destructive. Option B is incorrect because a new secondary cannot be added while a geo-replication link already exists to the old primary. Option C is incorrect because performing a planned failover back to the old primary would cause unnecessary downtime and does not facilitate adding a secondary in Central US.

Point-in-time restore (PITR) using geo-redundant backup storage provides disaster recovery without requiring a secondary database, thus avoiding additional compute costs. Geo-redundant backups are automatically stored in a paired region, so in the event of a regional outage, you can restore the database to any point within the backup retention period (typically up to 35 days). For a 50 GB database, the RTO of 2 hours is achievable, and the RPO of 1 hour is satisfied because backups are taken every 5-10 minutes.

Option A (active geo-replication) would incur compute costs for a readable secondary database. Option C (zone redundancy) provides high availability within a region, not cross-region DR. Option D (failover group with a secondary) also requires a secondary database costing compute resources.

Initiating a manual forced failover immediately fails over to the secondary, minimizing downtime. Option A is incorrect because dropping and recreating the failover group introduces additional steps and downtime, and is unnecessary since a manual failover can be performed directly. Option B is incorrect because waiting for automatic failover would take up to 1 hour due to the grace period, causing longer downtime.

Option C is incorrect because altering the grace period to 0 and then waiting for automatic failover is slower than performing a manual forced failover, which provides the fastest recovery.

Deploying two Azure VMs in an availability set and configuring SQL Server Always On availability group with synchronous commit and automatic failover meets the requirements of high availability with automatic failover and no data loss during planned patching (by performing a manual failover). This solution minimizes cost compared to Azure SQL Database Managed Instance or geo-replication. Option A is incorrect because migrating to Azure SQL Database Managed Instance is a different platform, not SQL Server on Azure VM, and geo-replication is for disaster recovery, not planned patching.

Option B is incorrect because log shipping is not automatic and can result in data loss. Option C is incorrect because a single VM with FCI using Storage Spaces Direct does not provide automatic failover for planned patching; it requires a secondary node.

To ensure no data loss during a failover in a distributed availability group (AG), you must configure synchronous commit mode on the distributed AG. In this mode, a transaction is committed only after it has been hardened on both the primary replica and the primary forwarder (the primary of the local AG). This guarantees that all committed data is available on the secondary side.

Option A is incorrect because backup preference does not affect data loss. Option B is incorrect because asynchronous commit can allow data loss if the primary fails before the data is replicated. Option D is incorrect because automatic seeding is only used for initial data synchronization, not for ongoing data protection.

The correct combination is Business Critical service tier (B) and failover groups with active geo-replication (C). Business Critical provides multiple read-write replicas and automatic failover within a region, enabling low RTO. Active geo-replication with failover groups extends this across regions, achieving the required RPO of 5 seconds and RTO of 30 seconds.

Zone-redundant configuration (E) only provides intra-region resilience, not cross-region disaster recovery. Geo-restore from GRS backups (D) has an RTO measured in hours. General Purpose (A) lacks the performance and replica architecture to meet the strict RTO/RPO.

Options A and B are correct. Failover groups allow multiple databases to fail over together as a unit (A), which is not possible with active geo-replication where each database must be failed over individually. Failover groups also provide a read-write listener endpoint that remains unchanged after a failover (B), simplifying application connection strings.

Option C is incorrect because failover groups can be configured for automatic failover but do not automatically fail over without any manual intervention or a defined auto-failover policy. Option D is incorrect because both failover groups and active geo-replication provide readable secondary replicas, so this is not a distinct benefit. Option E is incorrect because failover groups still rely on geo-redundant storage; they do not eliminate the need for it.

With active geo-replication, there is no automatic listener endpoint. To achieve automatic reconnection with minimal code changes, the application should implement retry logic in the connection string that includes the failover partner (secondary) and set ApplicationIntent=ReadWrite. When the primary is unavailable, the driver will automatically attempt to connect to the secondary.

Option A is incorrect because manually updating DNS is not automatic and requires manual intervention, which violates the 'minimal code changes' requirement. Option B is incorrect because a failover group listener endpoint is specific to failover groups, not active geo-replication; configuring a failover group would be a different setup. Option C is incorrect because using Azure Traffic Manager introduces additional complexity and is not considered minimal code change; it requires managing a separate DNS service.

It combines synchronous data redundancy within the primary region via zone-redundant Business Critical, which provides automatic failover within the region for high availability, with an asynchronous geo-failover group to a paired region using a non-readable secondary replica. The Business Critical tier offers synchronous replication within the region, meeting the 10-second RPO, and the failover group enables geo-failover within 15 minutes (RTO). Using a non-readable secondary (no read scale-out) minimizes compute costs during normal operations.

Option A is wrong because General Purpose uses asynchronous replication, which cannot achieve a 10-second RPO. Option B is wrong because zone-redundancy alone does not protect against a full regional disaster. Option D is wrong because pairing a Business Critical primary with a General Purpose secondary would result in asynchronous replication between regions, risking higher RPO, and a readable secondary adds unnecessary cost.

Hyperscale service tier with zone-redundant configuration meets the requirements: it supports zone redundancy within the same region (satisfying data sovereignty), provides fast failover with RPO of 10 seconds and RTO under 30 minutes, and is suitable for large databases (2 TB). Option A is incorrect because Business Critical with zone redundancy and a failover group is designed for high availability within a region, but the mention of a failover group implies geo-replication, which is unnecessary and may increase costs; also, Business Critical has a maximum size of 4 TB but Hyperscale is more cost-effective for large databases. Option C is incorrect because General Purpose does not support zone redundancy and cannot meet the RPO/RTO.

Option D is incorrect because geo-replication to another region violates data sovereignty and incurs higher egress costs.

For Azure SQL Managed Instance, failover groups provide automatic failover to a secondary region and allow read-only workloads to use the secondary replica, minimizing data loss. Option B is incorrect because availability groups are not supported for Azure SQL Managed Instance; they are for SQL Server on Azure VMs. Option C is essentially the same as A but less precise; the standard solution is to deploy a second managed instance in the secondary region and configure a failover group.

Option D is incorrect because active geo-replication is a feature of Azure SQL Database, not Azure SQL Managed Instance.

For Azure SQL Database Hyperscale, named replicas can be created in a secondary region. These replicas provide both read scale-out and can be promoted to primary during a regional failover, ensuring minimal data loss. Option A is incorrect because zone redundancy provides high availability within a single region, not disaster recovery across regions.

Option C is incorrect because active geo-replication is not supported for Hyperscale; named replicas serve the geo-replication purpose. Option D is incorrect because failover groups are not supported for Hyperscale; named replicas are the mechanism for cross-region failover and read scaling.

Add ApplicationIntent=ReadOnly to the connection string and use the failover group listener. Azure SQL Database failover groups provide a read-only listener endpoint. When a client connects to the failover group listener with ApplicationIntent=ReadOnly in the connection string, the connection is automatically routed to the secondary database.

This offloads read-only queries from the primary. Option B is incorrect because Traffic Manager is not needed; the failover group listener already handles routing. Option C is incorrect because read-scale is a feature for querying readable secondaries in a Business Critical tier, but it does not automatically route read-only queries to a geo-secondary.

Option D is incorrect because using a separate connection string pointing directly to the secondary server defeats the purpose of automatic failover and redirection; the listener provides automatic routing and failover.

The Restore-AzSqlDatabase cmdlet with the -FromGeoBackup parameter requires the source database to have geo-redundant backup storage (also known as geo-redundant storage) enabled. This allows restoration from geographically replicated backups. Option B is incorrect because point-in-time restore is not required for a geo-restore; geo-restore uses the geo-redundant backup independently.

Option C is incorrect because the source database does not need to be online at the time of restoration; geo-backups are stored in Azure storage and are available even if the source database is offline. Option D is incorrect because the purpose of geo-restore is to restore to a different region; therefore, the target server can be in a different region than the source.

To achieve automatic failover with zero data loss during a regional outage, you need a solution that supports synchronous replication for a secondary replica in another region. Azure SQL Database Business Critical tier (or Premium tier) supports auto-failover groups with a readable secondary in a paired region, where the secondary is kept in sync synchronously, ensuring no data loss (RPO=0). Option A correctly describes this configuration.

General Purpose tier (Option B) uses asynchronous geo-replication, which has potential data loss. Hyperscale tier (Option C) supports zone redundancy but not synchronous replication across regions for auto-failover groups. Serverless tier (Option D) is not suitable for mission-critical workloads and does not provide the required availability guarantees.

After a failover using active geo-replication, the original primary becomes a secondary database in the replication relationship. To bring it back online with minimal data loss, you re-establish geo-replication from the new primary to the original primary. This allows the original primary to synchronize and become a readable secondary again.

Option D is correct. Option A is incorrect because geo-replication is not automatically re-established; you must manually configure it. Option B is incorrect because restoring from backup would cause data loss and require creating a new secondary.

Option C is incorrect because deleting the original primary is unnecessary; it can be reused as a secondary.

Azure SQL Database Hyperscale tier supports geo-replication (currently in preview), which creates a readable secondary database in a different region. This secondary database also supports point-in-time restore within the secondary region, meeting the requirement for disaster recovery with point-in-time restore capability. Option B is incorrect because auto-failover groups are not supported for Hyperscale databases.

Option C is incorrect because geo-restore of automated backups has a higher recovery point objective (RPO) compared to geo-replication. Option D is incorrect as failover groups are not supported for Hyperscale.

Deploy active geo-replication to a secondary region and automate failover. Active geo-replication provides an asynchronous secondary replica in a different region with an RPO of up to 5 seconds, meeting the 15-second requirement. By automating failover (e.g., via Azure PowerShell, CLI, or Azure Automation), the RTO can be minimized to under 1 hour.

Option A, creating a failover group with automatic failover, also uses geo-replication but the automatic failover policy may introduce additional detection time, making it harder to guarantee an RTO of exactly 1 hour. Additionally, failover groups are designed for managing multiple databases, adding unnecessary complexity for a single database. Option C, long-term backup retention and restore, has an RPO of hours, not seconds.

Option D, zone-redundant availability, protects against zone failures within a single region, not a regional outage.

The read-only endpoint's failover policy is set to Disabled, meaning it will not automatically redirect connections after a failover. Option A is incorrect because the read-write endpoint has its failover policy set to Automatic, so it will redirect connections automatically. Option C is incorrect because the grace period for data loss is set to 1 hour (3600 seconds), but the statement says 'more than 60 minutes' which is not exactly accurate; also the primary focus is on the endpoint behavior.

Option D is incorrect because the read-only endpoint is used for read-only connections, not read-write.

The correct features are failover groups and readable secondary replicas. A failover group with a secondary managed instance in a different region provides automatic failover for disaster recovery. Within the failover group, you can configure the secondary replica to be readable, allowing read-only workloads to use it.

Option C (failover group with secondary in different region) enables the automatic failover, and option B (readable secondary replicas within the failover group) is a configuration option that meets the requirement for readable secondaries. Together, they satisfy the disaster recovery and readability requirements.

The Business Critical tier with zone redundancy provides a 99.995% SLA within a region. However, to withstand a regional outage, you need geo-replication. A failover group with active geo-replication ensures that if the primary region fails, you can fail over to a secondary region.

Option A (Business Critical zone-redundancy only) protects against zone failures within a region but not a full regional outage. Option B (General Purpose with active geo-replication) has a lower SLA (99.99%) and does not meet the 99.995% requirement. Option C (Hyperscale with geo-replication) also has a lower SLA (99.95%) than required.