Microsoft Azure Interview Questions and Answers: 60 Questions from Easy to Hard
This guide is for freshers in India preparing for cloud and support roles, and for developers, administrators and cloud engineers with 1 to 10 years of experience facing Microsoft Azure interviews. It has 60 questions with answers in three levels: core concepts such as regions, resource groups, Microsoft Entra ID, VMs, storage and networking; day-to-day work with Bicep, App Service, Functions, AKS, Azure SQL, KQL and Azure Policy; and senior design questions on high availability, security and cost. Read each answer, then explain it aloud in your own words and take the mock test. The questions are written by CoreHRx for practice. CoreHRx is not affiliated with or endorsed by Microsoft, and these are not actual Azure certification exam questions. Azure changes often, so check the official documentation for current details.
- 60 questions, 3 levels
- Updated
- CoreHRx Jobs
- 3,277 open Microsoft Azure jobs
Practice questions written by CoreHRx. CoreHRx is not affiliated with or endorsed by Microsoft, and these are not actual Azure certification exam questions.
What Azure interviews cover
- Core concepts: IaaS, PaaS and SaaS, regions and availability zones, the management group, subscription and resource group hierarchy, and Azure Resource Manager.
- Identity and access: Microsoft Entra ID (formerly Azure AD), Azure RBAC roles and scopes, service principals and managed identities.
- Compute and data: Virtual Machines, App Service, Azure Functions, containers on AKS and Container Apps, Azure Storage, Azure SQL and Cosmos DB.
- Networking and security: virtual networks and subnets, NSGs, peering, private endpoints, the load balancing options and Key Vault.
- For experienced roles: Bicep and CI/CD pipelines, monitoring with KQL, Azure Policy and cost control, and multi-region high availability and disaster recovery designs.
How to prepare (freshers and experienced)
- Freshers: if you have access to a free or student subscription, build one small project end to end, such as a web app on App Service that reads a secret from Key Vault and stores files in Blob storage.
- Learn the Azure CLI basics (az group, az vm, az webapp, az storage), because interviewers trust a candidate who can describe the exact command and what it does.
- Deploy the same project from a Bicep file instead of clicking in the portal, then delete the resource group and redeploy it to see why infrastructure as code matters.
- Experienced engineers: prepare two or three real stories, such as an outage you debugged, a cost you cut or a migration you led, with the numbers and the trade-offs.
- Read the five pillars of the Azure Well-Architected Framework (reliability, security, cost optimisation, operational excellence, performance efficiency); senior design questions follow them closely.
Common mistakes and interview-day tips
- Do not answer with a list of service names. Say what problem the service solves, and when you would not use it.
- Mention security by default: managed identities instead of secrets, private endpoints, least-privilege RBAC and no RDP or SSH ports open to the internet.
- Azure changes often and services get renamed, so use current names such as Microsoft Entra ID and say "check the current documentation" for limits and tiers.
- For design questions, ask about scale, RTO, RPO, budget and compliance before drawing anything, and state your assumptions out loud.
- Do not quote prices or limits from memory; explain how you would check them in the pricing calculator or the official documentation.
Microsoft Azure interview questions: Easy questions (freshers)
20 questions1. What is the difference between IaaS, PaaS and SaaS, with an Azure example of each?
They differ in how much Azure manages for you. With IaaS, such as Azure Virtual Machines, Azure runs the hardware, network and virtualisation, while you manage the operating system, patches, runtime and app. With PaaS, such as App Service or Azure SQL Database, Azure also runs the OS and platform, so you bring only code or data. SaaS, such as Microsoft 365, is a finished application you configure and use. This split is the shared responsibility model: your data, identities, access and configuration stay your job in every model.
2. What are Azure regions, availability zones and region pairs?
A region is a set of datacenters in one area, such as Central India in Pune, joined by a low-latency network. In regions that support them, availability zones are physically separate groups of datacenters with their own power, cooling and networking, so spreading VMs or using zone-redundant services protects you from a datacenter failure. Many regions also have a paired region in the same geography for disaster recovery, but not every newer region has a pair, so check the documentation for the region you choose instead of assuming.
3. Explain the Azure resource hierarchy from management groups down to resources.
From top to bottom: management groups, subscriptions, resource groups and resources. Management groups organise subscriptions, for example a Production group and a Sandbox group under the tenant root group. A subscription is a billing and access boundary. A resource group is a container for resources that share a lifecycle, and a resource is a single item such as a VM, database or storage account. RBAC role assignments and Azure Policy set at a higher level are inherited below, so Reader on a management group gives read access to every subscription in it.
4. What rules should you know about resource groups?
A resource belongs to exactly one resource group, but the resources in a group can be in different regions; the group's own location only says where its metadata is stored. Group resources that are deployed, updated and deleted together, such as the app, database and storage of one environment. Deleting a resource group deletes everything in it, which is handy for clean-up and dangerous in production, so protect production groups with locks. Most resource types can be moved between groups, but resource groups cannot be nested.
az group create --name rg-payroll-dev --location centralindia
az group list --output table
az group delete --name rg-payroll-dev --yes --no-wait5. What is Azure Resource Manager (ARM)?
Azure Resource Manager is the deployment and management layer, the control plane, of Azure. Every request from the portal, Azure CLI, PowerShell, SDKs or the REST API goes to ARM, which authenticates the caller with Microsoft Entra ID, checks Azure RBAC and Azure Policy, and passes the request to the resource provider, such as Microsoft.Compute for VMs. Because everything goes through one layer you get consistent access control, tags, locks and activity logs. ARM templates and Bicep files are declarative files that ARM deploys.
6. What is Microsoft Entra ID, and how is it different from Windows Server Active Directory?
Microsoft Entra ID is Microsoft's cloud identity service; it was called Azure Active Directory (Azure AD) until Microsoft renamed it in 2023. A tenant holds users, groups, app registrations and devices, and signs them in to Azure, Microsoft 365 and SaaS apps with modern protocols such as OAuth 2.0, OpenID Connect and SAML. Active Directory Domain Services on Windows Server is an on-premises directory built on Kerberos, LDAP and Group Policy. Many companies sync the two with Microsoft Entra Connect, so they are related but not the same product.
7. How does Azure role-based access control (RBAC) work?
Azure RBAC controls who can do what on Azure resources. A role assignment has three parts: a security principal (a user, group, service principal or managed identity), a role definition (a set of allowed actions) and a scope (management group, subscription, resource group or single resource). The common built-in roles are Owner (full access, including granting access), Contributor (manage resources but not grant access) and Reader (view only). Assign roles to groups rather than to individuals, at the smallest scope that works: that is least privilege.
az role assignment create \
--assignee "priya.sharma@yourtenant.onmicrosoft.com" \
--role "Reader" \
--scope "/subscriptions/$SUB_ID/resourceGroups/rg-payroll-dev"8. What is a managed identity, and what is the difference between system-assigned and user-assigned?
A managed identity gives an Azure resource its own identity in Microsoft Entra ID, so code can get tokens for Key Vault, Storage or Azure SQL with no password or secret in the config, and Azure handles the credentials. A system-assigned identity is created with one resource and deleted with it. A user-assigned identity is a separate resource you create once and attach to many resources, useful when several apps need the same access or the identity must survive a redeployment. Either way you still grant access with an RBAC role, such as Storage Blob Data Reader.
az webapp identity assign --resource-group rg-hr-prod \
--name app-hr-portal9. What do you choose when creating an Azure VM, and what does Stopped (deallocated) mean?
You choose the region, image (such as Ubuntu or Windows Server), size (vCPUs and memory, for example the burstable B, general-purpose D or memory-optimised E series), disk types, virtual network and subnet, public IP or none, NSG rules and login method, ideally an SSH key. Shutting down from inside the OS, or az vm stop, keeps the VM allocated and compute is still billed. az vm deallocate, or Stop in the portal, releases the hardware so compute billing stops, but disks are still billed and the temporary disk is wiped.
az vm create --resource-group rg-lab --name vm-web01 \
--image Ubuntu2204 --size Standard_B2s \
--admin-username azureuser --generate-ssh-keys
az vm deallocate --resource-group rg-lab --name vm-web0110. Which data services does an Azure Storage account provide?
A general-purpose v2 storage account holds four data services under one name. Blob storage keeps unstructured objects such as images, backups and logs in containers. Azure Files offers managed file shares over SMB or NFS that VMs and office PCs can mount. Queue storage is a simple message queue for passing work between components. Table storage is a key-value NoSQL store for structured, non-relational data. The account name becomes part of every endpoint, such as name.blob.core.windows.net, so it must be globally unique, 3 to 24 lowercase letters and digits.
11. Explain the storage redundancy options LRS, ZRS, GRS and GZRS.
LRS keeps three copies in one datacenter in the primary region: cheapest, but a datacenter failure can make the data unavailable. ZRS keeps three copies across three availability zones in the region. GRS adds an asynchronous copy to the secondary paired region, where it is again stored with LRS, so six copies in total. GZRS uses ZRS in the primary plus the same geo-replication. The RA- versions (RA-GRS and RA-GZRS) also let you read from the secondary. Because geo-replication is asynchronous, the latest writes can be lost if the primary region fails.
12. What are the Blob storage access tiers, and when would you use each?
Hot is for data read often: highest storage cost, lowest access cost. Cool and Cold are for data read rarely: lower storage cost, higher access cost, and a minimum storage period with an early deletion charge if you move or delete the blob sooner. Archive is the cheapest to store but offline: you must rehydrate a blob to an online tier before reading it, which can take hours. A typical plan for logs is Hot for a week, Cool for a few months, then Archive for audit. Check the documentation for the current minimum periods.
13. What is a virtual network, and how many addresses can you use in a /27 subnet?
A virtual network (VNet) is your private network in one Azure region, with an address space such as 10.10.0.0/16 that you split into subnets for tiers like web, app and database. Azure reserves five addresses in every subnet: the network address, the next three (default gateway and Azure DNS) and the last (broadcast). A /27 has 2 to the power 5 = 32 addresses, so 32 - 5 = 27 are usable. Plan ranges early and avoid overlap, because peering or a VPN to the office fails when address spaces overlap.
14. How does a network security group (NSG) work?
An NSG is a list of allow and deny rules on source, destination, port and protocol, attached to a subnet or a network interface. Rules are checked in priority order, lower number first, and evaluation stops at the first match. NSGs are stateful: if inbound traffic is allowed, the reply is allowed automatically. The default rules allow traffic within the VNet and from Azure Load Balancer and deny all other inbound traffic. A common mistake is opening port 22 or 3389 to Any; use Azure Bastion or a specific office IP range instead.
az network nsg rule create --resource-group rg-lab \
--nsg-name nsg-web --name allow-https --priority 100 \
--direction Inbound --access Allow --protocol Tcp \
--destination-port-ranges 44315. What is Azure App Service, and what is an App Service plan?
App Service is a PaaS for hosting web apps and APIs in .NET, Java, Node.js, Python or PHP, or as a container, without managing servers. The App Service plan is the compute behind it: region, OS, pricing tier and number of instances. Every app in a plan shares those instances, so one heavy app slows its neighbours, and scaling the plan scales all its apps. You get built-in HTTPS, custom domains, autoscale, deployment slots on higher tiers and simple deployment from GitHub Actions or a zip package.
az appservice plan create --resource-group rg-hr-dev \
--name plan-hr-dev --sku B1 --is-linux
az webapp create --resource-group rg-hr-dev --plan plan-hr-dev \
--name app-hr-portal-dev --runtime "PYTHON:3.12"16. What are triggers and bindings in Azure Functions?
A trigger is what starts a function, and every function has exactly one: an HTTP request, a timer, a queue message, a new blob or an Event Grid event. Bindings connect the function to other services without client code: an input binding reads data in and an output binding writes data out, for example writing a queue message. The snippet is an HTTP-triggered function in the Python v2 programming model, where decorators declare the trigger. Bindings keep code short, but you can still use the normal SDK when you need retries or complex queries.
import azure.functions as func
app = func.FunctionApp()
@app.route(route="hello", auth_level=func.AuthLevel.FUNCTION)
def hello(req: func.HttpRequest) -> func.HttpResponse:
name = req.params.get("name", "candidate")
return func.HttpResponse(f"Hello, {name}")17. What is Azure Key Vault used for?
Key Vault stores secrets (connection strings, API keys), cryptographic keys and TLS certificates outside your code. Apps read them at run time with a managed identity, so no secret sits in the repository or the app settings. Access is controlled with Azure RBAC roles such as Key Vault Secrets User, and every access can be logged through diagnostic settings. Soft delete keeps deleted items recoverable for a retention period, and purge protection stops anyone deleting them permanently before that. A common mistake is one shared vault for every app and environment.
az keyvault secret set --vault-name kv-payroll-dev \
--name DbPassword --value "use-a-real-secret-here"
az keyvault secret show --vault-name kv-payroll-dev \
--name DbPassword --query value --output tsv18. What are the differences between Azure SQL Database, Azure SQL Managed Instance and SQL Server on an Azure VM?
Azure SQL Database is fully managed PaaS for a single database or an elastic pool: Microsoft handles patching, backups and high availability, but some instance-level features such as SQL Server Agent are not available. Azure SQL Managed Instance is a managed SQL Server instance inside your virtual network with near-complete compatibility, including SQL Agent and cross-database queries, so it suits lift-and-shift. SQL Server on an Azure VM is IaaS: full control of the engine and OS, but you patch, back up and build high availability yourself.
19. What is Azure Cosmos DB, and what is a request unit?
Cosmos DB is a fully managed, globally distributed NoSQL database. You choose an API when creating the account, such as the native API for NoSQL (JSON documents queried with SQL-like syntax) or the APIs for MongoDB, Apache Cassandra, Apache Gremlin and Table, so existing drivers work. Cost and capacity are measured in request units (RU): every read, write and query consumes RUs, and you provision RU per second, use autoscale or choose serverless. Data is spread over partitions by a partition key you pick, the most important design decision.
20. What is Azure Monitor, and how are metrics, logs and Application Insights different?
Azure Monitor is the platform that collects and acts on telemetry. Metrics are numbers over time, such as CPU percent or request count: lightweight, near real time and ideal for charts and alerts. Logs are detailed records stored in a Log Analytics workspace and queried with KQL. Application Insights is the application monitoring part: requests, dependencies, exceptions and traces from your code. The activity log records control-plane operations, such as who deleted a VM. Alerts on metrics or log queries call action groups to send email, SMS or webhooks.
Ready to check yourself? Take the free Microsoft Azure mock test
Microsoft Azure interview questions: Medium questions (1-3 years)
20 questions21. What does Bicep add over ARM JSON templates? Explain the file below.
Bicep is a language that compiles to ARM template JSON, so anything ARM can deploy, Bicep can too, and unlike Terraform there is no state file to manage. It is much shorter than JSON, has type checking and VS Code IntelliSense, and works out dependencies from symbolic references between resources. Here location defaults to the resource group's region, uniqueString gives a stable unique suffix per resource group, and the output reads the blob endpoint from the st symbol. Deploy it with az deployment group create; az bicep build shows the generated JSON.
param location string = resourceGroup().location
param env string = 'dev'
resource st 'Microsoft.Storage/storageAccounts@2023-05-01' = {
name: 'st${env}${uniqueString(resourceGroup().id)}'
location: location
sku: {
name: 'Standard_LRS'
}
kind: 'StorageV2'
}
output blobEndpoint string = st.properties.primaryEndpoints.blob22. What is the difference between incremental and complete deployment modes, and why run what-if first?
In incremental mode, the default, ARM creates or updates the resources in the template and leaves other resources in the resource group alone. Complete mode also deletes resources in the group that are not in the template, which can remove a database someone added by hand. what-if shows what would be created, changed or deleted without touching anything, so run it in every pipeline. A subtle trap: a resource that is in the template is fully reapplied, so redeploying a virtual network whose template omits its subnets can try to remove them.
az deployment group what-if --resource-group rg-hr-dev \
--template-file main.bicep --parameters env=dev
az deployment group create --resource-group rg-hr-dev \
--template-file main.bicep --parameters env=dev \
--mode Incremental23. What is the difference between an app registration, a service principal and a managed identity?
An app registration creates the application object, the global definition of an app in its home tenant: redirect URIs, API permissions and credentials. A service principal is that app's identity inside a particular tenant, and it is what you assign roles to. A managed identity is a special service principal whose credentials Azure creates and rotates, so prefer it whenever code runs in Azure. DefaultAzureCredential tries several sources in turn, such as environment variables, managed identity and your Azure CLI login, so the same code works on a laptop and in Azure.
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient
cred = DefaultAzureCredential()
client = SecretClient(
vault_url="https://kv-payroll-dev.vault.azure.net",
credential=cred)
db_password = client.get_secret("DbPassword").value24. Rahul has the Contributor role, but he gets AuthorizationFailed when he tries to give a function app access to a storage account. Why?
Contributor can manage resources but cannot grant access: its definition excludes writes under Microsoft.Authorization, so role assignments are blocked. Assigning roles needs Owner, User Access Administrator or Role Based Access Control Administrator at that scope. Ask someone holding one of these to grant the narrowest role, such as Storage Blob Data Contributor on that one account. Remember too that management roles are not data roles: reading blobs with Entra ID sign-in needs a data role even for a Contributor. New assignments can take a few minutes to apply.
25. How do App Service deployment slots work, and what is a slot setting?
A deployment slot is a separate live app with its own hostname, such as a staging slot next to production. You deploy to staging, warm it up and test it, then swap: App Service warms the staging instances first and then switches traffic, so users see no downtime, and the previous version stays in staging for a quick swap back. Settings marked as deployment slot settings stay with their slot, such as a staging database string, while other settings travel with the code. Forgetting to mark them is a classic cause of production incidents.
az webapp deployment slot create --resource-group rg-hr-prod \
--name app-hr-portal --slot staging
az webapp deployment slot swap --resource-group rg-hr-prod \
--name app-hr-portal --slot staging --target-slot production26. How do you use a Key Vault secret in App Service settings without storing the value in the app?
Set the app setting to a Key Vault reference instead of the value. App Service resolves it with the app's managed identity and exposes the secret to code as an ordinary environment variable, so the code does not change. Steps: enable a managed identity on the app, grant it Key Vault Secrets User on the vault, then add the setting. If the identity lacks access or the vault firewall blocks the app, the portal shows an error for that reference and the app receives the reference text itself instead of the secret, the first thing to check.
az webapp config appsettings set --resource-group rg-hr-prod \
--name app-hr-portal --settings \
"DbPassword=@Microsoft.KeyVault(VaultName=kv-hr-prod;SecretName=DbPassword)"27. Users of a Bengaluru fintech say its App Service API is very slow on the first request every morning. What do you check?
The usual cause is that the app was unloaded after sitting idle, so the first request pays the full startup cost. Turn on Always On (not available on the Free and Shared tiers), which keeps the app loaded. Add a health check path so unhealthy instances are taken out of rotation, and deploy with slot swap so new code is warmed before users hit it. Then look in Application Insights: if startup itself is slow because of heavy initialisation, fix the code. Scale up when one instance is too small, scale out when one is not enough.
28. Compare the Azure Functions hosting plans and the cold start problem.
On the Consumption plan instances are added and removed on demand and you pay per execution, so an idle app has a cold start and executions have a maximum timeout. The newer Flex Consumption plan adds virtual network integration and always-ready instances. The Premium plan keeps pre-warmed instances, so no cold starts, with VNet integration and longer runs. The Dedicated plan runs on an App Service plan you already pay for. Pick Consumption for spiky, short jobs and Premium or Flex Consumption for latency-sensitive APIs, and check the docs for current limits.
29. A queue-triggered function sometimes processes the same order twice, and some messages land in a queue called orders-poison. Explain both.
Storage queue triggers give at-least-once delivery: if the function fails, times out or the host restarts after doing the work but before the message is deleted, the message becomes visible again and runs again. So handlers must be idempotent, for example checking the order id before charging. When a message keeps failing, up to maxDequeueCount (5 by default, set in host.json), the runtime moves it to a queue with the -poison suffix. Alert on that queue, log the failure reason and replay the messages once the bug is fixed.
import azure.functions as func
app = func.FunctionApp()
@app.queue_trigger(arg_name="msg", queue_name="orders",
connection="AzureWebJobsStorage")
def process_order(msg: func.QueueMessage) -> None:
order = msg.get_json()
if already_processed(order["id"]):
return
save_and_charge(order)30. When do you use Service Bus, Storage queues, Event Grid and Event Hubs?
Service Bus is for business messages that must not be lost: topics with subscriptions, sessions for ordered processing, dead-lettering, duplicate detection and transactions, as in order processing. Storage queues are simpler and suit basic background work with a large backlog. Event Grid pushes discrete events, such as a blob being created, to handlers with filtering and retries. Event Hubs ingests high-volume streams such as telemetry or clickstream, with partitions and consumer groups, and speaks the Kafka protocol. Using Event Hubs for commands is a common design mistake.
31. What types of shared access signature (SAS) exist in Azure Storage, and which should you prefer?
A SAS is a signed token that grants limited rights, such as read on one blob until a set time. A user delegation SAS is signed with a key obtained using Microsoft Entra credentials and is the recommended kind for Blob storage. A service SAS and an account SAS are signed with the account key: anyone holding the key can create them, and revoking means rotating the key unless you used a stored access policy. Keep expiry short, grant only the needed permissions, allow HTTPS only, and consider disabling Shared Key authorization.
az storage blob generate-sas --account-name stpayslips \
--container-name slips --name 2025-03/emp1042.pdf \
--permissions r --expiry 2025-04-01T10:00Z \
--auth-mode login --as-user --https-only32. What does this Blob lifecycle management policy do?
A lifecycle policy moves or deletes blobs by age automatically, which cuts cost without code. This rule applies to block blobs whose names start with applogs/, and a prefix always begins with the container name. 30 days after a blob was last modified it moves to Cool, after 90 days to Archive, and after 365 days it is deleted. The policy runs in the background, so changes are not instant. Watch early deletion charges when moving data to Cool or Archive too soon, and remember archived blobs must be rehydrated before anyone can read them.
{
"rules": [
{
"enabled": true,
"name": "age-out-app-logs",
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "applogs/" ]
},
"actions": {
"baseBlob": {
"tierToCool": { "daysAfterModificationGreaterThan": 30 },
"tierToArchive": { "daysAfterModificationGreaterThan": 90 },
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}
]
}33. What is the difference between a service endpoint and a private endpoint?
A service endpoint lets a subnet reach a service such as Storage or Azure SQL over the Azure backbone and lets the service firewall allow only that subnet, but the service still uses its public endpoint and IP. A private endpoint is a network interface with a private IP in your subnet for one specific resource, so traffic stays private, works from peered networks and from on-premises over VPN or ExpressRoute, and public access can be disabled. Private endpoints depend on DNS: link a private DNS zone such as privatelink.blob.core.windows.net.
34. Spoke VNets A and B are both peered with a hub VNet, but VMs in A cannot reach VMs in B. Why, and what are the fixes?
VNet peering is not transitive: A to hub plus hub to B does not give A to B. You can peer A and B directly, which gets messy as spokes grow, or route spoke traffic through a firewall or network virtual appliance in the hub: add a user-defined route in each spoke sending the other spoke's range to the firewall's private IP, and allow forwarded traffic on the peerings. Azure Virtual Network Manager or Virtual WAN can manage this at scale. Address spaces must not overlap, or the peering cannot be created at all.
az network route-table route create --resource-group rg-net \
--route-table-name rt-spoke-a --name to-spoke-b \
--address-prefix 10.20.0.0/16 \
--next-hop-type VirtualAppliance \
--next-hop-ip-address 10.0.1.435. Compare Azure Load Balancer, Application Gateway, Front Door and Traffic Manager.
Azure Load Balancer works at layer 4 (TCP and UDP) inside a region: fast and protocol-agnostic, good for VMs and non-HTTP traffic. Application Gateway is a regional layer 7 HTTP load balancer with path-based routing, TLS termination and an optional web application firewall. Azure Front Door is a global layer 7 entry point at Microsoft's edge with caching, WAF and failover between regions. Traffic Manager is DNS-based: it only tells clients which endpoint to use, so failover speed depends on DNS caching. For a global website Front Door is the usual choice.
36. When would you choose Azure Container Instances, Azure Container Apps or AKS?
Azure Container Instances runs a single container or a small group quickly with no orchestration, good for batch jobs or short tasks. Azure Container Apps is a serverless container platform built on Kubernetes: revisions, traffic splitting, KEDA-based autoscaling including scale to zero, and Dapr, with no cluster to manage. AKS is managed Kubernetes: Azure runs the control plane and you get the full Kubernetes API, node pools and any tooling, but you own upgrades, node sizing, networking and security setup. Start with Container Apps unless you need raw Kubernetes control.
37. Pods in AKS show ImagePullBackOff for images stored in Azure Container Registry. How do you debug and fix it?
Start with kubectl describe pod and read the events: they say whether the image or tag was not found or the pull was unauthorised. For auth, the cluster's kubelet identity needs the AcrPull role on the registry, which az aks update with --attach-acr grants, and az aks check-acr tests the pull path from the nodes. If the registry uses a private endpoint or firewall, nodes must resolve and reach it privately. Also confirm the tag really exists: pushing latest from a laptop but deploying another tag is a very common mistake.
kubectl describe pod payroll-api-7d9f8c-x2k4p -n hr
az aks update --resource-group rg-aks --name aks-hr \
--attach-acr acrhrprod
az aks check-acr --resource-group rg-aks --name aks-hr \
--acr acrhrprod.azurecr.io38. An App Service app cannot connect to Azure SQL Database, or fails now and then with transient errors. What do you check?
For constant failures check the network path: the server firewall must allow the app, but avoid the broad Allow Azure services option; better, use VNet integration plus a private endpoint for SQL with public access off. Then check sign-in: with Microsoft Entra authentication, the managed identity must exist as a database user with roles, as in the snippet. For occasional failures, Azure SQL can drop connections during reconfiguration or failover, so add retry with exponential backoff, which recent drivers support. Keep connection pooling on.
CREATE USER [app-hr-portal] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [app-hr-portal];
ALTER ROLE db_datawriter ADD MEMBER [app-hr-portal];39. Write a KQL query that shows which API operations failed most in the last hour, and explain it.
AppRequests is the request table of workspace-based Application Insights. The query keeps only the last hour, then summarize groups by operation name and computes total requests, failures and the 95th percentile duration, which shows the slow tail far better than an average. extend adds a failure rate, where 100.0 forces decimal instead of integer division, and the result is sorted and cut to ten rows. Filtering on time first keeps queries fast and cheap. In the classic Application Insights view the table is requests, with columns such as timestamp and success.
AppRequests
| where TimeGenerated > ago(1h)
| summarize total = count(), failed = countif(Success == false),
p95ms = percentile(DurationMs, 95) by Name
| extend failRate = round(100.0 * failed / total, 1)
| order by failed desc
| take 1040. What is the difference between Azure Policy, Azure RBAC and resource locks?
RBAC decides who may perform an action. Azure Policy decides what is allowed or required whoever asks: allowed regions as in the rule below, no public IPs, or a mandatory cost-centre tag. Effects include Deny, Audit, Modify and DeployIfNotExists, and remediation tasks fix existing resources. Resource locks stop accidents: CanNotDelete allows changes but blocks deletion, and ReadOnly blocks changes too, even for an Owner, until removed. Locks act on the control plane, so ReadOnly also breaks POST operations such as listing storage keys.
{
"if": {
"not": {
"field": "location",
"in": "[parameters('allowedLocations')]"
}
},
"then": {
"effect": "deny"
}
}Ready to check yourself? Take the free Microsoft Azure mock test
Microsoft Azure interview questions: Hard questions (experienced)
20 questions41. How would you organise management groups, subscriptions and policies for a company with many teams and environments?
I follow the Azure landing zone approach from the Cloud Adoption Framework. Under the tenant root, create a company management group with children such as Platform (identity, connectivity and management subscriptions), Landing Zones (Corp for internal apps, Online for internet-facing ones), Sandbox and Decommissioned. Each workload gets its own subscriptions per environment, which isolates limits, cost and access. Assign policy initiatives and RBAC at management group level so new subscriptions inherit guardrails, and keep exceptions as time-bound exemptions.
42. The Azure bill of a Pune IT services firm grew 40 percent in two months. How do you investigate and cut cost without hurting reliability?
Start with Cost Management cost analysis grouped by service, resource group and tag to find what grew, and read the Advisor cost recommendations. Usual findings: idle or oversized VMs, unattached disks, old snapshots, verbose logs flooding Log Analytics, and data egress. Act in order: delete waste, right-size, autoscale or switch dev resources off at night, move cold data to cheaper tiers, and only then commit to reservations or a savings plan for steady usage. Budgets only alert, they do not stop spending. Enforce tags with Policy so every cost has an owner.
43. Design a web application and its database to survive a full Azure region outage. What trade-offs do you discuss?
Start from the RTO and RPO the business needs. A common design: Azure Front Door in front of App Service in two regions, such as Central India and South India, with health probes sending users to the healthy region. Azure SQL in a failover group replicates asynchronously, and the app uses the listener name so the connection string does not change on failover. Storage uses GZRS or object replication, and secrets and config exist in both regions. Active-active recovers faster but costs more and needs safe concurrent writes; active-passive is cheaper. Rehearse failover.
44. Compare availability sets, availability zones and Virtual Machine Scale Sets for VM resilience.
An availability set spreads VMs over fault domains (separate racks for power and network) and update domains (rebooted at different times during platform maintenance) inside one datacenter, so it survives a rack failure or maintenance but not a datacenter outage. Availability zones put VMs in separate datacenters, surviving a zone failure at the cost of slightly higher latency between zones. Scale sets with Flexible orchestration can spread VMs over zones and fault domains and add autoscaling. For new workloads prefer zones plus a scale set behind a zone-redundant Standard Load Balancer.
45. Compare active geo-replication and failover groups in Azure SQL Database.
Active geo-replication works per database: it creates readable secondaries in other regions, you fail over each database yourself, and the app must then point to the new primary. A failover group wraps one or more databases and gives stable listener names: a read-write listener that always points to the current primary and a read-only listener for the secondary. Microsoft recommends the customer-managed failover policy so your team decides when to fail over. Replication is asynchronous in both, so a forced failover can lose recent transactions; a planned failover syncs first.
az sql failover-group create --name fg-payroll \
--resource-group rg-data --server sql-hr-cin \
--partner-server sql-hr-sin --add-db payroll \
--failover-policy Manual
# planned failover: run against the secondary server
az sql failover-group set-primary --name fg-payroll \
--resource-group rg-data --server sql-hr-sin46. How do you choose a Cosmos DB partition key, and how do you spot a hot partition?
Pick a property with many distinct values that spreads both storage and request load evenly and appears in the filters of your most frequent queries, so they stay in one partition. In a multi-tenant HR app, tenantId alone may be hot if one large customer dominates; a hierarchical key such as tenantId then employeeId, or a synthetic key, spreads it. A hot partition shows as throttled requests (HTTP 429) while total RU use looks low, and Normalized RU Consumption near 100 percent for some ranges. The key cannot be changed in place; you copy data to a new container.
47. Explain the Cosmos DB consistency levels and how you would choose one.
There are five levels. Strong gives linearizable reads, always the latest committed write, at the cost of higher write latency, and it is not available with multi-region writes. Bounded staleness lets reads lag by at most a set number of versions or a time window. Session, the default, guarantees read-your-own-writes and monotonic reads per session, which suits most user-facing apps. Consistent prefix never shows writes out of order, and Eventual has no ordering guarantee. Weaker levels mean lower latency and better availability, and Strong or Bounded staleness reads cost more RUs.
48. How does fan-out/fan-in work in Durable Functions, and why must orchestrator code be deterministic?
The orchestrator starts one activity per file, waits for all of them with task_all and sums the results, while the framework stores progress in storage so a crash resumes from history instead of starting over. Each time the orchestrator wakes up it replays its code from the beginning against that history, so the code must be deterministic: no current time, random numbers, direct I/O or HTTP calls. Use context.current_utc_datetime and put real work in activities. Calling datetime.now in an orchestrator is a classic bug, because it returns a different value on each replay.
import azure.functions as func
import azure.durable_functions as df
app = df.DFApp(http_auth_level=func.AuthLevel.FUNCTION)
@app.orchestration_trigger(context_name="context")
def process_month(context: df.DurableOrchestrationContext):
files = yield context.call_activity("list_files", None)
tasks = [context.call_activity("process_file", f)
for f in files]
results = yield context.task_all(tasks)
return sum(results)49. Explain how autoscaling works in AKS with the Horizontal Pod Autoscaler, the cluster autoscaler and KEDA.
They act at different layers. The Horizontal Pod Autoscaler changes the replica count from metrics such as CPU against each pod's resource requests; the manifest keeps 2 to 10 replicas near 70 percent CPU. KEDA, an AKS add-on, scales on event sources like Service Bus queue length and can scale to zero. The cluster autoscaler adds nodes when pods stay Pending for lack of room and removes underused nodes. So pods scale first and nodes follow. Missing resource requests is a frequent mistake: HPA percentages and bin-packing both depend on them.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: payroll-api
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: payroll-api
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 7050. How should pods in AKS access Key Vault or Storage without storing any secret?
Use Microsoft Entra Workload ID. Enable the OIDC issuer and workload identity on the cluster, create a user-assigned managed identity, and add a federated identity credential that trusts tokens for one Kubernetes service account in one namespace. Annotate that service account with the identity's client id and label the pods to use workload identity. The pod then exchanges its projected service account token for an Entra token, which the Azure SDK does for you. This replaces the deprecated pod-managed identity and keeps keys out of Kubernetes secrets.
az aks update --resource-group rg-aks --name aks-hr \
--enable-oidc-issuer --enable-workload-identity
az identity federated-credential create --name fc-payroll \
--identity-name id-payroll --resource-group rg-aks \
--issuer "$AKS_OIDC_ISSUER" \
--subject system:serviceaccount:hr:payroll-sa \
--audience api://AzureADTokenExchange51. How do you upgrade an AKS cluster with minimal disruption to running apps?
Check the available versions and any deprecated Kubernetes APIs first, and upgrade a staging cluster before production. AKS upgrades the control plane, then each node pool by adding surge nodes and cordoning and draining old nodes. Raise max surge to go faster. Every important app needs more than one replica and a PodDisruptionBudget that still allows an eviction, because a PDB allowing zero disruptions blocks the drain. For risky changes, create a new node pool, move workloads and delete the old one. Maintenance windows and auto-upgrade channels keep this routine.
az aks get-upgrades --resource-group rg-aks --name aks-hr \
--output table
az aks nodepool update --resource-group rg-aks \
--cluster-name aks-hr --name userpool --max-surge 33%52. Compare a site-to-site VPN and ExpressRoute for connecting an office datacenter to Azure.
A site-to-site VPN Gateway connects your network over encrypted IPsec tunnels across the public internet: quick to set up and cheaper, but throughput and latency depend on the internet path. ExpressRoute is a private connection through a connectivity provider into Microsoft's network, with more predictable latency and higher bandwidth, but it can take weeks to provision and is not encrypted by default. Many enterprises use ExpressRoute as the primary link with VPN as backup. For resilience use zone-redundant gateways, two circuits or locations, careful BGP routes and non-overlapping addresses.
53. After you create a private endpoint for a storage account, on-premises servers still resolve it to the public IP. Why, and how do you fix it?
Private endpoints work through DNS: the public name gets a CNAME to the privatelink name, and only a private DNS zone linked to the VNet answers that with the private IP. On-premises DNS servers cannot query Azure private zones, so they follow the public chain. Fix it with conditional forwarders on the on-premises DNS for the service domains, pointing to an Azure DNS Private Resolver inbound endpoint (or a DNS forwarder VM) in the hub, which answers from the linked zones. Test with nslookup from both sides and avoid hosts-file workarounds.
nslookup stpayslips.blob.core.windows.net
# before the fix (on-premises): public IP
# after the fix: stpayslips.privatelink.blob.core.windows.net
# with a private address such as 10.0.5.454. An App Service app calling an external payment API gets intermittent connection timeouts under load, although the API itself is healthy. What could it be?
A likely cause is SNAT port exhaustion: outbound connections to public endpoints share a limited pool of source ports per instance, and code that opens a new connection per request, such as creating a new HttpClient each time, uses them up. Confirm it with the SNAT port exhaustion detector in Diagnose and solve problems. Fix the code first: reuse clients and keep-alive connections, and pool database connections. Then cut public outbound traffic with private endpoints for Azure services, or route all outbound through VNet integration and a NAT gateway, which offers far more ports.
55. How do you design Key Vault usage for many applications and environments?
Use one vault per application per environment, such as kv-payroll-prod and kv-payroll-dev, so access, blast radius and audit logs stay small. Use the Azure RBAC permission model rather than legacy access policies, give apps only Key Vault Secrets User, and keep production vaults behind a private endpoint with public access disabled. Soft delete is always on; enable purge protection for production. Key Vault throttles heavy traffic, so cache secrets in the app rather than reading them per request. Send audit logs to Log Analytics and alert on unusual access.
56. How would you protect administrator access to an Azure tenant?
Require phishing-resistant MFA for admins through Conditional Access, block legacy authentication, and add conditions such as compliant devices. Use Privileged Identity Management so nobody holds Owner or Global Administrator permanently: people activate a role just in time, with approval, a reason and an expiry. Keep two cloud-only emergency access accounts with phishing-resistant credentials such as FIDO2 keys, excluded from policies that could lock everyone out, and alert on every sign-in. Run access reviews. Conditional Access and PIM need premium Entra licences, so check your plan.
57. How should a GitHub Actions pipeline deploy to Azure without storing a client secret?
Use workload identity federation with OpenID Connect. On an app registration or a user-assigned managed identity, add a federated credential that trusts GitHub's token issuer for one repository and one branch or environment. In the workflow, give the job id-token write permission and pass the client, tenant and subscription ids, which are identifiers, not secrets, to azure/login. GitHub issues a short-lived token that Entra ID exchanges for an access token, so nothing needs rotating or can leak. Grant a narrow role on the target resource group and protect production with environment approvals.
permissions:
id-token: write
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
- uses: azure/login@v2
with:
client-id: ${{ vars.AZURE_CLIENT_ID }}
tenant-id: ${{ vars.AZURE_TENANT_ID }}
subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
- run: az deployment group create -g rg-hr-prod -f main.bicep58. How do you design monitoring for hundreds of resources across many subscriptions without a huge log bill?
Keep few Log Analytics workspaces, often one central workspace per environment or region, with resource-context RBAC so teams see only their own data. Enforce diagnostic settings with Azure Policy (DeployIfNotExists) so new resources send logs automatically, and collect only the categories you use. For VMs, use the Azure Monitor Agent with data collection rules that filter at collection time. Enable sampling in Application Insights for busy apps. Choose table plans and retention by value, and alert on what users feel, such as error rate and latency, not every CPU spike.
59. How do you protect business-critical blob data against accidental deletion and ransomware?
Layer the protections. Enable blob and container soft delete so deleted data can be restored within the retention period, and blob versioning so every overwrite keeps the previous version. Point-in-time restore can roll block blobs back to an earlier time. For records that must never change, such as audit files, use immutable storage with time-based retention or a legal hold, locked if regulation demands it. Add a CanNotDelete lock on the account, disable Shared Key access, grant least-privilege RBAC, and keep a copy in another region with GRS or object replication.
60. In an event-driven order system on Azure, how do you avoid losing or double-processing events?
Assume at-least-once delivery everywhere and make every consumer idempotent, for example by recording processed message ids or upserting by order id. Use Service Bus for commands that matter: peek-lock and complete only after success, dead-letter queues for poison messages, duplicate detection for retried sends, and sessions when order per customer matters. For Event Grid, configure retries and a dead-letter container. If a database write succeeds but publishing fails, events are lost, so use the transactional outbox: save the event in the same transaction and publish it from there.
Practice questions for November 2026
New every month3 questions from the Microsoft Azure mock test, the way they appear in it. A new set comes on the 1st of every month. Pick your answer, then open it.
-
In Azure App Service, what does the App Service plan define?
- The region, operating system, pricing tier and instance count that the apps run on
- The programming language, framework version and startup command of each app in the plan
- The source code repository and branch that each web app deploys from
- The custom domain names and TLS certificates attached to each web app
Show the answer
Answer: The region, operating system, pricing tier and instance count that the apps run on. The plan is the set of compute the apps run on. Every app in a plan shares its instances, so scaling the plan scales all of them. Language stack, domains and deployment source are settings of each app.
-
What does adding @secure() above a string parameter do in Bicep?
- Its value is checked for strong password rules before the deployment can start
- Its value is encrypted with your own key from Key Vault during the deployment
- Its value is not logged in deployment history and not shown in the portal
- Its value can only be supplied from a Key Vault reference in a parameters file
Show the answer
Answer: Its value is not logged in deployment history and not shown in the portal. Secure parameters are treated as secrets by ARM, so their values are kept out of deployment history and logs. You can still pass them from Key Vault with getSecret, but never return them as plain outputs.
-
Pods never get scheduled onto a new Spot node pool. What is the usual reason?
- Spot node pools accept only DaemonSets, and normal Deployments are refused at all
- Spot nodes stay powered off until the first eviction notice is received
- Spot node pools get a taint, so pods need a matching toleration to run on them
- Spot node pools can only run Windows containers built for that purpose
Show the answer
Answer: Spot node pools get a taint, so pods need a matching toleration to run on them. AKS taints Spot nodes with kubernetes.azure.com/scalesetpriority=spot:NoSchedule, so only pods that tolerate eviction land there. Add the toleration, and usually node affinity, to the workloads meant for Spot.
Ready to apply?
There are 3,277 open jobs asking for Microsoft Azure on CoreHRx right now. Create a free profile once and apply with it.