Azure Interview Questions and Answers (2026)

Azure interview questions usually test whether you can reason about the tradeoffs between services — App Service vs Functions vs Container Apps, Storage Queues vs Service Bus — not just recall feature lists. Here are the Azure questions that come up most often.

1. When would you choose App Service, Azure Functions, or Container Apps for a new workload?

   App Service is the default for long-running web apps and APIs with predictable traffic — it gives you a managed VM-based platform with easy deployment slots, custom domains, and built-in scaling, but you pay for the plan even when idle. Azure Functions fits event-driven, short-lived work (HTTP triggers, queue processing, timers) where you want consumption-based billing and scale-to-zero; it's wrong for long-running processes (>10 min on Consumption) or workloads needing full control over the runtime. Container Apps sits between them: it's for microservices that need Kubernetes-like features (KEDA-based scaling, Dapr, revisions, traffic splitting) without managing AKS directly. If you need full control of the orchestration layer, custom CNI, or complex networking, go straight to AKS instead of Container Apps.

2. What's the difference between vertical and horizontal scaling, and how do autoscale rules work in Azure?

   Vertical scaling (scale up/down) changes the size of an instance — e.g., moving an App Service plan from B1 to P1v3 for more CPU/RAM; it requires a restart and has a ceiling. Horizontal scaling (scale out/in) adds or removes instances behind the load balancer, which improves both capacity and availability with no downtime. Azure Autoscale defines rules based on metrics (CPU %, memory, queue length, HTTP queue length) with thresholds, cooldown periods, and min/max instance counts. Example rule logic: scale out by 1 instance when average CPU > 70% for 10 minutes, scale in by 1 when CPU < 30% for 10 minutes, min 2 / max 10 instances. Horizontal scaling is generally preferred for stateless web tiers because it also improves resilience.

3. What is Azure AD / Entra ID, and how does it differ from traditional Active Directory?

   Entra ID (formerly Azure AD) is Microsoft's cloud-native identity platform, providing authentication and authorization via open standards like OAuth 2.0, OIDC, and SAML rather than Kerberos/NTLM and LDAP used by on-prem AD. It's not a domain controller replacement — you can't join a Windows machine to Entra ID with GPOs the way you would on-prem AD (Entra ID join is different and lighter-weight, focused on app SSO and MDM). Key building blocks: tenants (isolated directory instances), app registrations (represent an application's identity), service principals (the tenant-local instance of an app), and enterprise applications. Entra ID also handles conditional access, MFA, and B2B/B2C guest access. Hybrid setups sync on-prem AD to Entra ID via Azure AD Connect for a unified identity.

4. What is Azure Key Vault used for, and what are the main object types it stores?

   Key Vault is a managed secrets store for centralizing sensitive configuration outside of application code and config files. It holds three object types: secrets (arbitrary strings like connection strings or API keys), keys (cryptographic keys for encrypt/decrypt/sign operations, optionally backed by HSMs), and certificates (with automated renewal support). Applications should access Key Vault using managed identities rather than embedded credentials, and access is governed either by legacy access policies or, preferably, Azure RBAC roles like Key Vault Secrets User. A common pattern is referencing Key Vault secrets directly in App Service application settings: @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/DbPassword/). Key Vault also provides audit logging via diagnostic settings and soft-delete/purge protection to prevent accidental permanent loss.

5. How do ARM templates or Bicep compare to manually configuring resources in the portal?

   Manual portal configuration is fast for prototyping but not repeatable, not version-controlled, and prone to configuration drift between environments. ARM templates (JSON) and Bicep (a cleaner DSL that compiles to ARM) let you define infrastructure declaratively, check it into source control, and deploy it consistently across dev/test/prod through idempotent deployments — running the same template twice converges to the same state rather than erroring or duplicating resources. Bicep is preferred over raw ARM JSON today because it's far less verbose and has better tooling (IntelliSense, modules, type checking). Example Bicep snippet:

   resource storage 'Microsoft.Storage/storageAccounts@2023-01-01' = {
     name: 'mystorageacct01'
     location: resourceGroup().location
     sku: { name: 'Standard_LRS' }
     kind: 'StorageV2'
   }

   This is the foundation of IaC practice and pairs naturally with CI/CD pipelines.

6. What are the four Azure Storage account data services and when would you use each?

   Blob storage is for unstructured data — images, videos, backups, log files, or data lake workloads — organized into containers with hot/cool/archive access tiers for cost control. Table storage is a NoSQL key-value store (partition key + row key) for simple, high-throughput structured data without complex query needs; Cosmos DB's Table API is the modern upgrade path. Queue storage provides simple, cheap, at-least-once message queuing between application components, good for basic decoupling but lacking advanced features like topics or ordering guarantees. File storage offers fully managed SMB/NFS file shares that can be mounted by VMs or on-prem servers via Azure File Sync, useful for lift-and-shift scenarios needing a shared file system. Choice usually comes down to data shape: blobs for objects, tables for simple structured records, queues for messaging, files for shared filesystem semantics.

