Azure cloud engineer interview questions: what interviewers actually probe

Question lists for this role are everywhere, and almost all of them make the same mistake: they give you a script for the first answer and nothing for the follow-up, which is where the interview is actually decided. Here are around twenty real questions, grouped by what each one tests, with the signal a strong answer sends.

New to cloud? CAMPUX is a free, build-first course. Start here →

Azure cloud engineer interviews at the role level test six things: identity (Entra ID, RBAC, managed identities), networking (VNets, NSGs, private endpoints), compute choices and scaling, storage, infrastructure as code, and how you troubleshoot under pressure. Interviewers listen for reasoning and trade-offs, not recited definitions — and honestly, a memorized answer usually collapses on the second follow-up.

First, make sure you are reading the right guide. This one is for the mid-level engineer role — you have some hands-on time, maybe an AZ-104, and you are interviewing for a job where you will own real infrastructure. If you are breaking in with no experience, start with the entry-level Azure interview questions instead; the bar and the question style are different. If you are aiming at the security specialization, the cloud security engineer interview set covers that ground. And if you want to drill the troubleshooting format specifically, the scenario-based questions walk through that drill in depth.

One framing note before the questions. I have sat on both sides of this table, and the pattern is consistent: the first question in each area is a door, not a test. Answer with a definition and stop, and the interviewer learns nothing except that you can read. Answer with the definition plus the decision it drives — "which is why I would reach for X here, unless Y" — and the conversation becomes two engineers talking, which is the whole game.

Identity and access: the questions that open most interviews

Identity comes first in most loops because it is where new engineers do the most damage. Every one of these questions is really asking: will you hand out broad access because it is easier?

1. What is the difference between a service principal and a managed identity, and when would you use each?

A strong answer contains the credential story, not just the definitions. A service principal has a secret or certificate you must store, rotate, and inevitably worry about; a managed identity is a service principal Azure owns for you — no credential to leak, nothing to expire in a pipeline variable at 2am. The signal the interviewer wants: "inside Azure I default to managed identities; service principals are for things outside Azure, and even then I prefer federated credentials over long-lived secrets." We build exactly this in the service principals and managed identity class, because it comes up in nearly every loop.

2. How would you let an app read secrets from Key Vault without storing any credentials?

This is question 1 wearing work clothes. Strong answers walk the chain: assign a managed identity to the app, grant it a Key Vault role scoped to that vault only, and have the app request tokens through the identity endpoint. The listened-for signal is scoping — the narrowest role on the narrowest scope, and you can say why.

3. Explain Azure RBAC. How does a role assignment at a subscription differ from one at a resource group?

Definitions are the easy half. The strong answer covers inheritance — assignments flow down from management group to subscription to resource group to resource — then makes a judgement: assign as low as the job allows, prefer built-in roles, and treat Owner at subscription scope as a smell. Bonus signal: knowing Entra ID directory roles and Azure RBAC are separate systems that beginners constantly conflate.

4. A user says they cannot see a resource group they should have access to. What do you check?

The first troubleshooting probe, and it is testing order. Strong answers go: confirm what "cannot see" means, check role assignments at that scope and above, check group membership, remember assignments can take minutes to propagate, and only then consider the wrong directory or conditional access. The weak answer jumps straight to "give them Contributor" — the exact instinct the question exists to catch.

Networking: where layered thinking shows or doesn't

Networking questions are the sharpest differentiator at this level, because you cannot bluff a diagnosis path. If VNets are still fuzzy for you, the virtual networks and subnets class is the free grounding for everything below.

5. Walk me through what happens when a VM cannot reach a storage account.

My favourite question to ask, because it tests layered troubleshooting order, not trivia. A strong answer moves through the stack out loud: is it DNS (does the storage hostname resolve to a public IP or a private endpoint?), is it the network path (NSG rules on subnet and NIC, effective security rules, a route table or firewall in the middle?), is it the storage account itself (network rules, public access disabled?), and is it authorization — a 403 is a permissions problem wearing a network costume. The signal: you name a first check with a reason, and you distinguish "cannot connect" from "connects and gets denied."

6. NSG or Azure Firewall — when do you use which?

Strong answers frame them as layers: NSGs are free, stateful, per-subnet or per-NIC allow/deny on IPs and ports; Azure Firewall is a managed, centralized appliance with FQDN filtering and a real monthly cost. The trade-off sentence matters — "NSGs everywhere as a baseline, a firewall in the hub when I need egress control or FQDN rules, and I would not pay for one on a small flat network."

7. What does a private endpoint actually change? Why do people break DNS with it?

Anyone can say "private connectivity to a PaaS service." A strong answer says what changes concretely: the service gets a private IP in your VNet, and — the part interviewers listen for — its public hostname must now resolve to that private IP, which is why the private DNS zone and its VNet links matter. Most private endpoint outages are DNS misconfigurations; saying so out loud tells the interviewer you have actually deployed one.

