{"id":1150,"date":"2026-07-16T22:20:03","date_gmt":"2026-07-16T16:50:03","guid":{"rendered":"https:\/\/lastroundai.com\/blog\/?post_type=iq&#038;p=1150"},"modified":"2026-07-19T09:23:29","modified_gmt":"2026-07-19T03:53:29","slug":"azure","status":"publish","type":"iq","link":"https:\/\/lastroundai.com\/interview-questions\/azure","title":{"rendered":"Azure Interview Questions (2026): 30 Most Asked, With Answers"},"content":{"rendered":"<p>A cloud engineer candidate at a 200-person fintech in Austin lost a final-round Azure loop in March 2026 over one follow-up: what actually happens to every VM, NSG, and storage account inside a resource group if someone runs <code>az group delete --yes<\/code> without a lock in place. She&#8217;d nailed every ARM template question up to that point. Then the interviewer asked what stops that command from wiping out production by accident, and the answer just wasn&#8217;t there.<\/p>\n<p>Azure still trails AWS for enterprise adoption, but not by much. In a survey of 753 cloud decision-makers this year, 83 percent of enterprises said they&#8217;re running some or significant workloads on AWS, against 79 percent on Azure, according to Flexera&#8217;s 2026 State of the Cloud Report (<a href=\"https:\/\/www.flexera.com\/blog\/finops\/flexera-2026-state-of-the-cloud-report-the-convergence-of-cloud-and-value\/\" target=\"_blank\" rel=\"noopener noreferrer\">Flexera, 2026<\/a>). A four-point gap is close enough that most cloud and DevOps roles in 2026 expect you to know Azure cold, not as a fallback for missing an AWS offer.<\/p>\n<p>Here&#8217;s an opinion that might be wrong: I think Bicep questions get asked more often than they should. Microsoft has pushed Bicep hard since 2021, and it&#8217;s a genuinely cleaner authoring experience than raw ARM JSON (<a href=\"https:\/\/learn.microsoft.com\/en-us\/azure\/azure-resource-manager\/bicep\/overview\" target=\"_blank\" rel=\"noopener noreferrer\">Microsoft Learn, Bicep overview<\/a>). But most enterprise Azure estates still running production infrastructure in 2026 have thousands of lines of ARM JSON from 2019 that nobody&#8217;s rewritten and nobody wants to touch. Testing a candidate purely on Bicep syntax skips the harder, more common skill: reading a legacy ARM template you didn&#8217;t write and safely changing one parameter without breaking the other forty resources hanging off it.<\/p>\n<p>This page covers the Azure interview questions that show up across real 2026 loops for cloud and DevOps roles: core Resource Manager concepts, VMs, storage accounts, Entra ID and identity, networking, Azure Functions, App Service, AKS, infrastructure as code, monitoring, and a handful of scenario questions that mix two or three topics into one problem.<\/p>\n<div class=\"iq-stats not-prose\"><div class=\"iq-stat\"><span class=\"iq-stat__value\">55<\/span><span class=\"iq-stat__label\">Questions<\/span><\/div><div class=\"iq-stat\"><span class=\"iq-stat__value\">Compute &amp; Identity<\/span><span class=\"iq-stat__label\">Core Topic<\/span><\/div><div class=\"iq-stat\"><span class=\"iq-stat__value\">ARM JSON vs Bicep<\/span><span class=\"iq-stat__label\">IaC Format<\/span><\/div><div class=\"iq-stat\"><span class=\"iq-stat__value\">79%<\/span><span class=\"iq-stat__label\">Azure enterprise adoption<\/span><\/div><\/div>\n<h2>Core Azure concepts: regions, resource groups, and Resource Manager<\/h2>\n<p>Every Azure loop opens here, even for senior candidates. It reads as throat-clearing, but a shaky answer on resource groups is usually the first thing that makes an interviewer start probing harder on everything that follows.<\/p>\n<div class=\"iq-dsec iq-dsec--easy\"><div class=\"iq-dsec__row\"><h2 class=\"iq-dsec__h\" id=\"easy\"><span class=\"iq-dsec__dot\" aria-hidden=\"true\"><\/span>Easy questions<\/h2><span class=\"iq-dsec__n\">9<\/span><\/div><div class=\"iq-dsec__bar\" aria-hidden=\"true\"><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What&#039;s the difference between an Azure region, an availability zone, and a region pair?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Fundamentals<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A region is a physical location with one or more datacenters, East US or West Europe, for example. Availability zones are physically separate datacenters within a single region, each with independent power, cooling, and networking, so a zone-redundant deployment survives one datacenter going dark.<\/p>\n<p>A region pair is two regions Microsoft has matched for disaster recovery, generally in the same geography (a couple of exceptions exist). Microsoft staggers planned platform maintenance so it doesn&#8217;t hit both halves of a pair in the same window, which is the actual reason region pairs exist beyond just &#8220;two places far apart.&#8221;<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What&#039;s a resource group in Azure, and what does putting resources into one actually enforce?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Fundamentals<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A resource group is a logical container for resources that share a lifecycle, not a physical boundary. Resources inside it don&#8217;t have to share a region, a VM in East US and a storage account in West Europe can sit in the same group without issue.<\/p>\n<p>What it enforces concretely is deletion and access scope. Delete the group and everything inside goes with it, no per-resource confirmation. What resource groups actually give you is one scope for RBAC, tagging, and cost reporting, not a network or geography boundary.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Managed disks vs unmanaged disks, and why does almost nobody deliberately pick unmanaged today?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Compute<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Managed disks are handled entirely by Azure, storage placement, redundancy, and IOPS scaling included, you just pick a size and a tier. Unmanaged disks require you to manage the underlying storage account yourself, which means watching IOPS limits per account so one busy VM doesn&#8217;t quietly throttle every other VM sharing that account.<\/p>\n<p>Microsoft&#8217;s been steering people toward managed disks since 2017, and that per-account IOPS ceiling is why almost nobody chooses unmanaged for a new build today.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">A storage account offers blob, queue, table, and file storage, what&#039;s each one actually for?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Storage<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Blob storage holds unstructured data, images, backups, log files, anything you&#8217;d otherwise dump on a filesystem. Queue storage is a simple message queue for decoupling components, one part of an app drops a message, a worker picks it up later.<\/p>\n<p>Table storage is a NoSQL key-value store for structured data that doesn&#8217;t need relational joins. File storage exposes an SMB or NFS file share you can mount directly, useful for lift-and-shift apps that expect a real network drive rather than an API call.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">An app expects a real network drive it can map with a UNC path, not an API call, does that rule Azure out entirely?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Storage<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>No, that&#8217;s exactly what Azure Files is for. It exposes a genuine SMB or NFS file share you mount like any on-prem file server, unlike blob storage, which is accessed through REST calls and SDKs rather than a mapped drive.<\/p>\n<p>Reach for Azure Files for lift-and-shift apps that read and write through normal filesystem calls, and reach for blob storage for anything built API-first, images, backups, log archives. Azure NetApp Files sits a tier above both, for workloads that need enterprise NFS performance neither blob nor standard Azure Files can hit, though it&#8217;s rare that a workload genuinely needs it.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What&#039;s a Network Security Group, and where can you attach one?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Networking<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>An NSG is a stateful firewall, a set of allow and deny rules evaluated by priority number, that filters traffic in and out of resources. You can attach one to a subnet, a network interface, or both at once.<\/p>\n<p>Attached at both levels, traffic has to clear both rule sets, whichever one denies first wins. A rule that looks fine on the NIC can still get blocked by a stricter subnet-level NSG a candidate forgot was even there.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Public Load Balancer vs internal Load Balancer, what&#039;s actually different beyond one having a public IP and the other not?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Networking<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A public Load Balancer distributes inbound internet traffic across a backend pool of VMs or scale set instances, and it&#8217;s also what gives those VMs outbound internet access by default through SNAT. An internal Load Balancer only ever gets a private IP inside a VNet, used for a mid-tier or database layer that only the app tier in front of it should reach at all.<\/p>\n<p>Both operate at Layer 4, TCP and UDP only, with no inspection of HTTP headers or paths. Anything a routing decision needs to make based on URL path or hostname belongs to Application Gateway instead, not to Load Balancer.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Triggers and bindings in Azure Functions, what&#039;s the actual difference?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Serverless<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A trigger is what starts an execution, an HTTP request, a new blob, a queue message, a timer, every function has exactly one. Bindings are optional, declarative connections to other services for input or output, without you writing SDK calls yourself.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">json<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-json\">\n\n{\n\n  \u201cbindings\u201d: [\n\n    {\n\n      \u201ctype\u201d: \u201chttpTrigger\u201d,\n\n      \u201cdirection\u201d: \u201cin\u201d,\n\n      \u201cname\u201d: \u201creq\u201d,\n\n      \u201cmethods\u201d: [\u201dget\u201d, \u201cpost\u201d]\n\n    },\n\n    {\n\n      \u201ctype\u201d: \u201chttp\u201d,\n\n      \u201cdirection\u201d: \u201cout\u201d,\n\n      \u201cname\u201d: \u201cres\u201d\n\n    },\n\n    {\n\n      \u201ctype\u201d: \u201cqueue\u201d,\n\n      \u201cdirection\u201d: \u201cout\u201d,\n\n      \u201cname\u201d: \u201coutputQueueItem\u201d,\n\n      \u201cqueueName\u201d: \u201coutqueue\u201d,\n\n      \u201cconnection\u201d: \u201cAzureWebJobsStorage\u201d\n\n    }\n\n  ]\n\n}\n<\/code><\/pre><\/div><\/p>\n<p>A function can bind straight to a Cosmos DB document or drop a message onto a Service Bus queue just by declaring it here, no client SDK code required.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What&#039;s the difference between a node and a node pool in AKS terms?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">AKS<\/span><span class=\"iq-badge iq-badge--easy\">Easy<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A node is a single VM running the Kubernetes agent and hosting pods. A node pool is a group of nodes sharing the same VM size and configuration. Every AKS cluster needs at least one system node pool for core cluster components, and you can add user node pools with different VM sizes, GPU-enabled nodes alongside cheaper burstable ones, for example.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-dsec iq-dsec--medium\"><div class=\"iq-dsec__row\"><h2 class=\"iq-dsec__h\" id=\"medium\"><span class=\"iq-dsec__dot\" aria-hidden=\"true\"><\/span>Medium questions<\/h2><span class=\"iq-dsec__n\">33<\/span><\/div><div class=\"iq-dsec__bar\" aria-hidden=\"true\"><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What is Azure Resource Manager, and what problem does it solve that clicking around the portal doesn&#039;t?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">ARM<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>ARM is the deployment and management layer every Azure interaction goes through, whether it comes from the portal, the CLI, PowerShell, Terraform, or a raw REST call. Every one of those tools ends up hitting the same ARM API underneath (<a href=\"https:\/\/learn.microsoft.com\/en-us\/azure\/azure-resource-manager\/management\/overview\" target=\"_blank\" rel=\"noopener noreferrer\">Microsoft Learn, Azure Resource Manager overview<\/a>).<\/p>\n<p>What that actually buys you: consistent RBAC enforcement no matter which access path someone used, and templated, repeatable deployments instead of clicking the same eleven settings by hand every time a new environment gets spun up. A minimal ARM template just needs a schema, a content version, and a resources array:<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">json<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-json\">\n\n{\n\n  \u201c$schema\u201d: \u201chttps:\/\/schema.management.azure.com\/schemas\/2019-04-01\/deploymentTemplate.json#\u201d,\n\n  \u201ccontentVersion\u201d: \u201c1.0.0.0\u201d,\n\n  \u201cparameters\u201d: {\n\n    \u201cstorageAccountName\u201d: {\n\n      \u201ctype\u201d: \u201cstring\u201d\n\n    }\n\n  },\n\n  \u201cresources\u201d: [\n\n    {\n\n      \u201ctype\u201d: \u201cMicrosoft.Storage\/storageAccounts\u201d,\n\n      \u201capiVersion\u201d: \u201c2023-01-01\u201d,\n\n      \u201cname\u201d: \u201c[parameters(\u2018storageAccountName\u2019)]\u201d,\n\n      \u201clocation\u201d: \u201c[resourceGroup().location]\u201d,\n\n      \u201csku\u201d: { \u201cname\u201d: \u201cStandard_LRS\u201d },\n\n      \u201ckind\u201d: \u201cStorageV2\u201d\n\n    }\n\n  ]\n\n}\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How do management groups, subscriptions, and resource groups actually nest together, and why would a company need more than one subscription?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Fundamentals<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A subscription is the billing boundary and also a scale boundary, quotas like maximum VNets per region or maximum resource groups apply per subscription, not per tenant. A management group sits above subscriptions purely for governance, letting one Azure Policy assignment or one RBAC role apply across a dozen subscriptions at once instead of copying the same setting into each one by hand.<\/p>\n<p>Multiple subscriptions become necessary once billing genuinely needs to separate, dev versus prod, or one subscription per business unit for clean chargeback, or once a workload hits a subscription-level quota that support won&#8217;t just raise on request. A four-level hierarchy, tenant root group, one management group per environment, subscription, resource group, is common on paper, though most mid-size companies get by fine with two or three subscriptions total.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Availability Set vs Availability Zone for VMs, what&#039;s the actual difference?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Compute<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>An Availability Set groups VMs across fault domains and update domains within a single datacenter, so a hardware failure or a planned maintenance window in one domain doesn&#8217;t take out every VM at once. An Availability Zone spreads VMs across physically separate datacenters in the same region entirely.<\/p>\n<p>Zones protect against losing a whole datacenter. Sets only protect against losing a rack or a maintenance window inside one. You can&#8217;t mix the two on a single VM, an instance is either zonal or in a set, never both at once.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What&#039;s a VM Scale Set, and when do you reach for one instead of provisioning VMs manually?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Compute<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A VM Scale Set manages a group of identical, load-balanced VMs as one resource, and it can scale the count up or down automatically off a metric like CPU or queue length. Reach for one the moment you need more than a handful of interchangeable VMs behind a load balancer, or any autoscaling requirement at all.<\/p>\n<p>Provisioning VMs by hand still works fine for a single always-on box, a jump server or a one-off batch job, but it falls apart the second &#8220;how many do we need&#8221; stops being a fixed number.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How do you actually pick a VM size for a new workload instead of grabbing whatever shows up first in the portal&#039;s dropdown?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Compute<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Start with the family, not the size. General-purpose Dv5 balances CPU and memory for typical app servers, Ev5 adds more memory per core for databases and in-memory caches, Fv2 is compute-optimized for CPU-bound batch work, and the N-series bolts on GPUs for ML training or rendering.<\/p>\n<p>Size within the family based on measured usage, not a guess. A burstable B-series instance is often the cheaper right answer for a dev box that sits idle most of the day and only needs headroom for occasional spikes. Right-sizing after two or three weeks of real Azure Monitor data beats guessing on day one almost every time.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">A new VM needs software installed and configured the moment it boots, with nobody logging in by hand, how do you actually set that up?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Compute<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>On Linux, cloud-init runs on first boot and can install packages, write config files, and run commands, all from one YAML file passed in at VM creation time. On Windows, or for anything that needs to run again after the VM already exists, the Custom Script Extension downloads and executes a script from a URL or an inline command instead.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">bash<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-bash\">\n\naz vm create\n\n  \u2013resource-group prod-app-rg\n\n  \u2013name web-vm01\n\n  \u2013image Ubuntu2204\n\n  \u2013custom-data cloud-init.yml\n<\/code><\/pre><\/div><\/p>\n<p>The two aren&#8217;t interchangeable. Cloud-init only fires once, on the very first boot. Ongoing configuration drift after day one needs a real configuration tool, Ansible or a similar agent, not another custom-data payload rerun against a VM that&#8217;s already live.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What&#039;s an Azure Spot VM, and what actually happens when Azure needs that capacity back?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Compute<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A Spot VM runs on Azure&#8217;s unused capacity at a discount that can run 60 to 90 percent off list price, but Azure can evict it with as little as 30 seconds of notice the moment that capacity is needed for a regular pay-as-you-go customer. An eviction policy controls what happens next, Deallocate keeps the disk around for a later restart, Delete removes the VM outright, and an optional max price caps what you&#8217;ll pay before Azure evicts on cost alone.<\/p>\n<p>Good fit for batch jobs, CI runners, and stateless workers that can pick up wherever they left off. Wrong fit for anything stateful or customer-facing, 30 seconds isn&#8217;t enough runway to fail over gracefully.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Premium SSD, Premium SSD v2, and Ultra Disk all sound similar on paper, when does the extra cost of v2 or Ultra actually pay off?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Compute<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Standard Premium SSD bundles a fixed IOPS and throughput tier to a fixed disk size, want more performance and you&#8217;re paying for a bigger disk whether the extra space gets used or not. Premium SSD v2 breaks that link entirely, capacity, IOPS, and throughput get set independently and can change with no downtime, which matters for a database that needs high IOPS against a fairly small amount of storage.<\/p>\n<p>Ultra Disk goes further still, sub-millisecond latency and IOPS up to 400,000 per disk, built for the handful of workloads, SAP HANA, high-transaction SQL, where even Premium SSD v2&#8217;s ceiling isn&#8217;t enough. Most production workloads never actually need Ultra Disk. Reaching for it by default instead of profiling real IOPS first is a common way teams overspend on disk.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Storage account replication options, LRS, ZRS, GRS, RA-GRS, how do you actually pick?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Storage<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>LRS keeps three copies within a single datacenter, cheapest option, zero protection if that datacenter goes down. ZRS spreads those three copies across availability zones in the same region instead.<\/p>\n<p>GRS adds a second, geographically distant region with asynchronous replication, but that secondary copy isn&#8217;t readable until Microsoft actually fails over to it. RA-GRS is GRS plus a read-only endpoint against the secondary region at all times, which is usually the one people actually want when they say &#8220;geo-redundant&#8221; and don&#8217;t realize plain GRS doesn&#8217;t let you read the backup copy during normal operation.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Hot, cool, cold, and archive blob tiers, what&#039;s the actual cost tradeoff, and how do you avoid babysitting it by hand?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Storage<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Hot costs the most per GB stored and the least per read, meant for data touched constantly. Cool and cold step storage cost down while raising the cost per access, meant for data touched monthly or less. Archive is by far the cheapest tier for storage, but data isn&#8217;t instantly available, rehydrating a blob out of archive can take hours, not seconds.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">json<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-json\">\n\n{\n\n  \u201crules\u201d: [\n\n    {\n\n      \u201cname\u201d: \u201cmoveOldLogsToArchive\u201d,\n\n      \u201ctype\u201d: \u201cLifecycle\u201d,\n\n      \u201cdefinition\u201d: {\n\n        \u201cactions\u201d: {\n\n          \u201cbaseBlob\u201d: {\n\n            \u201ctierToCool\u201d: { \u201cdaysAfterModificationGreaterThan\u201d: 30 },\n\n            \u201ctierToArchive\u201d: { \u201cdaysAfterModificationGreaterThan\u201d: 90 }\n\n          }\n\n        },\n\n        \u201cfilters\u201d: { \u201cblobTypes\u201d: [\u201dblockBlob\u201d], \u201cprefixMatch\u201d: [\u201dlogs\/\u201d] }\n\n      }\n\n    }\n\n  ]\n\n}\n<\/code><\/pre><\/div><\/p>\n<p>A lifecycle management policy like this one automates the tier transitions on a schedule instead of relying on someone to remember to move old data every quarter, which in practice never happens consistently.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Entra ID vs Active Directory Domain Services, what&#039;s the actual difference?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Identity<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Microsoft renamed Azure Active Directory to Microsoft Entra ID in 2023, same service, new name, so don&#8217;t be thrown if an interviewer uses either term. Entra ID is a cloud identity provider built around REST APIs, OAuth, and SAML, it doesn&#8217;t support classic on-prem concepts like Group Policy or NTLM.<\/p>\n<p>Active Directory Domain Services is the traditional on-prem directory, LDAP and Kerberos included. Azure&#8217;s managed, cloud-hosted version of that classic directory service exists for lift-and-shift apps that still need it, and it&#8217;s a genuinely different product from Entra ID, not a renamed version of the same thing.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">RBAC scope levels, management group, subscription, resource group, resource, how does the nesting actually work?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">RBAC<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Role assignments made higher up cascade down through everything beneath them. Assign Contributor at a management group and every team touching any subscription under it inherits Contributor, whether that&#8217;s what anyone intended or not.<\/p>\n<p>The safer default is assigning roles as low in the hierarchy as the job actually requires, resource group or single-resource scope, rather than reaching for subscription-level access because it&#8217;s the option people notice first in the portal.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">If managed identities remove the need to store any credential at all, why does anyone still use a service principal?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Identity<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A managed identity only exists for the lifetime of the Azure resource it&#8217;s attached to, and nothing outside Azure can authenticate as it. A service principal is a standalone identity that works from anywhere, a GitHub Actions runner, a script on someone&#8217;s laptop, an on-prem server, anything authenticating to Azure from outside Azure&#8217;s own resources.<\/p>\n<p>Rule of thumb: if the thing authenticating is itself an Azure resource, use a managed identity and skip credential management entirely. If it&#8217;s external to Azure, a service principal with a certificate or a federated credential (avoid a plain client secret where the option exists) is the only path left.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">A built-in role always grants one permission too many or too few for a given team, when do you actually build a custom role instead of picking the closest built-in?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">RBAC<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>When the closest built-in, Contributor say, grants delete rights on a resource type a support engineer should never touch, or when a team needs to restart VMs but not resize or remove them, no built-in role draws that exact line. A custom role definition lists specific allowed actions, specific denied actions, and the scopes it&#8217;s assignable at.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">json<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-json\">\n\n{\n\n  \u201cName\u201d: \u201cVM Restart Operator\u201d,\n\n  \u201cIsCustom\u201d: true,\n\n  \u201cActions\u201d: [\n\n    \u201cMicrosoft.Compute\/virtualMachines\/start\/action\u201d,\n\n    \u201cMicrosoft.Compute\/virtualMachines\/restart\/action\u201d,\n\n    \u201cMicrosoft.Compute\/virtualMachines\/read\u201d\n\n  ],\n\n  \u201cNotActions\u201d: [],\n\n  \u201cAssignableScopes\u201d: [\u201d\/subscriptions\/&lt;sub-id&gt;\/resourceGroups\/prod-app-rg\u201d]\n\n}\n<\/code><\/pre><\/div><\/p>\n<p>Custom roles earn their setup cost once the same narrow permission set gets assigned across teams repeatedly. For a one-off, scoping a built-in role tightly to a single resource group is usually less long-term maintenance than owning a custom role definition.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">A database password stored in Key Vault needs to rotate every 90 days, how does that work without breaking every app that&#039;s already pointing at the old value?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Security<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Every update to a secret creates a new version rather than overwriting the old one, and each version carries its own identifier and its own expiration date. Apps referencing the secret without pinning to a specific version pick up the latest one automatically on their next read, no code change or redeploy required.<\/p>\n<p>Key Vault can trigger rotation on a schedule and call an Azure Function to generate and write the new value, and for supported resource types like storage account keys there&#8217;s a built-in rotation policy that handles the whole cycle with no custom code at all. Old versions stay retrievable rather than vanishing, useful for the one time a rotation breaks something and the previous value needs pulling back immediately while someone debugs.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What does Microsoft Defender for Cloud actually catch that plain Azure Monitor wouldn&#039;t?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Security<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Azure Monitor watches performance and availability, CPU, latency, error rates. Defender for Cloud watches for security misconfiguration and active threats specifically, a storage account left open to the public internet, a VM missing months of patches, a login from a country nobody on the team has ever traveled to, and it rolls all of it into a secure score you can track improving or slipping over time.<\/p>\n<p>The free tier gives recommendations and the secure score. The paid tier, priced per resource type, adds actual threat detection, alerting on a brute-force attempt against a VM or an unusual Key Vault access pattern rather than only flagging static misconfiguration. Most teams run the free tier everywhere and turn on paid protection only for the resource types actually facing the internet.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">When does Application Gateway actually replace Load Balancer instead of sitting alongside it?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Networking<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Application Gateway operates at Layer 7 and can route based on URL path or hostname, terminate SSL, and run a Web Application Firewall in front of the backend, none of which Load Balancer does since it only ever sees TCP and UDP packets. Send \/api\/* to one backend pool and \/images\/* to another from the same public entry point, something Load Balancer simply has no concept of.<\/p>\n<p>They&#8217;re not always either-or. A common pattern puts Application Gateway in front for HTTP-aware routing and WAF, with an internal Load Balancer behind it distributing traffic to a tier that doesn&#8217;t need any Layer 7 logic at all. Picking Application Gateway purely for the WAF feature, with no path-based routing need in sight, is a fine reason on its own for anything internet-facing.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Azure routes traffic inside a VNet automatically by default, when do you actually need a user-defined route to override that?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Networking<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Default system routes handle traffic between subnets in the same VNet, to peered VNets, and out to the internet with zero configuration. A UDR overrides that default the moment traffic needs to go somewhere the system route wouldn&#8217;t send it, forcing all outbound traffic through a network virtual appliance or firewall instead of straight out to the internet, for example.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">bash<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-bash\">\n\naz network route-table route create\n\n  \u2013resource-group prod-network-rg\n\n  \u2013route-table-name prod-rt\n\n  \u2013name force-through-firewall\n\n  \u2013address-prefix 0.0.0.0\/0\n\n  \u2013next-hop-type VirtualAppliance\n\n  \u2013next-hop-ip-address 10.0.1.4\n<\/code><\/pre><\/div><\/p>\n<p>The classic mistake: a UDR routes everything through a firewall appliance, then someone adds a new subnet and forgets to associate the route table with it, and that subnet&#8217;s traffic quietly bypasses the firewall entirely with no error or warning anywhere in sight.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Consumption vs Premium vs Dedicated hosting plan for Azure Functions, and what&#039;s cold start actually about?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Serverless<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Consumption plan scales to zero and you pay per execution, but an idle function has to spin up a fresh instance on the next request, that&#8217;s cold start, and it can add anywhere from a few hundred milliseconds to several seconds depending on runtime and package size.<\/p>\n<p>Premium plan keeps a configurable number of instances warm at all times, eliminating cold start at a fixed baseline cost. Dedicated plan runs functions on VMs you&#8217;re already paying for, so cold start isn&#8217;t a concern at all, but you lose the pay-per-execution economics that make Consumption attractive for spiky, low-volume workloads.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What&#039;s a deployment slot, and how does slot swapping actually work?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">App Service<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A deployment slot is a separate, fully live instance of your App Service, staging next to production, each with its own hostname and settings. Swapping two slots doesn&#8217;t copy files around, it&#8217;s a virtual IP and configuration swap, so the instance that was &#8220;staging&#8221; a second ago is serving production traffic instantly, and vice versa.<\/p>\n<p>App settings marked &#8220;sticky&#8221; don&#8217;t swap, which is exactly how you keep a slot&#8217;s own connection string or feature flag from following it into production by mistake. (Side note: the portal&#8217;s blade names rarely match the actual ARM resource type, App Service is <code>Microsoft.Web\/sites<\/code> everywhere else, which trips up more scripting exercises than it should.)<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How do you actually configure App Service to scale out under load instead of babysitting instance count by hand?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">App Service<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>An autoscale setting on the App Service plan defines rules keyed to a metric, CPU percentage or HTTP queue length are the common ones, with a scale-out rule (add an instance when CPU passes 70 percent for 10 minutes) and a scale-in rule (remove one below 30 percent), plus a minimum and maximum instance count so it can never scale to zero or run away unbounded.<\/p>\n<p>Cooldown periods matter here as much as the thresholds do. Skip one and a metric bouncing around the threshold triggers a scale-out and a scale-in every few minutes, instances flapping up and down instead of settling, which costs more and helps nobody.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How does AKS handle secrets and credentials for pulling images or reaching other Azure services?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">AKS<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>For pulling images from Azure Container Registry, AKS can attach directly using managed identity integration, no static credential or imagePullSecret needed at all. For pods that need to reach other Azure services, workload identity federation lets a Kubernetes service account exchange its token for an Entra ID token scoped to exactly what that workload needs, rather than a cluster-wide credential every pod could theoretically read.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Horizontal Pod Autoscaler and Cluster Autoscaler both scale AKS, what layer does each one actually operate on?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">AKS<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>HPA scales the number of pod replicas for a deployment based on CPU, memory, or a custom metric, operating entirely inside the cluster with no idea whether the nodes underneath actually have room for more pods. Cluster Autoscaler operates one layer down, adding or removing real VM nodes in a node pool once pods can&#8217;t be scheduled because every existing node is full, or removing nodes that have sat underutilized long enough.<\/p>\n<p>They work together, not in competition. HPA decides more pods are needed, scheduling fails because there&#8217;s no room, Cluster Autoscaler notices the unschedulable pods and adds a node, and the stuck pods finally land. Running HPA without Cluster Autoscaler on a fixed-size node pool just means pods pile up in Pending once capacity runs out.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">AKS needs an ingress controller to route HTTP traffic to services, why would a team pick AGIC over the more common NGINX ingress?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">AKS<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Application Gateway Ingress Controller wires an existing Application Gateway directly into the cluster as its ingress, so WAF, SSL termination, and Azure-native monitoring come from infrastructure the team may already run elsewhere, not a new component living inside the cluster. NGINX ingress runs as pods inside the cluster itself, more portable across clouds, with the larger community and more examples to copy from.<\/p>\n<p>My honest take: if Application Gateway isn&#8217;t already sitting in the environment for something else, standing one up just to get AGIC is more moving parts than most clusters actually need. NGINX ingress is the less opinionated default the moment AKS is the only thing in the picture.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">ARM templates are JSON, Bicep compiles down to ARM JSON, so what does Bicep actually buy you?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">IaC<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Cleaner syntax mainly. No bracket-matching, no giant expressions like <code>[reference(resourceId('Microsoft.Storage\/storageAccounts', variables('storageName')))]<\/code> buried three parameters deep. Bicep also gives you real modules, type-checking at authoring time instead of failing mid-deployment, and loops over resource collections without copy-pasting the same block five times.<\/p>\n<p>Functionally the two deploy identically, Bicep is just a transpiler down to the same ARM JSON. If you&#8217;d asked me in 2021 whether Bicep would replace ARM JSON outright by now, I&#8217;d have said obviously. It hasn&#8217;t, not even close. Most of what&#8217;s actually running in production predates Bicep entirely.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What&#039;s idempotency in the context of ARM\/Bicep deployments, and why does it matter?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">IaC<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Idempotent means running the same deployment twice produces the same end state, not two of everything. Deploy a Bicep file defining one storage account, run it again unchanged, and Azure recognizes the resource already matches and does nothing.<\/p>\n<p>That&#8217;s what makes IaC safe to run on every merge instead of only on the first deploy. Worth knowing too: incremental mode, the default, leaves other resources in the group alone. Complete mode deletes anything in the resource group that isn&#8217;t defined in the template, which is a real footgun if someone flips that flag without realizing what&#8217;s sitting in the group already.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What&#039;s a Bicep module, and when do you break a deployment into modules instead of one big file?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">IaC<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Once a template starts mixing genuinely unrelated concerns, networking, compute, and a database, in one file, or once two environments need to share most of the same resources with a few parameters different. A module lets you reference a separate Bicep file as a reusable unit with its own inputs and outputs, similar to calling a function instead of pasting the same fifty lines into every environment&#8217;s template.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">bicep<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-bicep\">\n\nmodule storageModule \u2018modules\/storage.bicep\u2019 = {\n\n  name: \u2018storageDeploy\u2019\n\n  params: {\n\n    storageAccountName: \u2018stprodapp001\u2019\n\n    location: resourceGroup().location\n\n    sku: \u2018Standard_ZRS\u2019\n\n  }\n\n}\noutput storageAccountId string = storageModule.outputs.storageId\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How do you actually check what a Bicep deployment is going to change before running it against production?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">IaC<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>The what-if command runs the deployment engine&#8217;s comparison logic without touching a single resource, showing exactly which resources it would create, modify, or delete, and which specific properties would change on each one.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">bash<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-bash\">\n\naz deployment group what-if\n\n  \u2013resource-group prod-app-rg\n\n  \u2013template-file main.bicep\n\n  \u2013parameters main.parameters.json\n<\/code><\/pre><\/div><\/p>\n<p>It catches the deployment that looks safe on paper but would actually recreate a resource, some property changes force a delete-and-recreate instead of an in-place update, and what-if is the only way to see that coming before it happens to something stateful, a database with real data sitting in it, instead of finding out after the fact.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Azure Monitor vs Log Analytics vs Application Insights, what&#039;s the difference?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Monitoring<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Azure Monitor is the umbrella platform, metrics, logs, and alerts across every Azure resource. Log Analytics is the query engine and workspace underneath it, where logs actually get stored and queried using Kusto Query Language.<\/p>\n<p>Application Insights is the application-performance layer built on top of that same workspace, request rates, dependency call latency, exception traces, tied to your code rather than infrastructure metrics.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How would you set up an alert that fires when a VM&#039;s CPU stays above 90 percent for 10 minutes?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Monitoring<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>An Azure Monitor metric alert rule scoped to that VM, condition set on the Percentage CPU metric with a 90 threshold, evaluated over a 10-minute window, wired to an action group for email or a webhook.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">bash<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-bash\">\n\naz monitor metrics alert create\n\n  \u2013name high-cpu-prod-vm01\n\n  \u2013resource-group prod-app-rg\n\n  \u2013scopes \/subscriptions\/&lt;sub-id&gt;\/resourceGroups\/prod-app-rg\/providers\/Microsoft.Compute\/virtualMachines\/prod-vm01\n\n  \u2013condition \u201cavg Percentage CPU &gt; 90\u201d\n\n  \u2013window-size 10m\n\n  \u2013evaluation-frequency 5m\n\n  \u2013action high-cpu-action-group\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">How do you actually pull structured, queryable data out of Azure Monitor instead of clicking through the portal&#039;s default charts?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Monitoring<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Diagnostic settings on any resource route its logs and metrics into a Log Analytics workspace. From there, Kusto Query Language is what turns raw log rows into something queryable, filterable, and chartable, closer to a SQL SELECT than a static dashboard tile.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">kql<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-kql\">\n\nAppRequests\n\n| where TimestampTime &gt; ago(1h)\n\n| where ResultCode == \u201c500\u201d\n\n| summarize FailureCount = count() by bin(TimestampTime, 5m), Name\n\n| order by TimestampTime desc\n<\/code><\/pre><\/div><\/p>\n<p>That query surfaces exactly which endpoint is throwing 500s in five-minute buckets over the last hour, the kind of question a default metrics chart can&#8217;t answer without KQL doing the actual filtering and grouping underneath it. Saved queries turn into workbooks, and workbooks turn into the dashboard a team actually checks every morning instead of the default blade nobody bothers to customize.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Reserved Instances, Savings Plans, and Spot pricing are all ways to pay less than list price for compute, how do you actually decide between them?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Cost<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A Reserved Instance commits to a specific VM size in a specific region for one or three years for up to 72 percent off, the biggest discount of the three, but it&#8217;s locked to that exact size, switch VM families later and the reservation stops matching what&#8217;s actually running. A Savings Plan commits to a dollar amount of compute spend per hour instead of a specific size, a smaller discount than a matched Reserved Instance but flexible enough to shift across VM families, regions, and even container instances without losing the discount.<\/p>\n<p>Spot, covered earlier for VMs specifically, isn&#8217;t a commitment at all, no upfront spend, just whatever unused capacity is available at whatever price Azure sets that hour, eviction as the tradeoff. Stable, predictable production workloads fit Reserved Instances or Savings Plans. Anything that tolerates interruption fits Spot, and most production estates end up running a mix of all three rather than betting everything on one pricing model. I don&#8217;t have solid numbers on how Savings Plans perform for container instances specifically, most of what I&#8217;ve seen written up is VM-focused.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">A subscription&#039;s monthly bill keeps creeping up with no obvious new project driving it, where do you actually look first?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Cost<\/span><span class=\"iq-badge iq-badge--medium\">Medium<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Azure Advisor&#8217;s cost recommendations surface the boring, high-impact stuff automatically, VMs running under 5 percent average CPU that could downsize a tier or two, disks attached to nothing at all, and Reserved Instance purchase suggestions based on actual usage over the last 30 days.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">bash<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-bash\">\n\naz advisor recommendation list\n\n  \u2013category Cost\n\n  \u2013output table\n<\/code><\/pre><\/div><\/p>\n<p>Cost Management&#8217;s own analysis view breaks spend down by resource group, tag, or meter, so a creeping increase gets attributed to something specific instead of staying a mystery line on the invoice. In practice, forgotten dev and test resources that never got torn down after a project wrapped are the single most common source of unexplained cost growth, well ahead of anything tied to actual production traffic.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-dsec iq-dsec--hard\"><div class=\"iq-dsec__row\"><h2 class=\"iq-dsec__h\" id=\"hard\"><span class=\"iq-dsec__dot\" aria-hidden=\"true\"><\/span>Hard questions<\/h2><span class=\"iq-dsec__n\">13<\/span><\/div><div class=\"iq-dsec__bar\" aria-hidden=\"true\"><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">If you delete a resource group, what actually happens to everything inside it, and how do you stop it from happening by accident?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Resource Groups<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Every resource inside gets deleted along with it, no per-item confirmation, even resources you didn&#8217;t personally create and might not remember are sitting in there. Azure doesn&#8217;t ask &#8220;are you sure&#8221; per resource, only once for the group.<\/p>\n<p>The two real safeguards: a resource lock, CanNotDelete or ReadOnly, set at the resource group or resource level, and RBAC scoped tightly instead of handing out Contributor at the subscription level by default. A lock on the group is the one that would&#8217;ve actually caught the scenario from the top of this page.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">bash<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-bash\">\n\naz lock create\n\n  \u2013name dont-delete-prod-rg\n\n  \u2013resource-group prod-app-rg\n\n  \u2013lock-type CanNotDelete\n\n  \u2013notes \u201cProduction resources, remove lock before deleting anything\u201d\n<\/code><\/pre><\/div><br \/>\n<\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">A third-party vendor needs temporary access to one blob container, why not just hand them a storage account key?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Storage<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A storage account key grants full control over every container and every blob in the entire account, and it doesn&#8217;t expire until someone rotates it manually. Handing that to a vendor for one container means they could read, write, or delete anything else in the account too, indefinitely, until someone remembers to rotate the key.<\/p>\n<p>A shared access signature scopes access down to exactly what&#8217;s needed, one container, read-only, expiring in 24 hours, and can be revoked early by rotating the stored access policy it&#8217;s tied to, no need to touch the account key at all. User delegation SAS goes further still, tying the token to an Entra ID identity instead of the account key, so audit logs show a named principal rather than an anonymous holder of a shared secret.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What&#039;s a managed identity, and why does it beat a connection string sitting in app config?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Identity<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A managed identity is an identity Azure creates and manages for a resource, a VM, a Function App, an App Service, so that resource can authenticate to other Azure services with no credential ever stored in code or config. System-assigned identities live and die with the resource; user-assigned identities exist independently and can attach to multiple resources at once.<\/p>\n<p>The real security win is that there&#8217;s nothing to leak. A hardcoded connection string in app settings is a standing secret that outlives the deployment. A managed identity&#8217;s token gets issued on demand and expires, and there&#8217;s nothing sitting in a repo or a config blade for someone to accidentally commit.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What&#039;s Privileged Identity Management, and how is it different from just assigning someone the Owner role permanently?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Identity<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>PIM makes a privileged role, Owner, Global Administrator, User Access Administrator, eligible rather than permanently active. A user eligible for a role has zero standing access until they explicitly activate it, usually with an approval step and a written justification, and the activation expires on its own after a set window, an hour, eight hours, whatever the policy allows.<\/p>\n<p>The security win is that a compromised account sitting idle carries no privileged access worth stealing, there&#8217;s nothing to use without also tripping the approval workflow and the audit trail behind it. Permanent Owner assignments are exactly the standing access PIM exists to eliminate, and most compliance frameworks in 2026 flag a permanent privileged role assignment as a finding on its own.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Key Vault has two separate permission models, access policies and Azure RBAC, why does that split exist, and which should a brand-new vault use?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Security<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Access policies are the original, vault-scoped model, permissions get set directly on the vault resource itself with no inheritance from resource group or subscription-level role assignments. Azure RBAC integration lets Key Vault permissions flow through the same role assignment system as every other Azure resource, inherited from resource group or subscription scope exactly like a storage account or a VM would be.<\/p>\n<p>Microsoft&#8217;s own guidance points new vaults toward RBAC now, mainly for consistency, one permission model across the whole estate instead of Key Vault being the one resource type that works differently from everything else. Vaults created before RBAC integration existed are often still running on access policies, and migrating a live vault between the two models mid-flight is disruptive enough that most teams leave the old ones alone rather than migrate purely for consistency&#8217;s sake.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Two VMs in different VNets need to talk to each other privately, what are your options?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Networking<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>VNet peering connects two VNets directly over Microsoft&#8217;s backbone with no public internet hop, cheapest and lowest-latency choice when both VNets are already in Azure. A VPN gateway works when one side is on-premises or in another cloud, encrypted but with more latency and a per-hour gateway cost.<\/p>\n<p>ExpressRoute is the private, dedicated-circuit option for high-throughput, low-latency connections to on-prem, at real cost and a provisioning lead time measured in weeks. For two Azure VNets specifically, peering is almost always the right first answer unless there&#8217;s a specific reason, overlapping address spaces, routing through a shared firewall appliance, to reach for something heavier.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">Private Endpoint and Service Endpoint both promise to keep traffic off the public internet, what&#039;s the real difference between them?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Networking<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>A Service Endpoint extends your VNet&#8217;s identity to a service like a storage account or SQL database, traffic still travels Microsoft&#8217;s backbone instead of the public internet, but the service itself keeps its public IP and public DNS name, just with network rules restricting which VNets can reach it. A Private Endpoint goes further and assigns the service an actual private IP inside your VNet, with its own network interface, so it shows up as if it were just another resource sitting on your subnet.<\/p>\n<p>The practical difference shows up in hybrid scenarios. A Private Endpoint reaches from on-prem over ExpressRoute or VPN with no extra configuration since it&#8217;s just a private IP. A Service Endpoint can&#8217;t, it only works for traffic starting inside the same VNet or a peered one, which rules it out for exactly the hybrid setups a Private Endpoint handles without issue.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">What are Durable Functions, and what problem do they solve that plain Functions can&#039;t?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Serverless<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Plain Azure Functions are stateless and short-lived by design, each execution starts fresh with no memory of the last one. Durable Functions add an orchestration layer that can pause for hours or days, wait on external events, and fan out to dozens of parallel activities and fan back in, all while checkpointing state so an orchestration survives the host restarting mid-run.<\/p>\n<p>The classic use case is a multi-step approval workflow. Submit, wait for a human sign-off that might take three days, then continue, something a plain function has no mechanism to express on its own.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">App Service vs Azure Functions vs AKS, how do you actually decide?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Architecture<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>App Service fits a traditional always-on web app or API where you want managed scaling, deployment slots, and custom domains without touching Kubernetes. Azure Functions fits event-driven, bursty, or scheduled work where paying only for execution time matters more than keeping an instance warm.<\/p>\n<p>AKS is the answer once you need fine-grained control over the runtime itself, multiple services with different resource profiles, custom networking, sidecar patterns, or you&#8217;re already running Kubernetes elsewhere and want one operational model everywhere. My honest read: most teams reach for AKS a step earlier than they need to. App Service or Functions handles a surprising amount of real production traffic without the ongoing cluster-maintenance tax.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">A storage account&#039;s costs tripled overnight with no code deploys, what do you check?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Scenario<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Check the storage account&#8217;s transaction metrics first, not just capacity. A spike in read or write transaction count with no change in stored data usually means something&#8217;s hammering it with requests rather than storing more.<\/p>\n<p><div class=\"iq-code not-prose\"><div class=\"iq-code__bar\"><span class=\"iq-code__lang\">bash<\/span><button class=\"iq-code__copy\" type=\"button\">Copy<\/button><\/div><pre><code class=\"language-bash\">\n\naz monitor metrics list\n\n  \u2013resource \/subscriptions\/&lt;sub-id&gt;\/resourceGroups\/prod-app-rg\/providers\/Microsoft.Storage\/storageAccounts\/stprodapp001\n\n  \u2013metric Transactions\n\n  \u2013interval PT1H\n\n  \u2013aggregation Total\n<\/code><\/pre><\/div><\/p>\n<p>Common culprits: a retry loop somewhere gone wrong hammering the same blob repeatedly, a new consumer accidentally pointed at production instead of a test container, or a lifecycle management policy that stopped tiering anything to cool storage, so everything&#8217;s billing at hot-tier rates.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">You need to migrate a monolithic app to Azure with minimal downtime and no rewrite budget, what&#039;s your approach?<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Scenario<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Lift-and-shift onto App Service or a set of VMs first, not a rewrite, the goal here is minimal downtime, not architectural purity. Use deployment slots to warm up the new environment fully before cutover, swap once health checks pass, and keep the old environment running for a rollback window instead of tearing it down the moment the swap looks fine.<\/p>\n<p>Database migration is usually the actual risk, not the app tier. Azure Database Migration Service, or a read-replica-then-cutover pattern, keeps write downtime down to the seconds it takes to flip a connection string, rather than hours of a full export and import.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">A pod keeps getting OOMKilled, walk through how you&#039;d diagnose it.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Troubleshooting<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Start with <code>kubectl describe pod<\/code>, the events section usually shows OOMKilled directly along with the exit code. Then check whether the memory limit is actually undersized for real load, <code>kubectl top pod<\/code> against the same pod, or Container Insights in Log Analytics if metrics-server access is limited, shows actual usage against the configured limit.<\/p>\n<p>It&#8217;s not always a limits problem. A memory leak that grows unbounded will eventually blow past any limit you set, so watching whether usage climbs steadily over hours versus spiking under one specific request pattern tells you whether to raise the limit or go find the leak.<\/p>\n<p><\/div><\/div><\/div>\n<div class=\"iq-qa\"><button class=\"iq-qa__q\" type=\"button\" aria-expanded=\"false\"><span class=\"iq-qa__qtext\">App Service is returning intermittent 502s, walk through how you&#039;d debug it.<\/span><span class=\"iq-qa__meta\"><span class=\"iq-qa__tag\">Scenario<\/span><span class=\"iq-badge iq-badge--hard\">Hard<\/span><span class=\"iq-qa__chev\" aria-hidden=\"true\"><\/span><\/span><\/button><div class=\"iq-qa__a\"><div class=\"iq-qa__a-inner\"><\/p>\n<p>Start with the App Service diagnostics blade and actual application logs, <code>az webapp log tail<\/code> streams them live and usually shows whether the app is throwing an unhandled exception or just timing out. A 502 from App Service specifically often means the worker process crashed or restarted mid-request, so check the health-check and container-restart events under Diagnose and Solve Problems before assuming it&#8217;s a networking issue.<\/p>\n<p>If logs look clean, check whether the 502s correlate with scale-out events or slot swaps. A cold instance spinning up under load is a common, boring cause that gets missed while everyone&#8217;s staring at application code.<\/p>\n<p><\/div><\/div><\/div>\n<h2>How to prepare for an Azure interview in 2026<\/h2>\n<p>Skip another slide deck of service names and pricing tiers. Build one small thing end to end instead: a resource group with a VNet, one VM or App Service instance, a storage account, and an NSG that locks down anything public-facing. Then break it on purpose. Delete a lock and see what actually happens, swap a deployment slot and watch which settings follow it and which stay behind, misconfigure an NSG priority and trace why the rule you expected to win didn&#8217;t. Fixing your own mistakes teaches the mental model faster than reading about it does.<\/p>\n<p>Across mock interview sessions run through LastRoundAI&#8217;s cloud and DevOps track, the stumble that shows up most often isn&#8217;t a missing service name. It&#8217;s candidates who know AKS conceptually, pods, deployments, services, but freeze the moment a follow-up gets AKS-specific: how does this cluster actually authenticate to the container registry without a static credential sitting in a secret somewhere. That one trips up candidates who&#8217;ve clearly used Kubernetes, just not Azure&#8217;s identity plumbing around it. I don&#8217;t have good numbers on how this holds up for pure data-platform roles, Synapse, Data Factory, this page is written from an infrastructure and DevOps angle, not a data-engineering one.<\/p>\n<h2>Get the reps in before the real thing<\/h2>\n<p>Reading answers to Azure interview questions is not the same as defending them live once someone changes one variable on you mid-answer. LastRoundAI&#8217;s <a href=\"\/products\/mock-interviews\">mock interview mode<\/a> runs cloud and DevOps rounds with real-time follow-up questions instead of a static bank, and the free plan includes 15 credits a month that reset monthly rather than stockpiling. Starter is $19\/mo if fifteen sessions a month isn&#8217;t enough.<\/p>\n<p>If the slower part of the job hunt is actually getting in front of enough cloud and DevOps roles rather than passing the interview once you land one, <a href=\"\/products\/auto-apply\">Auto-Apply<\/a> queues tailored applications for your review, 10 a month on the free plan, up to 400 a month on the Ultimate plan, and every application sits in a review queue until you approve it. Nothing goes out on your behalf without you looking at it first.<\/p>\n<p>Questions about either product go to contact@lastroundai.com, that&#8217;s the only inbox we check.<\/p>\n<div class=\"iq-sources not-prose\"><div class=\"iq-sources__title\">Sources &amp; further reading<\/div><ul class=\"iq-sources__list\"><li><a href=\"https:\/\/learn.microsoft.com\/en-us\/azure\/azure-resource-manager\/management\/overview\" target=\"_blank\" rel=\"nofollow noopener\">Microsoft Learn: Azure Resource Manager Overview<\/a><\/li><li><a href=\"https:\/\/learn.microsoft.com\/en-us\/azure\/azure-resource-manager\/bicep\/overview\" target=\"_blank\" rel=\"nofollow noopener\">Microsoft Learn: Bicep Overview<\/a><\/li><li><a href=\"https:\/\/www.flexera.com\/blog\/finops\/flexera-2026-state-of-the-cloud-report-the-convergence-of-cloud-and-value\/\" target=\"_blank\" rel=\"nofollow noopener\">Flexera 2026 State of the Cloud Report<\/a><\/li><\/ul><\/div>\n","protected":false},"excerpt":{"rendered":"<p>A cloud engineer candidate at a 200-person fintech in Austin lost a final-round Azure loop in March 2026 over one follow-up: what actually happens to every VM, NSG, and storage account inside a resource group if someone runs az group delete &#8211;yes without a lock in place. She&#8217;d nailed every ARM template question up to&#8230;<\/p>\n","protected":false},"author":3,"featured_media":1695,"comment_status":"open","ping_status":"closed","template":"","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","footnotes":""},"tags":[],"class_list":["post-1150","iq","type-iq","status-publish","has-post-thumbnail","hentry"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.8 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Azure Interview Questions (2026): 30 Q&amp;A | LastRoundAI<\/title>\n<meta name=\"description\" content=\"Real Azure interview questions for 2026: ARM, VMs, storage, Entra ID, networking, Functions, AKS, and Bicep. Practice live before your next interview.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/lastroundai.com\/interview-questions\/azure\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Azure Interview Questions (2026): 30 Q&amp;A | LastRoundAI\" \/>\n<meta property=\"og:description\" content=\"Real Azure interview questions for 2026: ARM, VMs, storage, Entra ID, networking, Functions, AKS, and Bicep. Practice live before your next interview.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/lastroundai.com\/interview-questions\/azure\" \/>\n<meta property=\"og:site_name\" content=\"LastRound AI\" \/>\n<meta property=\"article:modified_time\" content=\"2026-07-19T03:53:29+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/07\/iq-azure-og.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1200\" \/>\n\t<meta property=\"og:image:height\" content=\"630\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/azure\",\"url\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/azure\",\"name\":\"Azure Interview Questions (2026): 30 Q&A | LastRoundAI\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/azure#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/azure#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/iq-azure-og.png\",\"datePublished\":\"2026-07-16T16:50:03+00:00\",\"dateModified\":\"2026-07-19T03:53:29+00:00\",\"description\":\"Real Azure interview questions for 2026: ARM, VMs, storage, Entra ID, networking, Functions, AKS, and Bicep. Practice live before your next interview.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/azure#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/azure\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/azure#primaryimage\",\"url\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/iq-azure-og.png\",\"contentUrl\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/07\\\/iq-azure-og.png\",\"width\":1200,\"height\":630,\"caption\":\"Azure interview questions \u2014 LastRoundAI\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\\\/azure#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/lastroundai.com\\\/blog\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Interview Questions\",\"item\":\"https:\\\/\\\/lastroundai.com\\\/interview-questions\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Azure Interview Questions (2026): 30 Most Asked, With Answers\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/\",\"name\":\"LastRound AI\",\"description\":\"Interview Assistant prep, tech careers and AI tools\",\"publisher\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#organization\",\"name\":\"LastRound AI\",\"url\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/lastroundai-transprant-logo-optimized-BxEo2Wtq.png\",\"contentUrl\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/06\\\/lastroundai-transprant-logo-optimized-BxEo2Wtq.png\",\"width\":400,\"height\":400,\"caption\":\"LastRound AI\"},\"image\":{\"@id\":\"https:\\\/\\\/lastroundai.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Azure Interview Questions (2026): 30 Q&A | LastRoundAI","description":"Real Azure interview questions for 2026: ARM, VMs, storage, Entra ID, networking, Functions, AKS, and Bicep. Practice live before your next interview.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/lastroundai.com\/interview-questions\/azure","og_locale":"en_US","og_type":"article","og_title":"Azure Interview Questions (2026): 30 Q&A | LastRoundAI","og_description":"Real Azure interview questions for 2026: ARM, VMs, storage, Entra ID, networking, Functions, AKS, and Bicep. Practice live before your next interview.","og_url":"https:\/\/lastroundai.com\/interview-questions\/azure","og_site_name":"LastRound AI","article_modified_time":"2026-07-19T03:53:29+00:00","og_image":[{"width":1200,"height":630,"url":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/07\/iq-azure-og.png","type":"image\/png"}],"twitter_card":"summary_large_image","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/lastroundai.com\/interview-questions\/azure","url":"https:\/\/lastroundai.com\/interview-questions\/azure","name":"Azure Interview Questions (2026): 30 Q&A | LastRoundAI","isPartOf":{"@id":"https:\/\/lastroundai.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/lastroundai.com\/interview-questions\/azure#primaryimage"},"image":{"@id":"https:\/\/lastroundai.com\/interview-questions\/azure#primaryimage"},"thumbnailUrl":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/07\/iq-azure-og.png","datePublished":"2026-07-16T16:50:03+00:00","dateModified":"2026-07-19T03:53:29+00:00","description":"Real Azure interview questions for 2026: ARM, VMs, storage, Entra ID, networking, Functions, AKS, and Bicep. Practice live before your next interview.","breadcrumb":{"@id":"https:\/\/lastroundai.com\/interview-questions\/azure#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/lastroundai.com\/interview-questions\/azure"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/lastroundai.com\/interview-questions\/azure#primaryimage","url":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/07\/iq-azure-og.png","contentUrl":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/07\/iq-azure-og.png","width":1200,"height":630,"caption":"Azure interview questions \u2014 LastRoundAI"},{"@type":"BreadcrumbList","@id":"https:\/\/lastroundai.com\/interview-questions\/azure#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/lastroundai.com\/blog"},{"@type":"ListItem","position":2,"name":"Interview Questions","item":"https:\/\/lastroundai.com\/interview-questions"},{"@type":"ListItem","position":3,"name":"Azure Interview Questions (2026): 30 Most Asked, With Answers"}]},{"@type":"WebSite","@id":"https:\/\/lastroundai.com\/blog\/#website","url":"https:\/\/lastroundai.com\/blog\/","name":"LastRound AI","description":"Interview Assistant prep, tech careers and AI tools","publisher":{"@id":"https:\/\/lastroundai.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/lastroundai.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/lastroundai.com\/blog\/#organization","name":"LastRound AI","url":"https:\/\/lastroundai.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/lastroundai.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/06\/lastroundai-transprant-logo-optimized-BxEo2Wtq.png","contentUrl":"https:\/\/lastroundai.com\/blog\/wp-content\/uploads\/2026\/06\/lastroundai-transprant-logo-optimized-BxEo2Wtq.png","width":400,"height":400,"caption":"LastRound AI"},"image":{"@id":"https:\/\/lastroundai.com\/blog\/#\/schema\/logo\/image\/"}}]}},"_links":{"self":[{"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/iq\/1150","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/iq"}],"about":[{"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/types\/iq"}],"author":[{"embeddable":true,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/comments?post=1150"}],"version-history":[{"count":3,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/iq\/1150\/revisions"}],"predecessor-version":[{"id":1485,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/iq\/1150\/revisions\/1485"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/media\/1695"}],"wp:attachment":[{"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/media?parent=1150"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lastroundai.com\/blog\/wp-json\/wp\/v2\/tags?post=1150"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}