AZ-305 Design infrastructure 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.

• ✗

  Geo-replication ensures zero data loss during failover

  Why it's wrong here

  Active geo-replication continuously sends transaction log records to a secondary database asynchronously, meaning transactions committed on the primary are acknowledged before the log has been hardened on the secondary. Consequently, a geo-failover can lose the most recent transactions that had not yet replicated, so the recovery point objective (RPO) is non-zero and can be several seconds or more. There is no zero-data-loss guarantee for geo-replication; a synchronous, availability-group-style solution would be required for that guarantee.

• ✓

  Geo-replication supports up to four readable secondary replicas

  Why this is correct

  Azure SQL Database active geo-replication is a valid design consideration because it supports establishing up to four readable secondary replicas. This technical mechanism allows organisations to distribute read workloads across multiple Azure regions, significantly enhancing disaster recovery capabilities and regional resilience. Designing with multiple secondaries facilitates robust business continuity planning and global read-scale scenarios, directly addressing the need for resilient database architectures.

• ✗

  Geo-replication provides automatic failover without manual intervention

  Why it's wrong here

  Geo-replication alone does not provide any automatic failover capability; the secondary database remains in standby and a role change must be manually initiated by an administrator or application through the failover API, PowerShell, CLI, or Azure portal. To obtain automatic, policy-driven failover you must additionally create an auto-failover group, which is a separate orchestration layer that applies a breaker policy and grace period. Thus, while auto-failover groups can automate the process, active geo-replication itself does not.

• ✗

  Geo-replication requires a listener for client connections

  Why it's wrong here

  A listener is a virtual network name (VNN) used by SQL Server Always On Availability Groups to route client connections to the current replica without changing the connection string. Azure SQL Database active geo-replication does not use listeners; each secondary is an independent readable database with its own server-level DNS endpoint, and clients connect directly to that endpoint (for example, secondary-server.database.windows.net). Therefore, requiring a listener contradicts the geo-replication architecture and is not a valid design consideration.

• ✓

  Geo-replication can be used to offload read-only workloads

  Why this is correct

  Each geo-replication secondary is a readable database, so you can offload read-only workloads, such as reporting, business intelligence, and analytical queries, to the secondaries while preserving the primary's capacity for transactional writes. This read-scale design reduces contention on the primary and, when the secondary is placed in another Azure region, provides low-latency reads to geographically distributed users. Supporting up to four readable secondaries makes this an even more powerful and commonly used design consideration for high-availability, disaster-recovery, and global-read architectures.

Go deeper

Related to this question