High Availability practice questions

Availability Zone

Why wrong: Availability Zones provide redundancy across separate physical locations, offering higher SLA but not required for simple within-datacenter HA.

Virtual Machine Scale Set with manual scaling

Why wrong: Scale Sets are for auto-scaling and can use availability zones or sets, but the primary HA feature within a region is the Availability Set.

Azure Site Recovery

Why wrong: Site Recovery is for disaster recovery across regions, not for high availability within a single region.

Azure Redis Cache Basic tier

Why wrong: Basic tier does not provide high availability (no SLA) and runs on a single node, so it does not meet the requirement for high availability.

Azure Redis Cache Premium tier

Why wrong: Premium tier provides additional features like data persistence and clustering, but it is unnecessary for the stated requirement for this requirement and more expensive.

Azure Content Delivery Network

Why wrong: Azure CDN is for caching static content (images, videos) at edge locations, not for application session state or dynamic data caching.

Azure App Service with autoscale rules and deployment slots

Why wrong: Azure App Service is a platform-as-a-service (PaaS) offering, not based on VMs. The requirement specifies Azure VMs, so App Service is not appropriate.

Azure Load Balancer with a backend pool of VMs and autoscale rules applied to individual VMSS

Why wrong: While Load Balancer distributes traffic, it does not provide autoscaling itself. You would still need VMSS for auto-scaling. This option is incomplete because it separates the autoscale from the compute platform.

Azure Traffic Manager with endpoints in separate regions and Manual scaling of VMs

Why wrong: Traffic Manager is for global traffic routing, not intra-region auto-scaling. Manual scaling does not meet the requirement for automatic scaling based on CPU. Also, it does not address zone-level high availability within a region.

Azure Front Door for web tier, Azure Load Balancer for database tier, and SQL Server on Azure VMs with Always On

Why wrong: Front Door is global and not needed for a single-region web tier; Load Balancer is for network traffic, not database tier; SQL Server on VMs adds overhead.

Azure Traffic Manager for web tier, Azure Application Gateway for database tier, and Azure SQL Database with failover groups

Why wrong: Traffic Manager is DNS-based and doesn't provide SSL termination; Application Gateway is not a database load balancer.

Azure Application Gateway for web tier, Azure Load Balancer (internal) for application tier, and Azure SQL Database with geo-restore

Why wrong: Geo-restore is for point-in-time recovery from a backup, not for high availability with automatic failover.

MongoDB API with strong consistency and multi-region writes enabled

Why wrong: Strong consistency is not compatible with multi-region writes; this configuration is invalid.

Table API with consistent prefix consistency and single-region writes

Why wrong: Table API stores key-value data, not JSON; single-region writes do not meet the multi-region write requirement.

Gremlin API with session consistency and multi-region writes enabled

Why wrong: Gremlin API is for graph databases, not suitable for JSON document storage.

Azure Application Gateway v2.

Why wrong: Application Gateway is a layer 7 load balancer with features like SSL termination and cookie-based affinity. These are not required, and it is more expensive than needed for simple HTTP distribution.

Azure Traffic Manager.

Why wrong: Traffic Manager is a DNS-based global traffic routing service. It does not provide health probes at the load level and is designed for multi-region scenarios, not single-region high availability.

Azure Front Door.

Why wrong: Front Door is a global application delivery network with layer 7 features. It adds unnecessary latency and cost for a single-region deployment and does not replace a regional load balancer.

SQL Server Failover Cluster Instance (FCI)

Why wrong: FCI provides high availability at the instance level using shared storage, but it does not support synchronous replication or read-only secondary replicas for reporting.

Azure Site Recovery

Why wrong: Azure Site Recovery is a disaster recovery solution that replicates VMs across regions. It is not designed for high availability within a single region and does not guarantee zero data loss.

Azure Backup

Why wrong: Azure Backup provides backup and restore capabilities but does not offer automatic failover or replication for high availability.

Azure Table Storage

Why wrong: Azure Table Storage is a NoSQL key-value store but does not support multi-region writes or latency SLAs at the 99th percentile.

Azure Redis Cache

Why wrong: Azure Redis Cache is an in-memory caching service, not a primary database for persistent data with multi-region writes.

