Cloud & Platform Fundamentals

Question 1. What is the difference between a Region, an Availability Zone, and a Region Pair, and how do they affect high availability and disaster recovery?

Answer

A Region is a geographic area containing one or more datacenters (e.g. Central India). An Availability Zone (AZ) is a physically separate location within a region with independent power, cooling, and networking — zones protect you from datacenter-level failure. A Region Pair is two regions in the same geography (e.g. Central India ↔ South India) used for cross-region replication and coordinated platform updates. Use zone-redundant deployments (and ZRS storage) to survive a single datacenter outage with no data loss inside one region. Use a paired region for disaster recovery against a whole-region outage. Microsoft rolls out platform updates to one region in a pair at a time, reducing the blast radius of a bad update.

Analogy

A region is a city, an availability zone is a separate building in that city (lose one building, the others keep running), and a region pair is a sister city you can flee to if the whole city goes dark.

Question 2. Explain the Azure resource hierarchy and the role of Azure Resource Manager (ARM).

Answer

The hierarchy is Management Group → Subscription → Resource Group → Resource. Management

groups apply policy and access across many subscriptions; a subscription is a billing and isolation boundary; a resource group is a lifecycle and permission container for resources that share a fate (deploy/delete together).

ARM is the deployment and management control plane. Every request — portal, CLI, SDK, REST — goes through ARM, which handles authentication, RBAC, policy evaluation, and idempotent, dependency-ordered provisioning. This is why infrastructure-as-code (Bicep/ARM templates) is declarative and repeatable.

Analogy

Think of an org chart: management groups are the company divisions, subscriptions are departments with their own budgets, resource groups are project folders, and ARM is the front desk every request must pass through.

Question 3. Walk through the Azure Storage redundancy options. When would you choose each?

Answer

LRS keeps 3 copies in one datacenter — cheapest, protects only against disk/node failure. ZRS spreads 3 copies across availability zones in one region — survives a datacenter outage. GRS replicates to the paired region asynchronously (6 copies total) for regional disaster recovery, but the secondary is not readable until failover. RA-GRS adds read access to the secondary. GZRS combines zone redundancy in the primary with geo-replication; RA-GZRS also makes the secondary readable.

Pick LRS for easily-reconstructable or dev data, ZRS for production needing in-region resilience, and GZRS/RA-GZRS for critical data needing both zone resilience and regional DR. Geo-replication is asynchronous, so a regional failure can lose the last few seconds of writes.

Analogy

LRS is three copies of a document in one filing cabinet; ZRS is copies in three cabinets across the building; GRS adds a copy couriered nightly to another city (you can only read it if you fly there); RA-GZRS is the full fireproof, multi-city, always-readable setup.

Question 4. What is a composite SLA and why does it matter when designing a multi-service system?

Answer

A composite SLA is the combined availability of all services on a request's critical path. Availabilities multiply:

if your API depends on a 99.95% App Service and a 99.99% database and a 99.9% downstream call, the composite is roughly 0.9995 × 0.9999 × 0.999 ≈ 99.84% — lower than any single component. You raise the composite SLA by reducing serial dependencies, adding redundancy (so a component is in parallel rather than in series), and degrading gracefully (queues, caches, circuit breakers) so one slow dependency doesn't fail the whole request.

Example

Two components in series multiply; the same component duplicated in parallel improves availability: combined = 1 − (1 − 0.99)². A 99% service behind a load balancer with two instances trends toward 99.99%.

Analogy

A chain is only as strong as its weakest link, and adding more links in series only makes it weaker — redundancy is adding a second parallel chain so one snapping doesn't drop the load.

Question 5. Vertical vs horizontal scaling, and what does autoscale actually do?

Answer

Vertical (scale up/down) means a bigger or smaller instance (more CPU/RAM) — simple but capped by the largest SKU and usually requires a restart. Horizontal (scale out/in) means more or fewer identical instances behind a load balancer — near-limitless and the cloud-native default, but requires your app to be stateless. Autoscale adjusts instance count automatically against metrics (CPU, memory, queue length) or a schedule. Rules should scale out aggressively and scale in conservatively to avoid flapping, and you set min/max bounds to cap cost and guarantee a floor.

Analogy

Vertical scaling is upgrading to a bigger truck; horizontal scaling is sending more trucks. There's a limit to how big one truck can get, but you can almost always add another truck.

Question 6. Compare ARM templates, Bicep, and Terraform for infrastructure-as-code on Azure.

Answer

ARM templates are the native JSON format — verbose and hard to read but always current with new features. Bicep is Microsoft's domain-specific language that transpiles to ARM: far cleaner syntax, modules, type safety, and day-zero support for new resources, while staying Azure-only. Terraform is multi-cloud with a huge provider ecosystem and explicit state management (a state file you must store and lock, e.g. in a blob).

Choose Bicep for Azure-only shops wanting the best authoring experience and immediate feature support; choose Terraform when you span multiple clouds or already have Terraform expertise and tooling. Both are declarative and idempotent.

Analogy

ARM JSON is assembly language, Bicep is a high-level language that compiles to it, and Terraform is a cross-platform language that runs anywhere but needs you to manage its own memory (state).