7. Explain the basics of a VNet and NSG, and how they secure Azure resources.

   A Virtual Network (VNet) is a logically isolated network in Azure where you define IP address ranges and subnets to segment resources — for example, separating a web tier subnet from a database tier subnet. Resources within a VNet (or peered VNets) communicate privately without traversing the public internet. A Network Security Group (NSG) acts as a stateful firewall applied to a subnet or NIC, with ordered allow/deny rules based on source/destination IP, port, and protocol — lower priority numbers are evaluated first. A typical pattern is denying all inbound traffic by default and explicitly allowing only required ports, e.g., allow 443 from an Application Gateway subnet, deny everything else inbound from the internet. VNets combined with private endpoints let you fully remove PaaS services like SQL or Key Vault from public exposure.

8. What is a managed identity and why is it preferred over storing credentials in code or config?

   A managed identity is an Azure AD identity automatically managed by the platform for a resource (like an App Service or VM), letting it authenticate to other Azure services (Key Vault, Storage, SQL) without any stored secret or connection string. There are two types: system-assigned, tied to the lifecycle of a single resource and deleted when the resource is, and user-assigned, created independently and shared across multiple resources. Because there's no credential to leak, rotate, or accidentally commit to source control, managed identities eliminate an entire class of secret-sprawl risk. In practice, you grant the identity's principal an RBAC role on the target resource, then the app uses DefaultAzureCredential (in the Azure SDK) to acquire tokens transparently — no code changes needed between local dev (using your Azure CLI login) and production (using the managed identity).

9. When would you use Azure Service Bus instead of Storage Queues?

   Storage Queues are simple, cheap, and good enough for basic decoupling of two components with at-least-once delivery and 64KB messages. Service Bus is the enterprise messaging option: it supports topics/subscriptions for pub-sub fan-out, FIFO ordering via sessions, transactions, dead-lettering, duplicate detection, and larger message sizes (up to 256KB/1MB depending on tier). Choose Service Bus when you need guaranteed ordering, multiple independent consumers of the same message stream, or advanced patterns like request-reply and scheduled delivery. Choose Storage Queues when you just need a cheap, simple buffer between a producer and a single consumer type, such as decoupling a web app from a background Function that processes uploaded files, and you don't need the extra features. Cost and simplicity favor Storage Queues; feature richness favors Service Bus.

10. What's the difference between availability zones and regions, and how do they affect resiliency design?

    A region is a geographic area containing one or more datacenters (e.g., East US). Availability Zones are physically separate datacenters within the same region, each with independent power, cooling, and networking, connected by low-latency links — deploying across zones protects against a single datacenter failure while keeping latency low. Deploying across regions (e.g., East US and West US paired via Azure's region-pair mechanism) protects against a regional-scale disaster but introduces higher replication latency and complexity (data residency, failover orchestration). A resilient design typically uses zone-redundant SKUs (zone-redundant Storage, zone-redundant App Service/SQL) for high availability within a region, and adds cross-region replication/failover (like SQL geo-replication or Front Door with multiple backends) only when the business truly needs disaster recovery from a full regional outage.

11. What's the difference between Azure Monitor and Application Insights, and what would you use each for?

    Azure Monitor is the umbrella platform that collects metrics, logs, and activity data across all Azure resources — it includes Log Analytics (a Kusto Query Language store for logs/metrics) and Alerts. Application Insights is Azure Monitor's Application Performance Management (APM) component, specifically instrumented into your application code (via SDK or auto-instrumentation) to capture request rates, response times, dependency calls, exceptions, and distributed traces. In practice you use Application Insights for "why is this specific API call slow" and Azure Monitor/Log Analytics for infrastructure-level questions like CPU trends or resource health. A common KQL query in Log Analytics: requests | where duration > 2000 | summarize count() by bin(timestamp, 1h) to find slow-request spikes over time. Alerts can be configured on either layer to page on-call engineers.

12. What are the main levers for controlling Azure cost?

    Right-sizing is first — matching SKU/tier to actual usage rather than over-provisioning "just in case," verified with Azure Advisor recommendations. Reserved Instances or Savings Plans give 30-60% discounts over pay-as-you-go for predictable, always-on workloads (1 or 3-year commitment), while Spot VMs offer deep discounts for interruptible batch workloads. Autoscaling avoids paying for peak capacity 24/7. Storage tiering (hot/cool/archive for Blob) cuts costs for infrequently accessed data. Turning off or deallocating non-production resources outside business hours (e.g., via Automation runbooks or Azure Dev/Test pricing) is a common quick win. Azure Cost Management + Budgets gives visibility and can trigger alerts at spend thresholds. Finally, choosing the right service tier (e.g., Functions Consumption vs Premium) and consolidating underutilized resources (like merging multiple low-traffic App Service plans) directly reduces waste.

More prep guides on the AI Interview Bot blog.