Interview Preparation

IaaS (VMs, VMSS): You manage OS, runtime, app. Azure manages hardware. PaaS (App Service, Azure SQL): You manage only the app/data. Azure manages OS, patching, scaling. SaaS: You configure only. Example: Microsoft 365.

A logical container grouping related Azure resources for a solution. Resources in a group share lifecycle — you can deploy, update, or delete them together. Also the unit for access control and billing tracking.

Any unstructured data: images, videos, documents, backups, log files, static web assets. Blob Storage is object storage — no filesystem semantics, just container → blob hierarchy.

A fully managed PaaS for hosting web apps and REST APIs. Supports Node.js, .NET, Python, PHP, Java, Ruby. Azure manages infrastructure, OS patching, scaling. You deploy code and configure settings.

A Shared Access Signature — a time-limited, permission-scoped signed URL for accessing Azure Storage resources without sharing account keys. You can scope to read, write, delete; and set an expiry time.

Azure SQL Database (managed relational SQL), Cosmos DB (globally distributed NoSQL), Azure Database for PostgreSQL (managed open-source relational). Also: SQL Managed Instance, Azure DB for MySQL.

When the app has OS-level requirements that PaaS can't satisfy: specific OS version, custom kernel modules, COM components, software that needs system daemons or registry access. Otherwise, App Service is almost always better — no OS patching, built-in scaling, lower TCO.

Hot: frequently accessed, highest storage cost, lowest retrieval cost. Cool: infrequently accessed (30+ days), lower storage, higher retrieval. Archive: long-term retention (180+ days), cheapest storage, highest retrieval (several hours to rehydrate). Use lifecycle policies to automate tier transitions.

A live environment (e.g., staging) alongside production. Deploy new code to staging, test, then swap to production with zero downtime. The old production becomes staging for instant rollback.

DTU: blended CPU/memory/IO unit, simpler to choose but less transparent. vCore: individual CPU cores + RAM, more predictable, eligible for Azure Hybrid Benefit (bring your own SQL Server license, save up to 55%). Use vCore for production with existing MS licensing; DTU for simple new apps.

How many copies Azure keeps and where. LRS: 3 copies, 1 datacenter. ZRS: 3 zones in one region. GRS: LRS + async replica to paired region. RA-GRS: GRS + read access to secondary. GZRS: ZRS + geo-replication. Production: minimum ZRS; critical data: GRS or RA-GRS.

On Consumption plan, if a function hasn't run recently, Azure provisions a new container from scratch — adding 1-3 seconds to the first invocation. Solved by: Premium plan (pre-warmed instances), App Service plan, or a Timer trigger pinging the function to keep it warm.

The partition key determines how data is physically distributed across partitions. Good partition key: high cardinality, even distribution of reads/writes. Bad key: "hot partition" — all traffic hits 1 partition, throttling everything else even if total provisioned RU/s is sufficient. userId, deviceId, and orderId are usually good choices; status codes (active/inactive) are terrible.

Frontend: React SPA on Azure Static Web Apps / Blob Storage + CDN for global edge caching.

API: App Service (Premium P2v3) with auto-scale. Deployment slots for zero-downtime deploys.

Database: Azure SQL Database (Business Critical) for orders/users. Cosmos DB for product catalog (schema flexibility, global reads, scales to flash-sale burst without DTU limits).

Cache: Azure Cache for Redis in front of the product catalog.

Background jobs: Azure Functions for order confirmations, inventory updates.

Assets: Blob Storage (Hot tier) + CDN for product images.

SQL Managed Instance. It's the only Azure managed SQL service with near-100% feature compatibility including SQL Agent, CLR, linked servers, and cross-database queries. Azure SQL Database would require removing all those features, which is a large migration effort. SQL MI is deployed inside a VNet, so network path from app servers is also secure.

1. API generates a SAS write URL for the user to upload directly to Blob Storage (bypasses API server).

2. Blob Storage triggers an Azure Function on new blob creation in the uploads container.

3. Function generates thumbnail, stores it in thumbnails container, writes a Queue message with the result.

4. API polls the queue or client uses WebSocket/SSE for real-time notification.

API response: 202 Accepted with a job ID. Client polls GET /jobs/{id} to check completion status stored in Azure SQL or Cosmos DB.

1. Deallocate unused VMs — stopped VMs still bill for compute. Deallocate dev/test VMs outside working hours with Azure Automation or auto-shutdown.

2. Blob lifecycle policies — move old blobs to Cool/Archive. Archive is ~95% cheaper than Hot.

3. Right-size databases — check DTU/vCore utilization in Monitor. A database at 5% average can drop 2 tiers immediately.

Bonus: Use Reserved Instances for stable VMs (save 30-72%). Use Azure Hybrid Benefit for Windows/SQL licenses.

1. Check App Service Plan CPU and Memory metrics — plan may be hitting limits.

2. Check if auto-scale is configured and if it triggered. If not, is the plan tier low (Basic has no autoscale)?

3. Check application logs (log stream) for exceptions — could be a downstream timeout (DB, cache) causing requests to pile up.

4. Check the database connection pool — a saturated DB under load causes the API to queue requests until timeout.

Fix: Scale up the App Service Plan to Standard/Premium; enable autoscale; investigate DB bottleneck (DTU exhaustion, missing indexes).

Start with Azure Container Apps — it runs containers, provides KEDA-based auto-scale, Dapr for service-to-service communication, and handles ingress routing — all without Kubernetes knowledge. If the team later needs full Kubernetes control (custom CRDs, stateful workloads, service mesh), migrate to AKS. Don't start with AKS complexity unless you have a specific requirement that Container Apps can't fulfill.

This is a hot partition problem. Even if total RU/s is 10,000, if 80% of requests hit partition key value "active", that partition can only serve its share of the RUs. The fix: redesign the partition key to distribute traffic more evenly. For example, instead of /status (2 values), use /userId (millions of unique values). Each partition gets an equal slice of throughput.