8. Two VNets need to talk to each other. Options, and how do you scale that to twenty VNets?

Peering for two. For twenty, the strong answer reaches for hub-and-spoke (or names Virtual WAN as the managed version): shared services and the firewall in the hub, spokes peered to it, and an honest note that peering is non-transitive, so spoke-to-spoke traffic routes through the hub. You are being tested on whether you have thought past two boxes and an arrow.

Compute: choosing, scaling, and paying for it

9. We have a containerized web API. App Service, Container Apps, AKS, or Functions — how do you choose?

The catalogue recital fails here. Strong answers pick decision criteria instead: how much orchestration control the team needs, its operational skill, traffic shape, and cost. Something like: "Functions if it is event-driven and short-lived; App Service or Container Apps for a straightforward API; AKS only when we genuinely need Kubernetes-level control, because we then own upgrades, node pools, and a much bigger operational surface." Saying what you would not pick, and why, is the strongest signal in this whole group.

10. How does autoscaling actually work for your chosen service? Scale up or scale out?

Strong answers separate the two axes — bigger instances versus more instances — and default to scaling out for stateless web workloads, with specific triggers: CPU is the lazy default, queue depth or requests-per-instance often track real load better. The follow-up is usually "what breaks when you scale out?" and the strong answer already knows: local state, sticky sessions, or a database connection pool sized for three instances that now has thirty.

11. What is the difference between availability sets and availability zones, and when does it matter?

Sets protect you within a datacenter (separate fault and update domains); zones protect you across physically separate datacenters in a region. A strong answer attaches a decision — zones for anything that matters, where the region supports them — plus the honest caveat that zone-redundancy has cost and latency implications you should check per service rather than assume.

Storage: small questions, expensive wrong answers

12. LRS, ZRS, GRS — how do you actually choose a redundancy level?

Acronym expansion is the floor. The strong answer converts each option into a failure it survives — LRS survives a drive, ZRS a datacenter, GRS a region — then ties the choice to money and blast radius: "rebuildable data on LRS; anything the business cannot recreate gets zone or geo redundancy, and I would ask about recovery expectations before paying for GRS." Cost-aware reasoning is the differentiator, not memory.

13. When would you move blobs to cool or archive tiers, and what is the catch?

Strong answers know tiers are a trade between storage cost and access cost: cool is cheaper to hold and pricier to read, archive is very cheap to hold but takes hours to rehydrate and charges you for early deletion. The signal sentence: "I would set lifecycle management rules to demote data automatically, and I would never archive anything someone might need within the hour."

14. How do you lock down access to a storage account?

This one quietly spans identity, networking, and storage at once, which is why it gets asked. A strong answer layers it: prefer Entra ID auth with RBAC over account keys, rotate or disable the keys, use short-lived SAS tokens only when identity-based auth genuinely cannot work, restrict the network with firewall rules or private endpoints, and turn off public blob access unless there is a stated reason. Noting that account keys grant everything and sit in far too many app configs marks someone who has cleaned up after them.

Infrastructure as code and automation

15. Why infrastructure as code at all? What actually goes wrong with portal-built environments?

Everyone says "repeatability." Strong answers describe the failure mode from the inside: the portal-built environment nobody can reproduce, the staging that differs from prod in ways nobody can list, the change with no review and no history. IaC makes infrastructure reviewable, diffable, and rebuildable — and the honest hedge lands well: "the portal is fine for exploring; production should never be hand-built."

16. What is Terraform state, and what happens when it drifts from reality?

The single most reliable filter for "has actually used Terraform." A strong answer explains that state is Terraform's record of what it believes exists, mapped to real resource IDs; that it lives remotely with locking; and that drift — someone changing a resource outside Terraform — shows up as an unexpected diff at the next plan. The signal is what you do about it: read the plan, decide whether reality or code is right, and reconcile deliberately rather than blind-applying. If you have never felt the small horror of an unexpected destroy in a plan, this question will find you out.

17. How do you structure a pipeline that deploys infrastructure safely?

Strong answers have stages and gates: validate and lint, plan on the pull request so a human reviews the diff, apply only after approval and only from the main branch, authenticate with OIDC federated credentials rather than stored secrets, and separate environments so a bad dev apply cannot touch prod. Nobody expects one canonical design — what is scored is treating infrastructure changes with the same review discipline as code.

Incident thinking: the group that decides borderline candidates

These have no correct final answer, which is precisely the point. The interviewer is watching your order of operations and whether you stay calm and specific.

18. Production is slow. Users are complaining. Where do you start?

Strong answers resist the guess. First establish what "slow" means and since when — a metric, not a vibe. Then check what changed: deployments, config, traffic. Then walk the request path with data — Application Insights or equivalent — to find where the time goes before touching anything. The weak answer restarts something on instinct; the strong one says "I want to know which layer is slow before I change any of them."

