Drawn from real Azure cloud-engineer job postings and the questions hiring panels reach for, categorised by topic — and every one mapped to the class that answers it, so a weak answer is one click from becoming a strong one.
This is not a memorisation list. Interviewers can tell a recited answer from an understood one in a sentence. Use each card two ways: cover the "what they're really testing" line and answer the question aloud, then read the line and the class it points to. The point is not to have the answer — it is to have built the thing the answer describes.
The room Two chairs, a desk, and half an hour. The cards below are the questions asked from the left of it; the last section is what you ask back from the right.
Cloud Fundamentals
Classes 1–6 · AZ-900
The warm-up round. Panels use it to sort people who memorised definitions from people who can reason about trade-offs — so answer with a decision, not a dictionary entry.
What's the difference between IaaS, PaaS, and SaaS — and how do you choose?
Testing: whether you pick per workload by chores-vs-control, not per company by fashion. Strong answers name a real example of each.
Where mid-level interviews get real. Identity is the security boundary of the cloud, and panels probe whether you grant the narrowest access at the lowest scope by instinct.
Service principal vs managed identity — what's the difference, and when do you use each?
Testing: the credential-hygiene ladder. The strong answer prefers managed identity inside Azure and federation outside — no stored secrets.
Service endpoint versus private endpoint — what's the real difference?
Testing: that a service endpoint firewalls a public endpoint while a private endpoint gives the service a private IP and can remove the public door entirely.
A private endpoint is configured but the app still can't reach the service. Where do you look first?
Testing: the DNS trap — a missing or unlinked private DNS zone resolves the name back to the public IP. Always check resolution from inside the network.
Testing: that Archive is offline — you must rehydrate before reading, which can take hours. Never the home for a backup you might restore under pressure.
The two-salary-band divide. Panels want to hear that your infrastructure is text, reviewed and reproducible — and that you can defend a tool choice with a rule, not a preference.
Bicep or Terraform — which do you choose, and why?
Testing: the decision rule, not a loyalty. It comes down to who keeps the books — Azure for Bicep, its own state for Terraform — and whether you need multi-cloud reach.
The questions with the sharpest right answers. One in particular — how the pipeline authenticates — separates candidates who store a secret from those who don't.
How does your pipeline authenticate to Azure?
Testing: OIDC federation — GitHub signs a token, Entra trades it for minutes of access, nothing stored. The answer most candidates cannot give.
GitFlow or trunk-based development — which, and when?
Testing: that the answer is a consequence of deployment frequency, not fashion. Ship often, trunk-based; ship on a slow cadence, GitFlow earns its overhead.
Why is a workflow file a security-sensitive artifact?
Testing: that it can read secrets and deploy to production, so it must be reviewed with the same care as production code — trigger, permissions, steps, gates.
The bill tripled. Walk me through finding out why.
Testing: cost analysis as a query — group then filter to the culprit — and the four usual suspects: orphans, oversized compute, non-prod running 24/7, and data movement.
What's your defence-in-depth story for a public web app?
Testing: layers that fail independently — WAF at the edge, private endpoints beneath, a keyless identity, a vault for secrets, the data tier off the internet.
A live key just got committed to a public repo. What do you do, in order?
Testing: rotate first — the secret is burned the instant it's pushed. Assess the blast radius, remove it from history, then move the workload off stored secrets.
What could an attacker do with your CI pipeline, and how do you bound it?
Testing: the least-privilege audit — what each service principal reaches, which runs can become it, the GITHUB_TOKEN's scope, and who reviews the file.
The market's vaguest requirement — "AI a plus" — and your chance to answer it with infrastructure instead of a chat window.
How would you run an internal AI assistant on Azure OpenAI, privately?
Testing: a private endpoint, public access disabled, key auth off, the app authenticating by managed identity — the Class 14 pattern applied to the model.
Several teams share one model. How do you know who is spending what?
Testing: an API Management gateway metering tokens per key, with per-caller limits and the counts charted — the sentence that gets an AI-infra candidate hired.
What is the context window, and why does it explain most "AI is acting weird" bugs?
Testing: that the model knows only its weights plus what's in the window — not in the weights, not in the window, not known. Every AI bug is a question about the window.
The round candidates underprepare and panels weight heavily. Answer in the shape of a real story — situation, action, result — and let your capstones supply the specifics.
Tell me about a time you troubleshot an issue that spanned several services.
Testing: a method under pressure — detect, triage, mitigate, learn — and a rollback before a root-cause hunt. Use a real incident, not a hypothetical.
The open-ended rounds for senior roles — no single right answer, just whether you reason like someone who has run this before. Each opens to a strong sample answer and the points a panel listens for. Read them, then say them your own way.
Walk me through how you would design a landing zone for a company migrating 200 workloads to Azure.
Technical · Architecture · Senior
Show a strong answer
Start with governance first, not infrastructure. I'd establish management groups aligned to the org chart — typically Corp → Platform → Workloads — with Azure Policy at each level enforcing mandatory tags, allowed regions, and required diagnostics.
For the platform layer: hub-and-spoke network topology with a hub VNet hosting the firewall (Azure Firewall or NVA), DNS, and VPN/ExpressRoute gateway. Each spoke is a workload VNet peered to the hub.
Identity: Extend on-prem AD via Azure AD Connect or go cloud-native with Azure AD. Implement PIM for privileged roles — no standing access.
Then I'd categorize the 200 workloads by risk and complexity: lift-and-shift candidates, refactor candidates, retire candidates. Start with low-risk lift-and-shift to build process confidence, then tackle the complex ones.
Finally, FinOps from day one: budgets and alerts per subscription, tags for cost allocation, Azure Cost Management dashboards.
Hit these points
Management groups + Policy
Hub-and-spoke networking
PIM for privileged access
Workload categorization
FinOps from day one
How would you implement zero-trust for a Kubernetes workload that needs to talk to Azure SQL and Key Vault?
Technical · Security · Senior
Show a strong answer
Eliminate static credentials entirely using Azure Workload Identity. Here's the flow:
Enable the OIDC issuer on AKS and Workload Identity webhook. Create an Azure Managed Identity, and federate it with a Kubernetes ServiceAccount via OIDC federation — now the pod's identity is the Managed Identity.
For Key Vault: grant the Managed Identity "Key Vault Secrets User" role. The pod uses the Azure SDK, which automatically gets a token via IMDS — no credentials in environment variables, no secrets in the cluster.
For Azure SQL: use the Managed Identity as an AAD login on the database. The connection string uses Active Directory Default auth — again, no password.
On the network side: network policies in Kubernetes default-deny everything, then explicitly allow the app pod to egress to Key Vault and SQL endpoints on specific ports. No lateral movement possible.
This is zero-trust in practice: identity is workload identity, credentials don't exist, network access is explicit and minimal.
Hit these points
AKS OIDC + Workload Identity
Federated credential binding
Managed Identity for Key Vault and SQL
Network policies default-deny
No static credentials anywhere
A production AKS workload is experiencing intermittent pod crashes. How do you diagnose it?
Technical · Reliability · Mid
Show a strong answer
Start with signals, not guesses. First: kubectl describe pod <pod-name> — look at the Events section for OOMKilled, image pull failures, or failed probes.
If it's OOMKilled: the container is exceeding its memory limit. Check actual usage with kubectl top pods, compare to the limit in the deployment spec, and either increase the limit or fix the memory leak.
If liveness probe is failing: kubectl logs <pod> --previous to see what happened before the crash. Check if the /health endpoint has a regression or if the app is slow to start and probe timing is too aggressive.
If it's intermittent with no clear OOM: look at node pressure. kubectl describe nodes — check for memory pressure, disk pressure, or PID pressure. A node under pressure evicts pods.
Then check the observability stack: Prometheus → kube_pod_container_status_restarts_total with a 5-minute rate. If it's spiking, Grafana can show when it started and correlate with deployments.
I'd also check Azure Monitor for node-level metrics — sometimes it's the underlying VM having issues.
Hit these points
kubectl describe for events
OOMKilled → check limits vs usage
kubectl logs --previous
Node pressure (describe nodes)
Prometheus metric correlation
You've been asked to reduce Azure spend by 30% without impacting production. What's your approach?
Technical · FinOps · Senior
Show a strong answer
I approach this as three buckets: eliminate waste, right-size, and optimize commitment.
Eliminate waste first — this is free money. Use Azure Advisor and run a query for unattached managed disks, stopped (not deallocated) VMs, empty resource groups, and unassociated public IPs. In most orgs this alone saves 5-10%.
Right-size: pull 30 days of CPU and memory metrics from Azure Monitor for all VMs. Any VM consistently below 20% CPU is a right-size candidate. Use the Azure Advisor recommendations as a starting point but validate with actual workload owners before resizing prod.
Optimize commitment: Reserved Instances for any workload that runs 24/7 — 1-year RI gives ~40% savings over pay-as-you-go. Savings Plans for compute-heavy workloads where RI flexibility matters. Azure Hybrid Benefit if they have Windows Server licenses through EA.
Dev/Test environments: implement auto-shutdown schedules if they don't exist. Dev workloads running nights and weekends is common waste.
Finally, tag everything with cost-center and team. Make teams accountable for their spend with monthly chargeback reports — behavior changes fast when people see their bill.
Hit these points
Waste first (disks, stopped VMs, public IPs)
Right-size from 30-day metrics
Reserved Instances for 24/7 workloads
Dev/Test auto-shutdown
Chargeback for accountability
Tell me about a time you had to push back on a technical decision made by leadership.
Behavioral · Leadership · Senior
Show a strong answer
Use STAR format: Situation, Task, Action, Result.
**Situation**: At [company], the VP of Engineering decided to move all production workloads to spot instances to cut costs 60%. I was the lead cloud engineer responsible for availability.
**Task**: I needed to communicate the risk clearly without being seen as resistant to cost reduction — which was a legitimate business priority.
**Action**: I built a cost-risk analysis. Spot instances for stateless, interruptible workloads (batch jobs, non-critical workers) — absolutely yes. But for our payment processing service, a spot eviction during peak hours would cause a production outage and violate our SLA. I scheduled a 30-minute meeting with the VP, brought the data, proposed a hybrid: spot for dev/staging and interruptible workloads (saving ~40%), on-demand reserved for production critical path (protecting the SLA).
**Result**: VP agreed. We hit 38% cost reduction without a production incident. More importantly, I built credibility by coming with a solution, not just a problem.
**What I learned**: Engineers who push back without an alternative are obstacles. Engineers who push back with a better solution are partners.
Hit these points
STAR structure
Came with data and an alternative
Acknowledged the business priority
Specific outcome
Self-aware reflection
Describe a production incident you were involved in. What happened and what did you change afterward?
Behavioral · Incident · Mid
Show a strong answer
Use STAR + what you changed structurally, not just what you fixed.
**Situation**: We had a database connection pool exhaustion incident that took down the API layer for 45 minutes on a Saturday afternoon.
**Task**: I was on call and responsible for diagnosis and remediation.
**Action**: First 5 minutes: triage. Checked dashboards — API 503s spiking, DB connections at max (150/150). Identified three services hammering the DB during a scheduled batch job that normally ran off-hours but had been rescheduled. Immediate mitigation: killed the batch job, connection pool recovered, services recovered within 2 minutes.
**Root cause**: No connection limits per service. The batch job could consume the entire pool, starving transactional services.
**Result**: Immediate fix was adding connection pool partitioning per service (max 30 per service). Longer term, we moved the batch job to a separate read replica and added an alert on connection pool utilization > 70%. We also did a blameless post-mortem and documented it in our runbooks.
The key insight: the incident itself was 45 minutes. The 2 hours after building the safeguards was the real value.
Hit these points
Clear STAR structure
Specific metrics and timeline
Root cause vs symptom
Structural fix, not just immediate patch
Blameless post-mortem culture
How do you prevent bad infrastructure code from reaching production in a Terraform-based pipeline?
Technical · CI/CD · Mid
Show a strong answer
Defense in depth — multiple gates, not one.
**Linting and formatting**: terraform fmt and tflint in the PR check. Fails fast on style issues before expensive plan runs.
**Security scanning**: tfsec or Checkov on every PR. These catch security misconfigurations — open security groups, storage accounts with public access, unencrypted disks — before they're ever planned.
**Terraform plan as PR artifact**: Run terraform plan in the PR pipeline and post the plan output as a PR comment. Engineers review what will actually change before approving. No surprises.
**Policy as code**: OPA (Open Policy Agent) or Sentinel to enforce organizational rules — for example, "no resource can be created without required tags" or "storage accounts must use private endpoints." These rules live in code, not in someone's head.
**Protected main branch**: Require at minimum one reviewer approval + passing CI before merge. For production, require a named approver.
**Blast radius limiting**: Use workspaces or separate pipelines per environment. Dev → Staging → Prod promotion. Never run terraform apply directly against prod from a feature branch.
Hit these points
tflint + tfsec/Checkov in PR
Plan as PR comment
OPA/Sentinel policy as code
Branch protection with approvals
Environment promotion pipeline
How do you work with developers who resist infrastructure changes you know are necessary?
Behavioral · Collaboration · Mid
Show a strong answer
I start by understanding why they're resisting. Usually it's one of three things: the change adds friction to their workflow, they don't trust it won't break something, or they weren't involved in the decision.
**If it's friction**: find out what specifically. Sometimes security controls or new deployment processes can be automated so developers barely notice them. If I can absorb the complexity in the platform layer, I do.
**If it's trust**: I pilot with one willing team first. Real results from a team they respect are more convincing than any presentation. I bring data: deploy frequency before and after, incident count, time-to-restore.
**If it's ownership**: I involve them earlier. The best infrastructure changes come from pairing with developers to understand their actual pain points. If they helped design it, they're invested in it working.
What I avoid: pushing changes top-down and calling it "platform governance." That breeds resentment and shadow IT. The goal is to make the right thing the easy thing.
Hit these points
Diagnose the resistance first
Absorb complexity at platform layer
Pilot + data before broad rollout
Involve early in design
Make the right thing the easy thing
The questions you ask them
Interviews go both ways
"Do you have any questions for us?" is not the end of the interview — it is part of it, and the strongest candidates treat it as their own diligence. Good questions signal seniority and, just as importantly, tell you whether to accept the offer. Ask a few of these; then listen to how they answer, not only what they say.
What does success look like for this role at 30, 60, and 90 days?
What a good answer reveals: whether the team has actually thought about onboarding. A crisp, staged answer means a plan exists; a vague one means you will write it yourself. Either way you now know.
How is the team structured, and who would I work most closely with day to day?
What a good answer reveals: team dynamics and where you'd sit in them — one team or shared across many, a clear lead or a flat scrum, and whether the people who'd review your work are named or hand-wavy.
Team shape decides your day
What's the culture around on-call, incidents, and postmortems?
What a good answer reveals: whether failure is treated as a systems problem or a personal one. "Blameless" said plainly is a green flag; a pause, or "we find who caused it," tells you what a bad night here feels like.
What a good answer reveals: the real engineering maturity behind the job post. Pull request, review, gated pipeline, no stored secrets — or a person clicking in the portal on a Friday. This one question separates the roles.
What a good answer reveals: whether you'll have a voice or inherit edicts — a design-review culture and written trade-offs, or "the lead decides." Neither is wrong; knowing which lets you choose with your eyes open.
Decision rules, from every class
How do you balance new feature work against reliability and tech debt?
What a good answer reveals: whether operations are valued or merely tolerated. A team that budgets time for toil relief and monitoring is a team you can grow in; one that only ships features will burn you on the pager.
The Phase Four question
How do you support learning and growth for engineers here?
What a good answer reveals: whether this job is a ladder or a treadmill — real answers name mentorship, conference budgets, time for certifications, or internal mobility. Silence here is its own answer.
Your growth is the point
What's the single biggest challenge the team is facing right now?
What a good answer reveals: candour, and what you'd actually walk into. A specific, honest challenge is a gift — it tells you the real work — while a polished non-answer tells you how much they'll level with you once you're inside.