Azure Interview Guide: Core Services Every Developer Should Know

·18 min read
devopsazurecloudmicrosoftinterview-preparation

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.

RegionPaired Region
East USWest US
West EuropeNorth Europe
Southeast AsiaEast 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).

SeriesUse CaseCharacteristics
BBurstableVariable workloads, cost-effective
DGeneral purposeBalanced CPU/memory
EMemory optimizedHigh memory-to-CPU ratio
FCompute optimizedHigh CPU-to-memory ratio
NGPUML training, graphics
LStorage optimizedHigh 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.

TierFeatures
Free/SharedDevelopment, shared infrastructure
BasicDedicated compute, manual scaling
StandardAuto-scale, staging slots, daily backups
PremiumMore instances, more storage, better performance
IsolatedVNet 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:

PlanScalingTimeoutUse Case
ConsumptionAuto (0 to many)5-10 minSporadic, unpredictable workloads
PremiumPre-warmed instances60 minAvoid cold starts, VNet needed
DedicatedApp Service PlanUnlimitedExisting 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

FeatureTraditional ADAzure AD
LocationOn-premisesCloud
ProtocolsLDAP, KerberosOAuth 2.0, SAML, OIDC
StructureOUs, GPOs, domain-joinedFlat, no GPOs
Use caseDomain-joined machinesCloud/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.

TypeLifecycleSharing
System-assignedTied to resourceCannot share
User-assignedIndependentCan 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:

RolePermissions
OwnerFull access, can assign roles
ContributorFull access, cannot assign roles
ReaderView only
User Access AdministratorManage 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

FeatureNSGAzure Firewall
CostFreePaid service
LayerL3/L4 (IP, port)L3-L7 (application aware)
ScopeSubnet/NICCentralized
FeaturesBasic allow/denyFQDN filtering, threat intel, logging
Use caseMicrosegmentationEnterprise 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

MethodUse Case
VNet PeeringConnect VNets (same or different regions/subscriptions)
VPN GatewayEncrypted connection over internet to on-premises
ExpressRoutePrivate dedicated connection to on-premises
Private EndpointAccess Azure PaaS services over private IP
Service EndpointOptimized 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:

ServiceTypeUse Case
Blob StorageObject storageUnstructured data, images, backups
File StorageSMB file sharesLift-and-shift, shared storage
Queue StorageMessage queuingDecoupling components
Table StorageNoSQL key-valueSimple structured data (consider Cosmos DB)

Blob Access Tiers:

TierAccessCost Pattern
HotFrequentHigher storage, lower access
CoolInfrequent (30+ days)Lower storage, higher access
ArchiveRare (180+ days)Lowest storage, rehydration required

Redundancy Options:

OptionDescriptionDurability
LRS3 copies in one data center11 nines
ZRS3 copies across AZs12 nines
GRSLRS + async copy to paired region16 nines
GZRSZRS + async copy to paired region16 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):

LevelGuaranteeLatency
StrongLinearizable (latest write)Highest
Bounded StalenessConsistent within K versions or T timeHigh
SessionConsistent within sessionMedium (default)
Consistent PrefixReads never see out-of-order writesLow
EventualNo ordering guaranteeLowest

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:

OptionDescription
Azure SQL DatabaseSingle database, fully managed
Elastic PoolMultiple databases sharing resources
SQL Managed InstanceNear 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

FactorAzure SQLCosmos DB
Data modelRelational, joinsDocument, key-value
SchemaFixedFlexible
ScalingVertical (mostly)Horizontal (unlimited)
ConsistencyStrong (ACID)Tunable
Global distributionGeo-replicationMulti-region writes
Best forTransactional, complex queriesScale, 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.

FeatureKubenetAzure CNI
Pod IPsNAT'd behind nodeDirect VNet IPs
IP consumptionEfficientRequires large subnet
Windows supportNoYes
Network policiesCalico onlyAzure 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)

AzureAWSPurpose
Virtual MachinesEC2Compute
App ServiceElastic BeanstalkPaaS web hosting
Azure FunctionsLambdaServerless compute
Blob StorageS3Object storage
Azure SQLRDSManaged relational DB
Cosmos DBDynamoDBNoSQL
VNetVPCVirtual networking
Azure ADIAM + CognitoIdentity
AKSEKSManaged Kubernetes
Azure DevOpsCodePipeline + CodeBuildCI/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:

  1. Assess: Use Azure Migrate to discover dependencies
  2. Choose target: App Service (easiest), AKS (containers), or VMs (lift-and-shift)
  3. Database: Azure SQL Managed Instance for compatibility or Azure SQL Database
  4. Identity: Azure AD Connect to sync on-premises AD
  5. Networking: VPN or ExpressRoute for hybrid connectivity
  6. 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:

  1. SQL Server firewall: Is client IP or VNet allowed?
  2. NSG on VM subnet: Outbound to SQL port 1433 allowed?
  3. Private Endpoint configured? Check private DNS resolution
  4. Connection string correct? Server name, database, authentication
  5. SQL authentication enabled if using SQL auth?

Q: App Service can't access Key Vault. Why?

A:

  1. Managed Identity enabled on App Service?
  2. Access policy or RBAC role assigned to the identity?
  3. Correct Key Vault URI in app configuration?
  4. If using Private Endpoint, is VNet integration configured on App Service?
  5. Key Vault firewall blocking access?

Q: AKS pods are stuck in Pending state. What do you check?

A:

  1. Node resources: Is there enough CPU/memory? (kubectl describe node)
  2. Node pool scaling: Are nodes available or scaling?
  3. Taints and tolerations: Does pod tolerate node taints?
  4. Node selectors: Does pod's nodeSelector match any nodes?
  5. 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:


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.

Ready to ace your interview?

Get 550+ interview questions with detailed answers in our comprehensive PDF guides.

View PDF Guides