19. You get paged at 2am — a service is down. Talk me through your first fifteen minutes.

The signal here is separating restoration from investigation. Strong answers go: confirm the alert is real and scope the impact, check health and recent changes, and bias toward the fastest safe path back to service — often rolling back the last deployment — while preserving logs. Saying "root cause comes after service is restored, in the post-incident review" tells the interviewer you have either lived this or trained for it properly.

20. A deployment you approved took production down. What do you do — and what do you change afterwards?

Partly technical, mostly character. Strong answers roll back first and say so plainly, communicate status without spin, then talk about the system rather than the guilty party: what check was missing from the pipeline, whether a canary rollout would have caught it, what the blameless review should produce. Interviewers ask this to find out whether you hide failures. The only failing answer is the one where nothing was your fault.

The first answer proves you read a list. The second follow-up proves you have done the work. Interviews at this level are won on the follow-up.

The honest gap: why the second follow-up beats every question list

Here is the part most question-and-answer posts will not tell you, because it undermines the post. Any interviewer worth their calendar invite probes past the first answer. You say managed identities avoid stored credentials — good. "So how does the app actually get a token at runtime?" You say private endpoints give a service a private IP — fine. "Your app resolves the public IP anyway. Why?" A memorized answer survives the first question and collapses on the second, and the collapse costs more than an honest "I have not hit that," because the interviewer now re-reads everything you said earlier with suspicion.

The uncomfortable conclusion is that the only durable prep is having done the things. Not watched them — done them. Deploy something behind a private endpoint and break its DNS on purpose. Give a web app a managed identity and pull a secret from Key Vault with it. Drift a Terraform state and reconcile it. Each takes an evening, costs nearly nothing on a free-tier subscription, and converts three or four of the questions above from recall into memory of your own hands. That is the version of you the follow-ups cannot collapse.

Question lists still have a use — mapping the territory and drilling your delivery out loud. Our free interview questions page is built for exactly that rehearsal, and exam practice keeps the underlying Azure knowledge sharp, since AZ-104-level fundamentals are the floor these interviews stand on. And when you get to the offer stage, the landing-the-job class covers the search mechanics around the interview itself. If what you actually need is the building part with someone to unblock you — structure, real labs, an instructor when it breaks — that is what the live cohort exists for. But the free path above is real prep on its own, and you should use it first.

Questions people also ask

What questions are asked in an Azure cloud engineer interview?

Expect questions across six areas: identity (Entra ID, RBAC, service principals versus managed identities), networking (VNets, NSGs, private endpoints and their DNS behaviour), compute (choosing between App Service, containers, AKS and Functions, plus scaling), storage (redundancy tiers, access control), infrastructure as code (why IaC, Terraform state, safe pipelines), and troubleshooting scenarios like a VM that cannot reach a storage account. Definitions get you through the first sentence; the interview is really about the follow-ups, where you explain trade-offs and walk through how you would diagnose a problem in order.

How do I prepare for an Azure cloud engineer interview?

Build things, then practise explaining them out loud. Deploy a small app behind a private endpoint, break the DNS on purpose, and fix it. Assign a managed identity to something and watch a role assignment propagate. Write a Terraform config, drift it, and reconcile the state. Every one of those exercises turns a question you would have answered from memory into one you answer from experience, and interviewers can hear the difference within a sentence or two. Reading question lists is fine for mapping the territory, but it is the weakest form of prep on its own.

Are Azure certifications enough to pass a cloud engineer interview?

Usually not on their own. Certifications like AZ-104 get your résumé past screening and prove you know the vocabulary, but role-level interviews probe past the first answer with follow-ups that exam prep does not cover — why you would choose one service over another, what you would check first when something breaks, what went wrong the last time you deployed something. A certification plus one or two things you genuinely built and can explain beats a wall of badges with nothing behind them. That is a consistent pattern hiring managers describe, even if individual interviews vary.

How do I answer scenario-based Azure interview questions?

Answer in a visible order, out loud. Start by saying what you would check first and why — usually the layer most likely to fail or cheapest to verify — then move through the stack: identity and permissions, network path and DNS, service configuration, then the service itself. Name the actual tools you would use, like effective security rules, nslookup against the private endpoint, or activity logs. Interviewers score the shape of your reasoning more than the specific fix, because the scenario in the job will never match the one in the interview.

What is the difference between a service principal and a managed identity in an interview answer?

A service principal is an identity you create and manage yourself, including its credential — a secret or certificate that can expire, leak, or end up in a pipeline variable. A managed identity is a service principal that Azure creates and rotates for you, attached to a resource, so there is no credential for you to store at all. The strong interview answer states the rule that follows: inside Azure, prefer managed identities so there is nothing to leak; use a service principal when something outside Azure needs to authenticate, and prefer federated credentials over long-lived secrets when you can.