Task 3.2: Design for high availability

• AAn availability set with three fault domains behind a Standard load balancer

  Incorrect

  A datacenter failure can still take every VM in the set down at once.

• BA scale set spread across three availability zones behind a zone-redundant Standard load balancer

  Correct

  Zones are separate datacenters, so VMs in other zones keep serving, and a zone-redundant frontend survives the loss of a zone.

• CA proximity placement group that holds all six VMs

  Incorrect

  A proximity placement group puts VMs close together for latency, which concentrates rather than spreads the risk.

• DSix single VMs with premium SSD disks in the same zone

  Incorrect

  One zone is one failure domain, so a datacenter failure stops all of them.

Availability zones are physically separate groups of datacenters within a region, so VMs spread across zones survive the loss of one zone. A zone-redundant Standard Load Balancer frontend keeps distributing traffic when one zone is lost.

• AActive geo-replication for each database to a server in West US

  Incorrect

  The app would have to connect to the secondary server's name after a failover, so connection strings would change.

• BThe zone-redundant configuration turned on for each database in East US

  Incorrect

  It changes nothing for a full outage of East US, which is the failure the requirement covers.

• CA failover group with the three databases and a server in West US

  Correct

  A failover group fails over its databases together and gives read-write and read-only listener endpoints that keep their names.

• DGeo-restore of the databases into West US when needed

  Incorrect

  Geo-restore creates new databases from backups with data loss and new names, and takes time.

Failover groups manage geo-replication and failover of a group of databases. The listener endpoints stay the same after failover, so connection strings don't change.

• AAvailability zone support on the East US region

  Correct

  Zone support places replicas across zones in the region, so a zone failure doesn't interrupt the account.

• BMulti-region writes on the account

  Incorrect

  Multiple write regions would accept writes everywhere and bring the conflicts the design avoids.

• CThe strong consistency level

  Incorrect

  Consistency sets read guarantees; it doesn't fail over regions or survive a zone loss.

• DService-managed failover with a failover priority list

  Correct

  Service-managed failover promotes a read region to write region when the write region becomes unavailable.

• EPeriodic backup with geo-redundant backup storage

  Incorrect

  Backups help restore data later, not keep the account available during an outage.

Availability zone support keeps a region's replicas in separate zones. For single-write-region accounts, service-managed failover moves the write region to the next region in the priority list during a regional outage, without enabling multi-region writes.

• AZone-redundant storage (ZRS)

  Correct

  ZRS is supported for SSD file shares and copies data synchronously across zones in the region.

• BGeo-zone-redundant storage (GZRS)

  Incorrect

  Geo-redundancy options aren't supported for SSD file shares; they apply to HDD SMB shares.

• CLocally redundant storage (LRS)

  Incorrect

  LRS keeps all copies in one datacenter, so a zone failure can make the share unavailable.

• DGeo-redundant storage (GRS)

  Incorrect

  GRS isn't offered for SSD file shares and uses LRS in the primary region anyway.

For Azure Files, ZRS is available for both SSD and HDD shares, while the geo-redundant options GRS and GZRS are only available for HDD SMB shares. ZRS keeps an SSD share available during a zone failure.

• AThe Standard plan scaled out to three instances

  Incorrect

  Standard plans don't support zone redundancy, so the instances aren't guaranteed to be in different zones.

• BA second app in the same region behind Azure Traffic Manager

  Incorrect

  Two apps in one region without zone redundancy can still share a zone, and it adds routing to manage.

• CDaily App Service backups restored to a new app after a failure

  Incorrect

  Restoring a backup after an outage isn't staying available during it.

• DA Premium v3 plan with zone redundancy turned on and at least two instances

  Correct

  Zone redundancy needs a Premium v2 to v4 plan and a minimum of two instances, which App Service spreads across zones.

App Service supports zone redundancy on Premium v2 to v4 plans in regions with availability zones. The plan must have at least two instances, and App Service distributes them across zones.

• AAn Always On availability group with both SQL Server VMs placed in one availability set

  Incorrect

  Both VMs can still go down together when that datacenter is lost.

• BA single VM with premium SSD disks and Azure Backup

  Incorrect

  A single VM restored from backup means downtime and data loss since the last backup.

• CLog shipping to a VM in another region

  Incorrect

  Log shipping is asynchronous with manual failover, so it can lose data and doesn't fail over automatically.

• DAn availability group with synchronous replicas in different availability zones

  Correct

  Zones protect against a datacenter failure, and synchronous replicas with automatic failover avoid data loss.

For SQL Server on Azure VMs, availability group replicas in different availability zones protect against the failure of an entire datacenter, and synchronous commit with automatic failover gives zero data loss.

• ASame-zone high availability

  Incorrect

  A standby in the same zone doesn't survive the loss of that zone.

• BZone-redundant high availability, with the standby in another zone

  Correct

  The service keeps a warm standby in a second zone, replicates synchronously and fails over automatically.

• CA read replica in the same region

  Incorrect

  Read replicas replicate asynchronously and don't fail over automatically, so committed data can be lost.

• DGeo-redundant backup storage

  Incorrect

  Geo-redundant backups support restores in another region, not automatic failover within this one.

With zone-redundant high availability, Azure Database for PostgreSQL provisions a warm standby in a different availability zone, replicates changes synchronously for zero data loss and fails over automatically.

• ARead-access geo-zone-redundant storage (RA-GZRS)

  Correct

  RA-GZRS uses ZRS in the primary region and geo-replicates to a secondary region that is always readable.

• BGeo-zone-redundant storage (GZRS)

  Incorrect

  GZRS has the zone and geo copies, but the secondary isn't readable until a failover.

• CRead-access geo-redundant storage (RA-GRS)

  Incorrect

  RA-GRS keeps the primary copies in one datacenter with LRS, so a zone failure isn't covered.

• DZone-redundant storage (ZRS)

  Incorrect

  ZRS has no secondary region to read from.

GZRS combines ZRS in the primary region with asynchronous copies to a secondary region; RA-GZRS adds read access to the secondary at all times, without a failover.

• AThe Free pricing tier with more nodes

  Incorrect

  The Free tier has no uptime SLA, however many nodes it has.

• BNode pools spread across three availability zones

  Correct

  Nodes in several zones keep pods running when one zone is lost.

• CA proximity placement group for all node pools

  Incorrect

  Proximity placement keeps nodes close together, which works against spreading them across zones.

• DThe Standard pricing tier for the cluster

  Correct

  The Standard tier adds the cluster uptime SLA that the Free tier lacks.

• ESpot node pools for every workload

  Incorrect

  Spot nodes can be evicted at any time, which lowers availability.

Spreading AKS node pools across availability zones protects workloads from a zone failure. The Standard tier provides the financially backed uptime SLA for the cluster's control plane.