Azure SQL Database

Why wrong: Azure SQL Database is a relational database; while it supports geo-replication, it is not a NoSQL service and its latency guarantees differ.

Azure SQL Database

Why wrong: Relational, not optimized for key-value.

Azure Table Storage

Why wrong: No multi-region writes, higher latency.

Azure Cache for Redis

Why wrong: Not a persistent data store.

Ultra Disk

Why wrong: Ultra Disk supports higher IOPS but is overkill and more expensive.

Standard SSD

Why wrong: Standard SSD does not meet the IOPS requirement.

Premium SSD (non-v2)

Why wrong: Premium SSD max IOPS is lower than 80,000 for most sizes.

Azure Database for PostgreSQL

Why wrong: Not a SQL Server migration target.

SQL Server on Azure Virtual Machines with Always On availability groups

Why wrong: Requires manual setup and management.

Azure SQL Managed Instance with failover groups

Why wrong: Failover groups provide automated failover but are not as seamless as active geo-replication.

Long-term retention (LTR) backups

Why wrong: LTR is for backup retention, not high availability.

Automatic tuning

Why wrong: Automatic tuning is for performance optimization, not high availability.

Transparent Data Encryption (TDE)

Why wrong: TDE is for encryption at rest, not high availability.

SQL Server on Azure Virtual Machines

Why wrong: VMs require manual patching and backups, increasing administrative overhead.

Azure SQL Database Hyperscale

Why wrong: Hyperscale is for large databases with fast scaling, not specifically for minimal admin overhead.

Azure SQL Database (single database)

Why wrong: Single database is also managed but may not support all SQL Server features needed.

Premium tier.

Why wrong: Designed for low-latency, high-performance, not cost-effective.

Archive tier.

Why wrong: Retrieval time is hours, not minutes.

Hot tier.

Why wrong: Higher cost for infrequent access.

Azure Cosmos DB with SQL API

Why wrong: Does not fully support ACID transactions for complex queries.

Azure Database for PostgreSQL - Hyperscale (Citus)

Why wrong: Not designed for Oracle migration.

Enable read scale-out to distribute read queries to a secondary replica.

Why wrong: Read scale-out improves performance, not availability.

Use Azure Backup to copy database backups to another region.

Why wrong: Backup is for point-in-time restore, not HA.

Configure auto-failover groups with a secondary in another region.

Why wrong: This is a disaster recovery strategy, not high availability (HA). HA typically refers to within-region.

Configure Azure Site Recovery to replicate VMs to a paired region

Why wrong: This is for cross-region DR, not intra-region HA.

Use Azure Site Recovery to replicate VMs across availability sets

Why wrong: Site Recovery does not replicate across availability sets; availability sets provide fault tolerance within a datacenter.

Configure Azure Site Recovery to replicate VMs to different availability zones within the same region

Why wrong: Site Recovery is not designed for intra-region replication; it is for cross-region DR.

Enable automatic failover from a single write region to a read region

Why wrong: This can have RPO up to 15 minutes.

Deploy Cosmos DB in an availability zone-enabled region

Why wrong: This protects within a region, not cross-region.

Use manual failover to a secondary read region

Why wrong: Manual failover has higher RTO.

Use Azure Storage geo-redundant storage (GRS) for the VM's managed disks.

Why wrong: Storage replication does not ensure database consistency.

Deploy the VM in an Availability Set and use SQL Server Always On Availability Groups.

Why wrong: Availability Set does not protect against region failure; RPO may be higher.

Configure Azure Backup for the VM with application-consistent backups every 5 minutes.

Why wrong: Azure Backup cannot achieve 5-second RPO and 15-minute RTO.

Use Cosmos DB with geo-redundant storage and deploy a single AKS cluster with Azure Site Recovery.

Why wrong: Azure Site Recovery requires manual failover and is complex for AKS.

Deploy AKS clusters in two regions with Azure Traffic Manager and use Cosmos DB single-region writes with async replication.

Why wrong: Asynchronous replication may cause data loss during failover.

Deploy the application to a single region and use Azure Backup for Cosmos DB to restore in another region.

Why wrong: Backup restore has high RTO and does not meet availability requirements.