44 Azure Interview Questions and Answers

Azure is a major cloud platform with strong integration across Microsoft's identity, developer and operations ecosystem. Interview questions reward service mechanics and trade-offs more than unverified market-rank claims.

This guide covers Microsoft Entra ID, Azure Resource Manager and representative compute, storage, database and networking services. Treat every architecture answer as a discussion of workload requirements, failure modes, security boundaries and measured cost.

Table of Contents

1. Azure Fundamentals Questions
2. Azure Resource Manager Questions
3. Virtual Machine Questions
4. App Service Questions
5. Azure Functions Questions
6. Microsoft Entra ID and Identity Questions
7. RBAC and Access Control Questions
8. Virtual Network Questions
9. Network Security Questions
10. Storage Account Questions
11. Cosmos DB Questions
12. Azure SQL Questions
13. AKS and Container Questions
14. Azure Architecture Scenario Questions

Azure Fundamentals Questions

Before diving into specific services, you need to understand how Azure organizes and manages resources at a fundamental level.

How is Azure's resource hierarchy organized?

Azure uses a specific hierarchy for organizing and managing resources that determines how policies, billing, and access control are applied. Understanding this hierarchy is essential because it affects how you structure enterprise Azure deployments and how permissions cascade.

The hierarchy flows from a Microsoft Entra tenant/root management group through management groups, subscriptions, resource groups and resources. Role assignments and Azure Policy definitions can be scoped high and inherited, subject to exclusions, deny assignments and policy behavior.

flowchart TB
    T["Microsoft Entra tenant"]
    MG["Root and child<br/>Management Groups"]
    S["Subscriptions"]
    RG["Resource Groups"]
    R["Resources"]
 
    T --> MG --> S --> RG --> R

Key concepts:

• Tenant: Identity boundary that can be associated with multiple subscriptions
• Management Groups: Root and optional child hierarchy for organizing subscriptions and applying governance at scale
• Subscription: Management, quota and billing scope; network/data isolation still depends on configuration
• Resource Group: A logical container for resources that share the same lifecycle

What happens when you delete a Resource Group in Azure?

Deleting a resource group starts deletion of the resources it contains, subject to authorization, locks, dependencies and each resource provider's behavior. The operation can be asynchronous and partial failures need investigation. Resources outside the group that depend on those resources are not automatically part of that lifecycle.

Group by lifecycle and operational ownership, apply deletion locks and policy where justified, and test cleanup. Do not assume a resource group is a hard security, network or data boundary.

What are Azure Regions and Availability Zones?

Azure's global infrastructure is organized into Regions and Availability Zones that provide the foundation for building highly available applications. Understanding these concepts is crucial because they directly impact your application's latency, compliance posture, and disaster recovery capabilities.

A Region is a geography-scoped deployment area. An Availability Zone is a separated group of datacenters within a region with independent power, cooling and networking; service and zone availability varies. Some regions have an associated region pair and a small number of services use that pairing, while many regions are nonpaired and many services can replicate to other regions independently. Merely deploying in one member of a pair provides no automatic failover.

How do you achieve high availability in Azure?

High availability in Azure is achieved through redundancy at multiple levels, and the approach differs depending on whether you're protecting against hardware failures, data center outages, or regional disasters.

For zonal compute, distribute independent instances and state across enough zones, retain failover capacity and place a health-aware load-balancing layer in front. Prefer zone-redundant service tiers where their semantics meet the workload. For regional disaster recovery, choose a secondary region from latency, data-residency, capacity and service constraints; implement replication, backups and orchestrated failover, and measure RTO/RPO in exercises. SLA percentages depend on the exact SKU and configuration and do not prove end-to-end availability.

Azure Resource Manager Questions

ARM is Azure's control-plane deployment and management layer. Service data-plane calls, such as reading a blob or querying a database, are distinct and may use different endpoints and authorization.

What is Azure Resource Manager and how does it work?

Azure Resource Manager handles control-plane resource operations. It authenticates principals through Microsoft Entra ID, evaluates Azure RBAC and other controls, and dispatches requests to resource providers.

