Azure is the second-largest cloud platform and the default choice for many enterprises, especially those with Microsoft investments. If you're interviewing for a role at a company using .NET, Office 365, or any Microsoft stack, expect Azure questions.
Azure interviews test both general cloud knowledge and Microsoft-specific patterns. You need to understand Azure AD (identity is central to everything), ARM (how Azure manages resources), and the core compute, storage, and networking services.
This guide covers the Azure services that appear in nearly every interview, the concepts you need to understand deeply, and the questions interviewers actually ask.
Azure Fundamentals
Before diving into services, understand how Azure organizes resources.
Resource Hierarchy
Azure has a specific hierarchy for organizing and managing resources:
Tenant (Azure AD)
└── Management Groups (optional)
└── Subscriptions
└── Resource Groups
└── Resources
Tenant: Your organization's instance of Azure AD. One tenant can have multiple subscriptions.
Management Groups: Optional containers for organizing subscriptions. Apply policies and RBAC at scale.
Subscription: A billing and access boundary. Resources in different subscriptions are isolated by default.
Resource Group: A logical container for resources that share the same lifecycle. All resources must belong to exactly one resource group.
Interview question: "What happens when you delete a Resource Group?"
All resources in the group are deleted. Resource Groups are lifecycle containers—they're meant to hold resources that should be created and deleted together. Be careful with production Resource Groups.
Regions and Availability Zones
Region: A geographic area containing one or more data centers (e.g., East US, West Europe). Choose regions based on latency, compliance, and service availability.
Availability Zone: Physically separate data centers within a region with independent power, cooling, and networking. Not all regions have AZs.
Paired Regions: Each region is paired with another for disaster recovery. Some services replicate automatically to the paired region.
| Region | Paired Region |
|---|---|
| East US | West US |
| West Europe | North Europe |
| Southeast Asia | East Asia |
Interview question: "How do you achieve high availability in Azure?"
Deploy across multiple Availability Zones within a region for HA. For disaster recovery, replicate to a paired region. Use zone-redundant services where available (Zone-Redundant Storage, zone-redundant AKS).
Azure Resource Manager (ARM)
ARM is the deployment and management layer for Azure. Every Azure operation goes through ARM.
Key concepts:
- All API calls (Portal, CLI, PowerShell, SDK) go through ARM
- ARM authenticates and authorizes requests via Azure AD
- Declarative deployments via ARM templates (JSON) or Bicep
ARM Templates: Infrastructure as code in JSON format.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources": [{
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2021-02-01",
"name": "mystorageaccount",
"location": "[resourceGroup().location]",
"sku": {"name": "Standard_LRS"},
"kind": "StorageV2"
}]
}Bicep: A cleaner DSL that compiles to ARM templates.
resource storage 'Microsoft.Storage/storageAccounts@2021-02-01' = {
name: 'mystorageaccount'
location: resourceGroup().location
sku: { name: 'Standard_LRS' }
kind: 'StorageV2'
}Interview tip: Know that Bicep exists and is Microsoft's recommended approach for new IaC. It's simpler than raw ARM JSON.
Compute: VMs, App Service, and Functions
Azure offers multiple compute options. Know when to use each.
Virtual Machines
Azure VMs provide full control over the operating system. Key concepts:
VM Sizes: Named by series and size (e.g., Standard_D4s_v3).
| Series | Use Case | Characteristics |
|---|---|---|
| B | Burstable | Variable workloads, cost-effective |
| D | General purpose | Balanced CPU/memory |
| E | Memory optimized | High memory-to-CPU ratio |
| F | Compute optimized | High CPU-to-memory ratio |
| N | GPU | ML training, graphics |
| L | Storage optimized | High disk throughput |
Availability Sets: Distribute VMs across fault domains (racks) and update domains. Protects against hardware failures and planned maintenance. 99.95% SLA.
Availability Zones: Distribute VMs across physically separate data centers. Higher availability than Availability Sets. 99.99% SLA.
VM Scale Sets: Auto-scaling groups of identical VMs. Define scaling rules based on metrics.
Interview question: "When would you use an Availability Set vs Availability Zones?"
Availability Zones provide higher availability (separate data centers) but not all regions support them. Availability Sets work in all regions and protect against rack-level failures. Use Zones when available for production; Sets as fallback or for legacy workloads.
App Service
App Service is a fully managed platform for web apps, APIs, and mobile backends.
App Service Plans: The compute resources your apps run on.
| Tier | Features |
|---|---|
| Free/Shared | Development, shared infrastructure |
| Basic | Dedicated compute, manual scaling |
| Standard | Auto-scale, staging slots, daily backups |
| Premium | More instances, more storage, better performance |
| Isolated | VNet integration, dedicated environment |
Key features:
- Deployment slots: Staging environments with swap capability
- Auto-scaling: Scale based on metrics or schedule
- Custom domains and SSL: Built-in certificate management
- Managed identity: Secure access to Azure services
Interview question: "How do you achieve zero-downtime deployments in App Service?"
Use deployment slots. Deploy to a staging slot, warm it up, then swap with production. The swap is instant (just a DNS/routing change). If issues occur, swap back immediately.
Azure Functions
Functions is Azure's serverless compute platform. Event-driven, pay-per-execution.
Hosting plans:
| Plan | Scaling | Timeout | Use Case |
|---|---|---|---|
| Consumption | Auto (0 to many) | 5-10 min | Sporadic, unpredictable workloads |
| Premium | Pre-warmed instances | 60 min | Avoid cold starts, VNet needed |
| Dedicated | App Service Plan | Unlimited | Existing App Service, predictable load |
Triggers: What starts a function execution.
- HTTP, Timer, Blob storage, Queue, Event Hub, Cosmos DB, etc.
Bindings: Declarative connections to data sources (input/output).
[FunctionName("ProcessOrder")]
public static void Run(
[QueueTrigger("orders")] Order order,
[CosmosDB("db", "processed")] out dynamic document)
{
document = new { id = order.Id, processed = DateTime.UtcNow };
}Compute Decision Tree
Need full OS control?
├── Yes → Virtual Machine
└── No
└── Container workload?
├── Yes → AKS (orchestration) or Container Apps (simpler)
└── No
└── Event-driven, short tasks?
├── Yes → Azure Functions
└── No → App Service
Identity: Azure AD (Entra ID)
Identity is central to Azure. Almost everything authenticates through Azure AD.
Azure AD vs Traditional AD
| Feature | Traditional AD | Azure AD |
|---|---|---|
| Location | On-premises | Cloud |
| Protocols | LDAP, Kerberos | OAuth 2.0, SAML, OIDC |
| Structure | OUs, GPOs, domain-joined | Flat, no GPOs |
| Use case | Domain-joined machines | Cloud/SaaS apps |
Azure AD is not AD in the cloud. It's a different service designed for modern authentication patterns. You can sync on-premises AD to Azure AD using Azure AD Connect.
Service Principals and Managed Identities
Service Principal: An identity for an application or service. Like a user account but for apps.
Managed Identity: Azure-managed service principal. No credentials to manage—Azure handles rotation.
| Type | Lifecycle | Sharing |
|---|---|---|
| System-assigned | Tied to resource | Cannot share |
| User-assigned | Independent | Can share across resources |
Interview question: "How should an Azure Function access Key Vault?"
Use a Managed Identity. Enable system-assigned identity on the Function, grant it access to Key Vault secrets via RBAC or access policy. No credentials in code—just reference the Key Vault in configuration.
// No credentials needed - uses Managed Identity
var client = new SecretClient(
new Uri("https://myvault.vault.azure.net/"),
new DefaultAzureCredential());RBAC (Role-Based Access Control)
Azure RBAC controls who can do what on which resources.
Components:
- Security principal: Who (user, group, service principal, managed identity)
- Role definition: What they can do (Reader, Contributor, Owner, custom)
- Scope: Where (management group, subscription, resource group, resource)
Built-in roles:
| Role | Permissions |
|---|---|
| Owner | Full access, can assign roles |
| Contributor | Full access, cannot assign roles |
| Reader | View only |
| User Access Administrator | Manage user access only |
Custom roles: Define your own permissions when built-in roles don't fit.
Interview question: "A developer needs to deploy to App Service but shouldn't access production databases. How?"
Create a custom role or use built-in "Website Contributor" role scoped to the App Service resource group. Don't grant access at subscription level. Principle of least privilege.
Conditional Access
Conditional Access policies add conditions to authentication:
- Require MFA for specific apps
- Block access from certain locations
- Require compliant devices
- Force password change for risky sign-ins
Interview tip: Know that Conditional Access exists and enables zero-trust patterns. It's a premium Azure AD feature.
Networking: VNet
Virtual Networks (VNets) are the foundation of Azure networking. Every VM, App Service (isolated tier), and AKS cluster runs inside a VNet.
VNet Components
VNet: Your isolated network in Azure. Define address space (CIDR blocks).
Subnet: A range within your VNet. Resources deploy into subnets.
Network Security Group (NSG): Stateful firewall rules at subnet or NIC level. Allow/deny based on source, destination, port, protocol.
VNet: 10.0.0.0/16
├── Subnet: web-tier (10.0.1.0/24)
│ └── NSG: allow 80, 443 from internet
├── Subnet: app-tier (10.0.2.0/24)
│ └── NSG: allow from web-tier only
└── Subnet: data-tier (10.0.3.0/24)
└── NSG: allow from app-tier only
NSG vs Azure Firewall
| Feature | NSG | Azure Firewall |
|---|---|---|
| Cost | Free | Paid service |
| Layer | L3/L4 (IP, port) | L3-L7 (application aware) |
| Scope | Subnet/NIC | Centralized |
| Features | Basic allow/deny | FQDN filtering, threat intel, logging |
| Use case | Microsegmentation | Enterprise perimeter security |
Interview question: "When would you use Azure Firewall over NSGs?"
When you need centralized logging, FQDN filtering (allow *.microsoft.com), threat intelligence, or application-layer inspection. NSGs are sufficient for basic network segmentation; Azure Firewall adds enterprise security features.
Connectivity Options
| Method | Use Case |
|---|---|
| VNet Peering | Connect VNets (same or different regions/subscriptions) |
| VPN Gateway | Encrypted connection over internet to on-premises |
| ExpressRoute | Private dedicated connection to on-premises |
| Private Endpoint | Access Azure PaaS services over private IP |
| Service Endpoint | Optimized route to Azure services (still public IP) |
Private Endpoints vs Service Endpoints
Service Endpoints: Enable a direct route from your VNet to Azure services. Traffic stays on Azure backbone, but the service still has a public endpoint.
Private Endpoints: Create a private IP in your VNet for the Azure service. The service is accessible only via that private IP. More secure but more complex.
Interview question: "How do you ensure traffic to Azure SQL never goes over the public internet?"
Use Private Endpoint. It creates a private IP in your VNet for the SQL server. Disable public network access on the SQL server. Traffic between your VNet and SQL stays entirely within Azure's network.
Storage and Databases
Azure offers multiple storage and database options. Know the right tool for each use case.
Storage Accounts
A storage account provides access to Azure Storage services:
| Service | Type | Use Case |
|---|---|---|
| Blob Storage | Object storage | Unstructured data, images, backups |
| File Storage | SMB file shares | Lift-and-shift, shared storage |
| Queue Storage | Message queuing | Decoupling components |
| Table Storage | NoSQL key-value | Simple structured data (consider Cosmos DB) |
Blob Access Tiers:
| Tier | Access | Cost Pattern |
|---|---|---|
| Hot | Frequent | Higher storage, lower access |
| Cool | Infrequent (30+ days) | Lower storage, higher access |
| Archive | Rare (180+ days) | Lowest storage, rehydration required |
Redundancy Options:
| Option | Description | Durability |
|---|---|---|
| LRS | 3 copies in one data center | 11 nines |
| ZRS | 3 copies across AZs | 12 nines |
| GRS | LRS + async copy to paired region | 16 nines |
| GZRS | ZRS + async copy to paired region | 16 nines |
Cosmos DB
Cosmos DB is Azure's globally distributed, multi-model NoSQL database.
Key features:
- Global distribution: Multi-region writes, automatic failover
- Multiple APIs: SQL, MongoDB, Cassandra, Gremlin, Table
- Tunable consistency: Five consistency levels
Consistency Levels (strongest to weakest):
| Level | Guarantee | Latency |
|---|---|---|
| Strong | Linearizable (latest write) | Highest |
| Bounded Staleness | Consistent within K versions or T time | High |
| Session | Consistent within session | Medium (default) |
| Consistent Prefix | Reads never see out-of-order writes | Low |
| Eventual | No ordering guarantee | Lowest |
Interview question: "When would you choose Strong consistency in Cosmos DB?"
When you absolutely cannot read stale data—financial transactions, inventory systems where overselling is costly. Strong consistency limits you to single-region writes and adds latency. Most applications work fine with Session consistency (default).
Partitioning: Choose a partition key that distributes data evenly and matches your query patterns. Bad partition key = hot partitions = throttling.
Azure SQL
Azure SQL is managed SQL Server. Options:
| Option | Description |
|---|---|
| Azure SQL Database | Single database, fully managed |
| Elastic Pool | Multiple databases sharing resources |
| SQL Managed Instance | Near 100% SQL Server compatibility |
Interview question: "When would you use SQL Managed Instance over Azure SQL Database?"
When you need features only in full SQL Server: cross-database queries, SQL Agent, CLR, Service Broker. Managed Instance provides near-complete SQL Server compatibility for lift-and-shift migrations.
SQL vs Cosmos DB Decision
| Factor | Azure SQL | Cosmos DB |
|---|---|---|
| Data model | Relational, joins | Document, key-value |
| Schema | Fixed | Flexible |
| Scaling | Vertical (mostly) | Horizontal (unlimited) |
| Consistency | Strong (ACID) | Tunable |
| Global distribution | Geo-replication | Multi-region writes |
| Best for | Transactional, complex queries | Scale, global apps, flexible schema |
Containers: AKS
Azure Kubernetes Service (AKS) is managed Kubernetes. Azure handles the control plane; you manage worker nodes.
AKS Basics
What Azure manages:
- Control plane (API server, etcd, scheduler, controller manager)
- Upgrades and patching (optional for nodes)
- Integration with Azure AD, networking, monitoring
What you manage:
- Worker nodes (VM scale sets)
- Application deployments
- Node pool configuration
Node Pools: Groups of nodes with the same configuration. Use multiple pools for different workload types.
AKS Cluster
├── System Node Pool (Linux, runs system pods)
├── User Node Pool 1 (Linux, general workloads)
└── User Node Pool 2 (Windows, .NET apps)
AKS Networking
Kubenet: Simple networking. Nodes get Azure VNet IPs; pods get IPs from a different range with NAT.
Azure CNI: Pods get IPs directly from the Azure VNet subnet. Required for Windows nodes, VNet integration.
| Feature | Kubenet | Azure CNI |
|---|---|---|
| Pod IPs | NAT'd behind node | Direct VNet IPs |
| IP consumption | Efficient | Requires large subnet |
| Windows support | No | Yes |
| Network policies | Calico only | Azure or Calico |
Azure Container Registry (ACR)
ACR is a managed Docker registry.
Key features:
- Private registry for container images
- Geo-replication for global deployments
- Integration with AKS (managed identity authentication)
- Tasks for automated builds
Interview question: "How do you securely pull images from ACR to AKS?"
Attach ACR to AKS using managed identity. Run az aks update --attach-acr <acr-name>. AKS gets AcrPull role automatically. No image pull secrets needed.
AKS vs Other Compute Options
Need Kubernetes features (pods, services, deployments)?
├── Yes
│ └── Want to manage control plane?
│ ├── Yes → Self-managed K8s on VMs
│ └── No → AKS
└── No
└── Just need to run containers?
├── Yes, simple workloads → Container Apps or Container Instances
└── No → App Service or Functions
Common Interview Questions
Service Comparison (Azure vs AWS)
| Azure | AWS | Purpose |
|---|---|---|
| Virtual Machines | EC2 | Compute |
| App Service | Elastic Beanstalk | PaaS web hosting |
| Azure Functions | Lambda | Serverless compute |
| Blob Storage | S3 | Object storage |
| Azure SQL | RDS | Managed relational DB |
| Cosmos DB | DynamoDB | NoSQL |
| VNet | VPC | Virtual networking |
| Azure AD | IAM + Cognito | Identity |
| AKS | EKS | Managed Kubernetes |
| Azure DevOps | CodePipeline + CodeBuild | CI/CD |
Architecture Scenarios
Q: Design a highly available web application on Azure.
A:
- Deploy App Service in multiple regions or VMs across Availability Zones
- Azure Front Door or Traffic Manager for global load balancing
- Azure SQL with geo-replication or Cosmos DB for database
- Blob Storage for static assets, CDN for caching
- Azure AD for authentication
- Key Vault for secrets, Managed Identity for access
- Application Insights for monitoring
Q: How would you migrate an on-premises .NET application to Azure?
A:
- Assess: Use Azure Migrate to discover dependencies
- Choose target: App Service (easiest), AKS (containers), or VMs (lift-and-shift)
- Database: Azure SQL Managed Instance for compatibility or Azure SQL Database
- Identity: Azure AD Connect to sync on-premises AD
- Networking: VPN or ExpressRoute for hybrid connectivity
- Migration: Use Azure Site Recovery for VMs or deploy directly for App Service
Q: A container application needs to access Azure SQL and Key Vault securely. Design this.
A:
- Deploy to AKS with Azure CNI networking
- Enable Managed Identity on AKS (workload identity)
- Grant identity access to Key Vault and SQL via RBAC
- Use Private Endpoints for SQL and Key Vault
- Application uses DefaultAzureCredential—no secrets in code or config
Troubleshooting Questions
Q: VM can't connect to Azure SQL Database. What do you check?
A:
- SQL Server firewall: Is client IP or VNet allowed?
- NSG on VM subnet: Outbound to SQL port 1433 allowed?
- Private Endpoint configured? Check private DNS resolution
- Connection string correct? Server name, database, authentication
- SQL authentication enabled if using SQL auth?
Q: App Service can't access Key Vault. Why?
A:
- Managed Identity enabled on App Service?
- Access policy or RBAC role assigned to the identity?
- Correct Key Vault URI in app configuration?
- If using Private Endpoint, is VNet integration configured on App Service?
- Key Vault firewall blocking access?
Q: AKS pods are stuck in Pending state. What do you check?
A:
- Node resources: Is there enough CPU/memory? (
kubectl describe node) - Node pool scaling: Are nodes available or scaling?
- Taints and tolerations: Does pod tolerate node taints?
- Node selectors: Does pod's nodeSelector match any nodes?
- PVC issues: Is persistent volume claim bound?
Quick Reference
Resource Hierarchy: Tenant → Management Groups → Subscriptions → Resource Groups → Resources
Compute:
- VMs: Full control, IaaS
- App Service: Managed web hosting, PaaS
- Functions: Serverless, event-driven
- AKS: Managed Kubernetes
Identity:
- Azure AD: Cloud identity platform
- Managed Identity: No credentials in code
- RBAC: Role-based access control
Networking:
- VNet: Virtual network
- NSG: Stateful firewall (free)
- Azure Firewall: Enterprise firewall (paid)
- Private Endpoint: Private IP for PaaS services
Storage/Database:
- Blob: Object storage
- Azure SQL: Managed SQL Server
- Cosmos DB: Global NoSQL, tunable consistency
Related Articles
If you found this helpful, explore our other cloud and DevOps guides:
- Complete DevOps Engineer Interview Guide - Full DevOps interview preparation
- AWS Interview Guide - AWS core services comparison
- Kubernetes Interview Guide - Container orchestration fundamentals
- Docker Interview Guide - Container basics
- Monitoring & Observability Interview Guide - Azure Monitor and beyond
What's Next?
Azure interviews reward understanding of how services integrate. It's not enough to know what App Service does—you need to know how it connects to Azure AD, Key Vault, and SQL Database securely.
Start with identity (Azure AD) and networking (VNets)—they're the foundation everything else builds on. Then learn the core compute and storage services. Get hands-on: deploy an App Service with Managed Identity accessing Key Vault. Set up a VNet with proper subnets and NSGs.
If you're coming from AWS, focus on the differences: Azure AD is more central than IAM, ARM templates work differently than CloudFormation, and Azure's naming conventions take adjustment.
