I once sat across from a candidate who'd listed "Azure" four separate times on his resume — AZ-104, three years of "cloud infrastructure," the works. I asked him to walk me through what happens when you assign a Contributor role at the subscription level versus the resource group level, and he went quiet for a solid ten seconds before guessing "they're basically the same thing." They are not the same thing, and that gap between "I've used Azure" and "I understand how Azure's control plane is actually structured" is exactly what these questions are built to expose. Here are the eight that come up most, and what interviewers are really listening for when they ask them.
1. Walk me through the management group → subscription → resource group → resource hierarchy. Where does access actually get inherited from?
Management groups sit above subscriptions and let you apply RBAC and policy across multiple subscriptions at once — useful once an org has more than a handful of subscriptions and doesn't want to configure the same policy nine times. Access assigned at any level flows down: a Contributor role granted at the management group level applies to every subscription, resource group, and resource beneath it, with no way to "block" inheritance from above (you can only add more restrictive policy, not remove an inherited role assignment). The wrong answer treats resource groups as the top of the hierarchy, which is fine until an org actually needs cross-subscription governance and nobody on the team understands why a policy applied "everywhere" broke a dev subscription nobody meant to touch.
2. RBAC scope — when do you assign a role at the subscription level versus the resource group level, and why does it matter?
The technically correct answer is "wherever the access needs to apply," but the real signal is whether someone defaults to the narrowest scope that works. Assigning Contributor at the subscription level because it's "easier" than scoping to individual resource groups is the single most common over-permissioning mistake I see in Azure environments — it means every team, every environment, every resource group under that subscription inherits access nobody asked for. I ask this because I've had to clean up exactly this: a contractor granted Contributor at the subscription level for one project who could, technically, delete production storage accounts belonging to a completely unrelated team.
3. NSG vs Azure Firewall — what's the actual difference, and when do you need both?
Network Security Groups are stateful, layer-3/4 packet filters that live on a subnet or NIC and evaluate rules by priority — cheap, fast, and the right tool for basic allow/deny between subnets. Azure Firewall is a managed, stateful firewall-as-a-service that operates at the VNet level, supports FQDN-based filtering, threat intelligence feeds, and centralized logging across a hub-and-spoke topology. The wrong answer treats them as redundant. The real pattern in most enterprise Azure environments is NSGs for cheap subnet-level segmentation plus a centralized Azure Firewall in the hub VNet for egress control and FQDN filtering that NSGs simply can't do — NSGs don't understand DNS names, only IP ranges and ports.
4. Storage account redundancy — LRS, ZRS, GRS, RA-GRS. What is each one actually protecting against, and what's the tradeoff no one mentions?
LRS replicates three copies within a single datacenter — protects against disk/rack failure, not datacenter failure. ZRS spreads those three copies across availability zones in the same region — survives a datacenter outage, not a regional one. GRS adds asynchronous replication to a paired region hundreds of miles away — survives a full regional outage, but the replication lag means a failover can lose the last few minutes of writes. RA-GRS is GRS plus a read-only endpoint in the secondary region you can query directly. The tradeoff nobody mentions in the marketing material: geo-redundancy costs roughly double LRS, and a lot of teams pay for GRS on data that would be perfectly fine on ZRS because "geo-redundant" sounds safer without anyone checking what their actual RTO/RPO requirement is.
5. Managed Identity vs Service Principal — aren't they the same thing?
They solve the same underlying problem — letting an Azure resource authenticate to other Azure services without hardcoded credentials — but a Service Principal is a standalone identity you create and manage yourself, including rotating its secret or certificate, while a Managed Identity is tied directly to a resource's lifecycle and Azure rotates the credential for you automatically, with no secret ever exposed to your code. The follow-up I actually care about: system-assigned versus user-assigned managed identity. System-assigned dies with the resource it's attached to; user-assigned is a standalone Azure object you can attach to multiple resources and reuse. If someone's answer is "just use a service principal for everything," that's the answer of someone who hasn't had to explain a credential rotation incident to a security team.
6. App Service, Azure Functions, or AKS — how do you actually decide?
App Service is the default for a standard web app or API you don't want to think about — managed scaling, deployment slots, built-in SSL. Azure Functions is for event-driven, short-lived workloads where you're billed per execution rather than per hour of uptime — a queue trigger processing messages, a timer job, a webhook handler. AKS is for when you actually need container orchestration complexity: multiple services, custom networking, sidecar patterns, or you're already running Kubernetes elsewhere and want consistency. The mistake I see constantly is teams reaching for AKS by default because it's the "serious" option, then spending months on cluster operations for a workload that was three App Service instances and a Function the whole time.
7. Availability Set vs Availability Zone — what failure domain does each actually protect against?
An Availability Set spreads VMs across multiple fault domains (separate power/network) and update domains (separate maintenance windows) within a single datacenter — protects against a rack failure or planned maintenance taking down every instance at once. An Availability Zone is a physically separate datacenter within the same region, with independent power, cooling, and networking — protects against an entire datacenter going down. They are not interchangeable, and you can't mix VMs from an Availability Set across zones. The real-world implication: if your region only has one datacenter (not all Azure regions support zones), Availability Sets are your only option, and "just use zones" isn't universally available advice.
8. Azure Policy vs RBAC — people mix these up constantly. What's the actual difference in what each one controls?
RBAC controls who can do what — whether a user or identity has permission to create, read, update, or delete a resource. Azure Policy controls what gets created and how, regardless of who's doing it — enforcing that storage accounts must use HTTPS-only, that VMs must come from an approved image, or that resources must carry a cost-center tag, even for someone who has full Owner-level RBAC access. A candidate who says "Policy is basically RBAC for resources" hasn't actually used Policy for compliance enforcement — the whole point is that Policy applies even when RBAC would otherwise allow the action, which is exactly the governance gap RBAC alone can't close.
None of these are hard to explain once you've actually broken a subscription's access model or watched a GRS failover eat five minutes of writes. They're hard live, under a bit of pressure, with someone waiting for you to think out loud. I've started running through scenario questions like these with LastRound AI's AI Mock Interview before Azure-heavy interviews — not to memorize scripted answers, but because saying "the NSG handles subnet-level filtering, but egress FQDN filtering needs Azure Firewall in the hub" out loud, on the spot, is a different skill than recognizing it on a slide.
Top comments (1)
I really like how the article highlights the difference between having experience with Azure and truly understanding its control plane structure. I've seen this gap firsthand when working with teams that have implemented Azure solutions without fully considering the implications of their design choices. The section on RBAC scope really resonated with me, as I've encountered similar issues with over-permissioning in my own work. One thing I'd like to add is that it's not just about assigning roles at the correct scope, but also about regularly reviewing and auditing those assignments to ensure they remain appropriate over time. Do you have any strategies for keeping RBAC assignments up to date and aligned with changing business needs?