ARM provides several key capabilities: consistent management layer across all tools, declarative deployments through templates, dependency management that ensures resources are created in the correct order, and RBAC integration for access control. Understanding ARM is fundamental because it's how Azure actually works under the hood.

What is the difference between ARM Templates and Bicep?

ARM Templates and Bicep are both infrastructure-as-code solutions for Azure, but they differ significantly in syntax and usability. ARM Templates use JSON format, which can become verbose and difficult to read for complex deployments. Bicep is a domain-specific language that compiles to ARM templates but offers cleaner, more readable syntax.

Microsoft recommends Bicep for new infrastructure-as-code projects because it's significantly easier to write and maintain. However, ARM templates remain important to understand because Bicep compiles to them, and you'll encounter existing ARM templates in many organizations.

ARM Template (JSON):

{
  "$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 (cleaner syntax):

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

Virtual Machine Questions

Azure VMs provide full control over the operating system and are the foundation of IaaS workloads.

What are the different VM series in Azure and when would you use each?

Azure VMs are organized into series based on their optimization for different workloads. Choosing the right series affects both performance and cost, so understanding the options is essential for designing efficient infrastructure.

VM names encode a family, subfamily/features, vCPU count and version, but capabilities and availability vary by generation, processor, Region and zone. Treat an older name such as Standard_D4s_v3 as syntax—not a current recommendation. Filter by workload requirements, benchmark, check quotas/capacity and model reservations/savings plans/Spot.

What is the difference between Availability Sets and Availability Zones?

Both Availability Sets and Availability Zones provide high availability for VMs, but they protect against different types of failures and offer different SLA levels. Understanding when to use each is a common interview question.

Availability Sets ask Azure to distribute VMs across fault and update domains within a datacenter-scale failure boundary. Availability Zones are separated groups of datacenters within a Region. Multiple zone-pinned VMs can tolerate a zonal outage only when load balancing, data, capacity and application state span zones too.

Prefer zonal or zone-redundant designs when the selected service/SKU, latency and data architecture support them. Availability Sets remain relevant for some nonzonal/legacy designs. Check the current VM SLA and service reliability guide for the exact configuration instead of memorizing universal percentages.

What are VM Scale Sets and when would you use them?

VM Scale Sets centrally manage and scale collections of VMs. Uniform orchestration emphasizes identical instances; Flexible orchestration supports a broader VM model. Autoscale can react to metrics or schedules, but health probes, upgrade policy, zone balance, image lifecycle, capacity and safe scale-in remain your design.

Scale Sets integrate with load-balancing options and autoscale, but they are not mandatory for every multi-VM workload. Choose them when their orchestration, repair, upgrade and scaling model fits.

App Service Questions

App Service is Azure's fully managed platform for web apps, APIs, and mobile backends.

What are the different App Service Plan tiers and when would you use each?

App Service Plans define the compute resources your applications run on, and choosing the right tier significantly impacts cost, performance, and available features. The plan determines what features are available to all apps running on it.

Free/Shared are constrained shared-compute offers; paid dedicated tiers add capacity and capabilities. Premium generations and Isolated/App Service Environment target different scale and network-isolation needs. Features, limits and pricing evolve and vary by OS/Region, so select from current requirements rather than assuming one universal production tier.

How do you reduce deployment downtime in App Service?

Deployment slots let eligible App Service plans host and warm a candidate deployment behind a separate hostname, then swap routing/configuration with production. They reduce risk and downtime but cannot guarantee zero downtime for every application.

Deploy to staging, configure slot-sticky settings correctly, warm critical paths, validate dependencies and use swap-with-preview where appropriate. Health probes, long-lived connections, caches and background work need explicit handling. A reverse swap can restore application bits/configuration, but destructive database migrations and external side effects are not automatically rolled back; use backward-compatible expand/contract changes and observability.

Azure Functions Questions

Azure Functions is managed event-driven compute offered through several hosting and billing models; not every plan is pay-per-execution or scales to zero.

What are the different hosting plans for Azure Functions?

Azure Functions currently has five hosting options: Flex Consumption, Elastic Premium, Dedicated/App Service, Azure Container Apps and legacy Consumption. Availability, languages, deployment, scaling, networking and timeout behavior differ by plan and operating system.

Flex Consumption is the recommended dynamic Linux path for supported stacks and adds per-function scaling plus optional always-ready instances. Elastic Premium supplies prewarmed capacity and richer networking/longer execution. Dedicated runs on App Service capacity and needs a scaling plan. Container Apps fits containerized Functions and event-driven scale. Classic Consumption remains a legacy option; Linux Consumption hosting retires on September 30, 2028.

What are triggers and bindings in Azure Functions?

Triggers and bindings are declarative ways to connect Azure Functions to other services without writing boilerplate connection code. A trigger is what starts a function execution, while bindings provide input data or output destinations.

Triggers include HTTP requests, timers, queue messages, blob events and change feeds. Bindings can provide input or output integration. This reduces adapter code, but delivery, retries, poison messages, concurrency, identity-based connections and idempotency still need explicit tests.

[Function("ProcessOrder")]
[CosmosDBOutput("orders", "processed", Connection = "CosmosConnection")]
public ProcessedOrder Run(
    [QueueTrigger("orders", Connection = "QueueConnection")] string message)
    => ProcessedOrder.From(message);

When should you choose VMs vs App Service vs Functions vs AKS?

This is one of the most common Azure architecture questions. The answer depends on your requirements for control, scaling patterns, and operational overhead you're willing to accept.

Use VMs when host/OS control or compatibility requires them. App Service fits supported HTTP applications and containers. Functions fits trigger/binding workflows under a suitable current plan; Durable Functions changes the “short task” discussion. Container Apps often fits managed container and event workloads without Kubernetes API ownership. AKS is justified when Kubernetes extensibility or ecosystem requirements outweigh its operational cost.

flowchart TD
    Q1{"Need full<br/>OS control?"}
    Q1 -->|Yes| A1["Virtual Machine"]
    Q1 -->|No| Q2{"Container<br/>workload?"}
    Q2 -->|Yes| Q4{"Need Kubernetes APIs<br/>and cluster extensibility?"}
    Q4 -->|Yes| A2["AKS candidate"]
    Q4 -->|No| A5["Container Apps or App Service"]
    Q2 -->|No| Q3{"Event-driven,<br/>short tasks?"}
    Q3 -->|Yes| A3["Azure Functions"]
    Q3 -->|No| A4["App Service"]

Microsoft Entra ID and Identity Questions

Microsoft Entra ID is the current name of the cloud identity service formerly called Azure AD. Use the current product name except when discussing historical APIs or names.

What is the difference between Microsoft Entra ID and Active Directory Domain Services?

Microsoft Entra ID and Windows Server Active Directory Domain Services are distinct identity systems despite their naming history.

AD DS supplies domains, LDAP, Kerberos/NTLM, Group Policy and traditional machine join and can run on premises or on VMs. Microsoft Entra ID is a cloud identity and access service for users, applications, workload identities and devices, with OAuth 2.0, OpenID Connect and SAML integrations. Entra join exists, but it is not the same contract as an AD DS domain join.

Microsoft Entra ID is not “AD DS in the cloud.” Microsoft Entra Connect can synchronize selected identity data for hybrid scenarios, but synchronization, federation, password-hash sync and cloud authentication have separate threat and recovery models.

What is a Managed Identity and why should you use it?

Managed identities let supported Azure resources obtain Microsoft Entra tokens without an application secret in code or configuration. They do not replace the target service's authorization, network controls or data-plane policy.

System-assigned identities share the parent resource lifecycle. User-assigned identities are independent and can be associated with multiple resources, which improves reuse but can widen blast radius. Azure manages underlying credentials; teams still manage assignments, least privilege, deletion, token caching, monitoring and incident response.

How should an Azure Function access Key Vault securely?

Enable a managed identity for the Function App and grant only the required Key Vault data-plane actions, preferably through the Azure RBAC permission model for a new design. Configure Key Vault firewall/private endpoint and Functions VNet integration when required. The application requests a token rather than carrying a client secret, but access still depends on identity selection, RBAC propagation, DNS and network paths.

// The same API can use developer credentials locally and managed identity in Azure.
var client = new SecretClient(
    new Uri("https://myvault.vault.azure.net/"),
    new DefaultAzureCredential());

Configure the credential chain deliberately and, when multiple identities are available, select the intended user-assigned identity explicitly. Do not mistake successful token acquisition for Key Vault authorization.

RBAC and Access Control Questions

Azure Role-Based Access Control determines who can do what on which resources.

How does Azure RBAC work?

Azure RBAC evaluates role assignments for principals at scopes. Allows are generally cumulative, but effective access is also shaped by deny assignments, role conditions, Privileged Identity Management activation and the distinction between control-plane Actions and data-plane DataActions.

A role assignment combines three elements: a security principal (who—user, group, service principal, or managed identity), a role definition (what they can do—the permissions), and a scope (where—management group, subscription, resource group, or resource). Permissions inherit downward through the scope hierarchy.

What are the built-in RBAC roles and when would you use each?

Azure provides built-in roles for common access patterns, and understanding the key roles helps you implement least-privilege access. The most important distinction is between Owner, Contributor, and Reader.

Scenario: A developer needs to deploy to App Service but shouldn't access production databases. Create a custom role or use the built-in "Website Contributor" role scoped only to the App Service resource group. Don't grant access at subscription level—follow the principle of least privilege.

What is Microsoft Entra Conditional Access?

Conditional Access policies add conditions to authentication decisions, enabling zero-trust security patterns. Instead of simply allowing or denying access based on credentials, you can require additional verification based on context.

Policies can require an authentication strength/MFA, compliant or managed devices, approved applications or terms under selected user, resource and risk conditions. Location is a signal, not proof, and exclusions/break-glass accounts need governance. Licensing and feature prerequisites vary; deploy first in report-only mode, test impact and avoid lockout rather than copying a universal block-country policy.

Virtual Network Questions

VNets provide regional private address spaces, routing and service connectivity. VMs and AKS nodes attach to VNet subnets. Multitenant App Service uses separate inbound private endpoints and outbound VNet integration; an App Service Environment is injected into a VNet. These are not interchangeable forms of “running inside” a VNet.

What are the core components of an Azure VNet?

A Virtual Network is your isolated network in Azure where you define an address space using CIDR notation. VNets contain subnets, which are ranges within the VNet where you deploy resources. Network Security Groups provide stateful firewall rules at the subnet or NIC level.

Understanding VNet design is critical because it affects security, connectivity, and IP address management. Plan your address spaces carefully—VNets that need to peer or connect via VPN cannot have overlapping address ranges.

flowchart TB
    subgraph vnet["VNet: 10.0.0.0/16"]
        subgraph web["web-tier (10.0.1.0/24)"]
            nsg1["NSG: allow 80, 443<br/>from internet"]
        end
        subgraph app["app-tier (10.0.2.0/24)"]
            nsg2["NSG: allow from<br/>web-tier only"]
        end
        subgraph data["data-tier (10.0.3.0/24)"]
            nsg3["NSG: allow from<br/>app-tier only"]
        end
    end
 
    web --> app --> data

What connectivity options are available for Azure VNets?

Azure provides multiple options for connecting VNets to each other and to on-premises networks, each suited to different requirements for bandwidth, latency, and security.

What is the difference between Private Endpoints and Service Endpoints?

Both provide more secure connectivity to Azure PaaS services, but they work differently and offer different security levels. Understanding the distinction is important for designing secure architectures.

Service Endpoints extend a subnet identity to a supported service's public endpoint and let its firewall restrict selected VNets; DNS and public service addressing remain. Private Endpoints place a network interface with a private IP in your subnet for a specific service subresource through Private Link. Creating one does not automatically disable the service's public endpoint. Private DNS, approval, routing, exfiltration controls and the service firewall must be designed; neither option is categorically “more secure” without requirements.

How do you keep the Azure SQL data path on Private Link?

Create and approve a Private Endpoint for the Azure SQL logical server, configure the correct privatelink.database.windows.net DNS resolution from every client network, and disable public network access. Validate routes, proxies and failover DNS. This keeps the SQL connection on Private Link rather than its public endpoint; it does not by itself secure credentials, SQL authorization or data exfiltration.

This pattern applies to any Azure PaaS service that supports Private Endpoints: Key Vault, Storage Accounts, Cosmos DB, and more.

Network Security Questions

Network security in Azure involves multiple layers of defense.

What is the difference between NSG and Azure Firewall?

NSGs and Azure Firewall both provide network security, but at different layers and with different capabilities. Most architectures use both in combination—NSGs for microsegmentation between subnets, Azure Firewall for centralized perimeter security.

NSGs are stateful, priority-ordered allow/deny rules for supported subnet/NIC traffic, primarily by protocol/address/port. Azure Firewall centralizes network/application/NAT rules and logging; TLS inspection, IDPS, URL filtering and other capabilities depend on the selected SKU. Neither replaces identity, workload authorization or all east-west inspection.

When would you use Azure Firewall over NSGs?

Use Azure Firewall when a routed path needs centralized network/application rules, controlled SNAT/DNAT, threat-intelligence behavior or Premium inspection capabilities. Confirm which traffic actually traverses it and account for DNS proxy, asymmetric routing, availability and cost.

NSGs remain useful distributed segmentation even with a firewall. Regulation does not automatically require a specific product; map technical controls and evidence to the actual requirement.

Storage Account Questions

Azure Storage Accounts provide access to multiple storage services under a single account.

What storage services are available in an Azure Storage Account?

A standard general-purpose v2 account can expose Blob (including Data Lake Storage semantics when hierarchical namespace is enabled), Files, Queues and Tables. Premium and specialized account types support different subsets, performance and redundancy options, so “one account has everything” is not universal.

What are the Blob Storage access tiers and when would you use each?

Standard Blob Storage has four access tiers: Hot, Cool and Cold are online; Archive is offline and requires rehydration. Account type, redundancy, blob type and feature use constrain availability.

Choose from measured access/transaction volume, latency and retention. Cooler tiers lower storage price but add access and early-deletion costs/minimum-duration billing. Archive adds rehydration delay/priority/cost and is unsupported with ZRS/GZRS redundancy.

What redundancy options are available for Azure Storage?

Azure Storage exposes LRS, ZRS, GRS, RA-GRS, GZRS and RA-GZRS where the account/service/Region supports them. Geo replication is asynchronous, so failover can lose recent writes or expose inconsistency; read access to the secondary requires an RA variant, and write failover is a separate operation.

Cosmos DB Questions

Azure Cosmos DB is a distributed database family with multiple APIs and topology/throughput models. Global distribution and multiple writes are configured choices, not automatic requirements.

What makes Cosmos DB different from other databases?

Key capabilities include configurable Regions, optional multiple-write Regions, request-unit or vCore-based models depending on API, partitioning and five documented consistency levels. SLA guarantees have precise eligibility and percentile/scope conditions; a hot partition, cross-partition query or poor indexing policy can still create latency and cost problems.

The API for NoSQL plus wire-compatible APIs for MongoDB, Cassandra, Gremlin and Table have different feature and consistency mappings. Compatibility is not identical to running the upstream database. Validate the chosen API, SDK and migration behavior rather than assuming every workload gets the same contract.

What are the Cosmos DB consistency levels and when would you use each?

Cosmos DB defines Strong, Bounded Staleness, Session, Consistent Prefix and Eventual read consistency. Session is the account default, but read-your-writes across clients/nodes depends on correctly carrying the session token. Strong and Bounded Staleness reads use twice the RU of weaker levels for the same read; write RU cost is the same, while topology affects latency and availability.

Choose per invariant and failure mode. Financial or inventory correctness is not achieved merely by selecting Strong reads; conditional writes, stored procedures/transactions within their documented scope, idempotency and concurrency control may be required. Strong topology constraints have evolved, so verify current Region distance and multiple-write compatibility instead of memorizing “single Region only.”

What is a partition key and why does it matter in Cosmos DB?

The partition key determines how Cosmos DB distributes your data across physical partitions. Choosing a good partition key is critical because it affects performance, scalability, and cost. A poor partition key leads to hot partitions—one partition handling disproportionate load—which causes throttling.

Choose a stable key that aligns high-volume reads/writes with logical partitions while distributing throughput and storage. Prefer point reads with id plus partition key and bounded single-partition queries. Cardinality alone is not enough: model skew, growth, per-logical-partition limits, transactional boundaries and whether hierarchical partition keys or synthetic bucketing are needed.

Azure SQL Questions

Azure SQL provides managed SQL Server database services with varying levels of compatibility and control.

What are the different Azure SQL options and when would you use each?

The main deployment choices are Azure SQL Database, Azure SQL Managed Instance and SQL Server on Azure VMs. Elastic pools are a resource-sharing option within SQL Database, not a fourth engine.

Start with required SQL features, instance/database scope, migration assessment, HA/DR, networking, maintenance control, licensing and measured cost. SQL Database often fits new cloud applications; elastic pools can smooth multiple databases with complementary usage. Managed Instance or a VM can fit migrations blocked by Database feature gaps, but neither should be selected before compatibility tests.

When would you use SQL Managed Instance over Azure SQL Database?

Managed Instance offers instance-scoped capabilities and broader SQL Server compatibility, including use cases involving SQL Agent and cross-database behavior, but supported details vary by service tier and evolve. Run Azure Migrate/database assessment and a workload proof rather than relying on a “near 100%” slogan.

It is not universally more expensive: licensing, reserved capacity, I/O, replicas, operations and consolidation affect total cost. Prefer the least operationally complex option that meets verified compatibility, performance and recovery requirements.

How do you choose between Azure SQL and Cosmos DB?

This is a common architecture question that tests your understanding of relational vs NoSQL tradeoffs in the Azure context.

AKS and Container Questions

Azure Kubernetes Service (AKS) is managed Kubernetes where Azure handles the control plane.

What does Azure manage vs what do you manage in AKS?

Azure operates control-plane infrastructure and provides managed node-pool capabilities. The customer still owns supported Kubernetes-version lifecycle unless configured channels/Automatic manage it, plus cluster configuration, identities, network policy, admission, workloads, data and observability.

In Standard AKS, teams choose node pools, upgrade strategy, zones, autoscaling, maintenance windows and disruption budgets; Azure supplies images and automation but does not make application upgrades safe. AKS Automatic shifts more configuration and node operation to Azure, with a different supported feature contract. Shared responsibility must be stated for the selected mode.

flowchart TB
    subgraph aks["AKS Cluster"]
        sys["System Node Pool<br/>(Linux, system pods)"]
        user1["User Node Pool 1<br/>(Linux, general workloads)"]
        user2["User Node Pool 2<br/>(Windows, .NET apps)"]
    end

How do you choose an AKS networking model now that kubenet is retiring?

Current choices include Azure CNI Overlay and flat Azure CNI Pod Subnet/Node Subnet variants. kubenet is legacy and retires on March 31, 2028, so new designs should not present it as an equal default.

Azure CNI Overlay gives pods addresses from a separate overlay range and conserves VNet space; outside endpoints see node addresses. Azure CNI Pod Subnet gives pods VNet-reachable addresses and can use dynamic allocation, at the cost of deliberate IP planning. Azure CNI Powered by Cilium is the recommended policy/data plane where supported. Select from inbound pod reachability, Windows, scale, overlapping CIDRs, policy and existing network requirements.

How do you securely pull images from ACR to AKS?

For a normal RBAC-mode registry, az aks update --attach-acr <acr-name> grants AcrPull to the AKS kubelet identity—not the workload identity used by application pods. Scope it to the required registry and audit who can push or overwrite referenced tags/digests. Registries enabled for RBAC Registry + ABAC Repository Permissions do not support this --attach-acr path; use the documented repository-reader assignment instead.

This avoids static Docker registry secrets in manifests. Private networking, DNS, firewall, identity propagation and supply-chain controls (immutable digests, signing/admission and scanner policy) still matter.

Azure Architecture Scenario Questions

These questions test your ability to combine Azure services into complete solutions.

How would you design a highly available web application on Azure?

When designing for high availability, think through each layer of the stack and how it achieves redundancy. A complete answer addresses compute, networking, data, and operational concerns.

Begin with SLO, RTO/RPO, data residency and consistency. Within a Region, use zone-redundant App Service where supported or zone-spread VMs/AKS capacity with health-aware routing. For regional failure, deploy independently recoverable capacity and use Front Door or another suitable global routing layer. Select Azure SQL failover groups/geo-replication, Cosmos DB topology and Storage GZRS/RA-GZRS only after modeling replication lag and failover authority. Use Microsoft Entra ID, managed/workload identities and Key Vault, but also design bootstrap and regional dependencies. Add distributed telemetry, tested alerts, backups isolated from the failure, deployment rollback and regular chaos/DR exercises. A service list alone does not prove availability.

How would you migrate an on-premises .NET application to Azure?

Migration questions test practical experience. A methodical approach demonstrates maturity:

1. Assess: Use Azure Migrate to discover the application and its dependencies
2. Choose target: App Service, Container Apps, AKS or VMs from dependency, runtime, operating model and modernization goals—not “containerize by default”
3. Database: Run an Azure Migrate/database assessment and proof against SQL Database, Managed Instance or SQL Server VM
4. Identity: Use Microsoft Entra Connect or cloud-native identity only when its synchronization/authentication/recovery model is deliberate
5. Networking: VPN Gateway or ExpressRoute for hybrid connectivity during and after migration
6. Migrate and validate: Use Azure Migrate's supported migration tooling, rehearse cutover/rollback, reconcile data, performance and security, then decommission only after acceptance

How would you design secure access from a container application to Azure SQL and Key Vault?

This scenario tests your understanding of secure service-to-service communication in Azure.

First decide whether AKS is needed; Container Apps can also use workload identity. In AKS, enable OIDC issuer and Workload ID, bind a narrowly scoped Kubernetes service account to a user-assigned managed identity, and constrain token audiences/namespaces. Grant a Key Vault data-plane role only for required secrets. Azure RBAC manages the SQL resource but does not by itself grant database query permission: configure a Microsoft Entra administrator and create the contained database user/roles with least privilege. Add Private Endpoints, private DNS and outbound VNet routing, disable public access where required, and test token refresh/failure. DefaultAzureCredential removes an application secret only when its production credential selection is configured correctly.

A VM can't connect to Azure SQL Database. What do you check?

Troubleshooting questions reveal operational experience. Work through the network path systematically:

1. Endpoint mode: Is public access intended, or should DNS resolve the logical server to its Private Endpoint?
2. Network path: Check effective routes, NSGs, firewall and DNS; SQL connection policy can require more than TCP 1433 in redirect mode
3. Private Endpoint: If using Private Endpoint, is private DNS resolution working correctly?
4. Connection string: Is the server name, database, and authentication method correct?
5. Authentication/authorization: Validate Microsoft Entra token audience/identity/database user or SQL credentials without logging secrets

App Service can't access Key Vault. What do you check?

Another common troubleshooting scenario that tests understanding of managed identity and networking:

1. Managed Identity: Is it enabled on the App Service?
2. Access permissions: Is the exact identity granted the required Key Vault data-plane role (or legacy access policy for that vault model), and has propagation completed?
3. Key Vault URI: Is the correct URI configured in the application?
4. Network access: App Service VNet integration is outbound; verify route-all choices and private DNS resolve the Key Vault Private Endpoint from the app workers
5. Key Vault firewall: Is the firewall blocking the App Service?

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

Kubernetes scheduling issues require understanding how the scheduler works:

1. Node resources: Is there enough CPU/memory available? (kubectl describe node)
2. Node pool scaling: Are nodes available, or is the autoscaler still adding capacity?
3. Taints and tolerations: Does the pod tolerate any taints on available nodes?
4. Node selectors: Does the pod's nodeSelector match any available nodes?
5. PVC issues: If using persistent storage, is the PersistentVolumeClaim bound?

Quick Reference

Resource Hierarchy: Tenant → Management Groups → Subscriptions → Resource Groups → Resources

Compute:

• VMs: Full control, IaaS
• App Service: Managed web hosting, PaaS
• Functions: Managed event-driven compute with plan-specific billing and scale
• AKS: Managed Kubernetes

Identity:

• Microsoft Entra ID: Cloud identity and access platform
• Managed Identity: No application secret in code; least-privilege authorization still required
• RBAC: Role-based access control

Networking:

• VNet: Virtual network
• NSG: Distributed stateful allow/deny rules
• Azure Firewall: Central managed firewall with SKU-specific inspection
• Private Endpoint: Private IP for PaaS services

Storage/Database:

• Blob: Object storage
• Azure SQL: Managed SQL Server
• Cosmos DB: Partitioned database APIs with configurable Regions and consistency

Frequently Asked Questions

What is the difference between Microsoft Entra ID and Active Directory Domain Services?

Microsoft Entra ID, formerly Azure AD, is a cloud identity and access service for users, applications, workload identities and devices, using protocols such as OAuth 2.0, OpenID Connect and SAML. Windows Server Active Directory Domain Services provides domain, LDAP, Kerberos, Group Policy and traditional machine-join capabilities. They can coexist through Microsoft Entra Connect or other hybrid patterns, but one is not simply a hosted replacement for every feature of the other.

When should you use App Service vs Azure Functions vs AKS?

Use App Service for supported web/API runtimes and containers when managed HTTP hosting, deployment slots and platform integration fit. Use Functions for trigger-and-binding event workloads when a current hosting plan, execution lifecycle, scale and limits fit. Use AKS only when Kubernetes APIs and its operational flexibility justify cluster, node, networking, policy and upgrade ownership. Also evaluate Container Apps; choose from measured SLOs, workload shape, compliance, team capability and total cost rather than simplicity-versus-control slogans.

What is a Managed Identity in Azure?

A managed identity gives a supported Azure resource an identity in Microsoft Entra ID so code can request short-lived tokens without storing an application secret. A system-assigned identity shares the resource lifecycle; a user-assigned identity is independent and can be associated with multiple resources. The identity still needs least-privilege data-plane or management-plane authorization, and token acquisition, network access, audit and lifecycle must be designed.

What are the Cosmos DB consistency levels?

Azure Cosmos DB offers Strong, Bounded Staleness, Session, Consistent Prefix and Eventual consistency. Session is the default and provides read-your-writes within a session when its token flows correctly. Strong and Bounded Staleness reads consume twice the request units of weaker levels for the same read, while write RU cost is unchanged; latency, availability, topology and API constraints also differ. Choose from correctness and failure requirements, not a blanket strongest-is-best rule.

What is the difference between NSG and Azure Firewall?

Network security groups are stateful ordered allow/deny rules applied to supported subnet and network-interface traffic, mainly at layers 3 and 4. Azure Firewall is a centralized managed firewall with network, application and DNAT/SNAT capabilities whose exact TLS inspection, IDPS, URL and threat-intelligence features depend on SKU. Use NSGs for distributed segmentation and Azure Firewall when centralized egress/ingress policy and inspection requirements justify it; they are commonly complementary.

How does Azure Resource Manager (ARM) work?

Azure Resource Manager is Azure's control-plane deployment and management service. Control-plane requests are authenticated through Microsoft Entra ID, authorized with Azure RBAC and routed to resource providers. Management groups, subscriptions, resource groups and resources form scopes for governance; locks, tags and Azure Policy add controls. ARM templates and Bicep describe deployments declaratively, but many service data-plane operations use separate endpoints and authorization.

Sources

• Microsoft Entra ID naming changes
• Azure resource hierarchy and management groups
• Azure region pairs and nonpaired regions
• Reliability in Azure Virtual Machines
• Bicep overview
• App Service deployment slots
• Azure Functions hosting and scale
• Managed identities for Azure resources
• Azure RBAC overview
• Microsoft Entra Conditional Access overview
• Azure Private Endpoint overview
• Azure Firewall features by SKU
• Azure Storage account overview
• Blob Storage access tiers
• Azure Storage redundancy
• Azure Cosmos DB consistency levels
• Azure SQL service options
• AKS network concepts
• AKS and Azure Container Registry integration
• Microsoft Entra Workload ID on AKS

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