Azure Interview Questions

A curated set of Azure interview questions, ordered roughly from fundamentals to more applied — the kind you'll actually be asked in real screens and on-sites.

Compute#

Q: When would you choose Azure App Service over a Virtual Machine, and when would you choose a container instead? Choose App Service when you're hosting a standard web app, REST API, or mobile backend and want Azure to manage the OS, patching, and scaling for you — it's the fastest path from code to a live URL. Choose a VM when you need full control over the operating system: specific drivers, a legacy application that assumes it owns the whole machine, or software that App Service simply can't run. Choose a container (Azure Container Instances for one isolated container, AKS for many coordinated ones) when your workload is already packaged as a container image, needs to run identically across environments, or is one service among several that need real orchestration — restarts, service discovery, rolling updates.

Q: What's the difference between Azure Container Instances (ACI) and Azure Kubernetes Service (AKS)? ACI runs a single container (or a small container group) with no cluster to manage, billed per second — it's the "serverless container" option, ideal for a short-lived job or one simple isolated service. AKS is a managed Kubernetes cluster for running many interdependent containerized services that need orchestration: automatic restarts, load balancing, service discovery, and coordinated rolling deployments. The rule of thumb is: reach for ACI for one container, reach for AKS once you have a system of containers that need to work together.

Q: What is an App Service Plan, and how does it relate to a Web App? The App Service Plan is the underlying compute tier that's actually billed — it defines how much CPU/memory you're paying for and at what pricing tier (Free, Basic, Standard, Premium). A Web App is the actual running application deployed on top of that plan, with its own URL and configuration. Multiple Web Apps can share one App Service Plan, in which case they share (and split) that plan's compute resources.

Organization and structure#

Q: What is the purpose of a resource group? A resource group is a logical container that groups Azure resources sharing the same application, environment, or lifecycle — for example, all the pieces of one web app (its App Service, its database, its storage account). It doesn't perform any function itself; its main practical value is that deleting the resource group deletes everything inside it in one action, which makes cleanup of test environments trivial and prevents orphaned resources from quietly accumulating cost.

Q: What's the difference between an Azure subscription and a resource group? A subscription is the billing and quota boundary — it's what an invoice is calculated against, and it's where hard service limits are enforced. A resource group is a much finer-grained organizational container that lives inside a subscription, grouping related resources together (often for one specific application or environment). One subscription commonly holds many resource groups.

Q: What's the difference between an Azure region and an availability zone? A region is a specific geographic area made up of one or more physical Microsoft datacenters (e.g., East US). An availability zone is a physically separate datacenter within a region, with independent power and networking — spreading resources across zones protects against a single datacenter failure taking down your whole application, whereas choosing a region primarily affects latency to your users, data residency requirements, and which specific services are available.

Storage and databases#

Q: What are the Azure Blob Storage access tiers, and how would you decide between them? Hot, Cool, Cold, and Archive — a spectrum trading storage cost against retrieval speed and minimum retention period. Hot is for data accessed frequently and costs the most to store but is instantly available; Cool and Cold suit progressively less-frequently-accessed data with minimum storage durations (30 and 90 days respectively) and small retrieval fees; Archive is the cheapest to store but can take hours to retrieve, since data must be explicitly "rehydrated" first. The decision comes down to how often the data is actually read: a photo no one has viewed in two years belongs in Cool or Archive, not Hot.

Q: When would you choose Azure SQL Database over Cosmos DB, or vice versa? Choose Azure SQL Database when your data is naturally relational — rows that relate to other rows, need joins, and require strong transactional consistency (orders, invoices, inventory). Choose Cosmos DB when you need massive scale, guaranteed low latency across multiple geographic regions, multi-region writes, or a schema flexible enough to evolve without a migration. In short: SQL Database is the default for structured transactional apps; Cosmos DB is the specialist tool for global scale and flexible-schema workloads.

Q: What's the hierarchy of a Blob Storage account, from top to bottom? Storage Account (the globally-unique-named top-level container and billing boundary) → Container (a logical grouping, similar to a folder) → Blob (the actual file). Blob storage's namespace is technically flat — nested "folders" seen in the portal are really just blob names containing / characters, simulated for display purposes.

Cross-cloud context#

Q: If you already know AWS, what are the rough Azure equivalents of EC2, S3, RDS, and Lambda? EC2 (AWS virtual machines) maps to Azure Virtual Machines. S3 (AWS object storage) maps to Azure Blob Storage. RDS (AWS managed relational databases) maps to Azure SQL Database (or Azure Database for PostgreSQL/MySQL). Lambda (AWS serverless functions) maps to Azure Functions. The concepts transfer almost one-to-one between providers — what changes is naming, specific configuration knobs, and pricing details, not the underlying architectural ideas.

Q: Why doesn't it make sense to compare cloud providers purely on price per service? Because the services aren't perfectly interchangeable in behavior, integration, or ecosystem — the real cost of a cloud choice includes engineering time, how well services integrate with each other, available managed tooling, regional availability, and existing team expertise, not just the sticker price of one VM size against another. A fair comparison has to be made at the level of "what does it cost to run this specific application reliably," not "what does one instance-hour cost."