What Azure Hiring Managers Test Instead of Certifications
I've sat on both sides of the interview table, and the same pattern keeps showing up. Someone walks in with a stack of Azure certifications, and twenty minutes later they cannot answer a question that has no right answer printed on a card.
Here's the scenario I like to use. We're onboarding a hundred thousand new users next month. Walk me through how you'd make sure the platform holds up. That's usually where it goes quiet.
It isn't that the candidate is lazy or not smart enough. They studied exactly what they were told to study. The problem is that the certification measured whether they could recognize the right answer out of four options, and the job is asking them to reason their way to it from a blank page. Those are two completely different skills, and nobody ever made them practice the second one.
I'm not anti-certification. I hold more than ten of them. But certs are the baseline, not the ceiling. So here are the three skills I actually test for, and more importantly, how to check whether you have them using an environment you already control.
The Trap: Certifications Teach What, Interviews Test Why
You study for AZ-104. You watch a couple of courses and fill a notebook with what every service does. A virtual machine gives you compute, a storage account holds your data, Azure SQL is your managed database. On paper, you've done everything right.
Then the scenario lands and there's nothing to recognize. Why this service instead of that one. Why this design survives the traffic spike when another one falls over. Why you'd spend the money here instead of there.
That "why" is the entire job. Everything below is about closing that gap, and each one is something you can practice this week.
None of which makes the certifications worthless. If you want the current lay of the land after Microsoft retired half the catalogue in 2026, I keep an Azure certification roadmap for 2027 as a field note. Just do not mistake the roadmap for the destination.
Skill 1: System Design
System design is the ability to take a real business problem and turn it into an Azure architecture that actually fits.
Here's a concrete one. A company's checkout page keeps falling over every time they run a promotion. System design isn't naming the services. It's deciding how the traffic flows, what scales when the spike hits, what happens when one component dies, and what the whole thing costs the business on the 364 days a year when there is no promotion.
And here's why it's genuinely hard. The same checkout problem at a small startup with two engineers and no budget looks nothing like that problem at a bank with a compliance team and twenty engineers. The services might overlap. The right answer changes completely depending on the constraints.
The mechanical half of this is practisable even when the judgement half is not. Deploying a full environment with Bicep forces you to commit an architecture to code, which is where a vague design falls apart fastest.
Now, can't you just ask Copilot to design it for you? You absolutely can, and it will hand you an architecture in about ten seconds. But it doesn't know your budget, it doesn't know your team, and it doesn't know that your data has to stay in Canada for compliance. If you can't evaluate what it gave you, you're flying blind, and you won't catch the part it got wrong.
The way you practice this is simple. Stop starting with the service list. Start with a problem, sketch the design on a blank page, and then justify every single decision out loud, the way you'll have to in the interview.
And when you inherit someone else's design, the first question worth asking is whether it actually scales the way somebody claimed it does. That part is checkable:
# List autoscale settings in a resource group. Does anything actually scale?
az monitor autoscale list \
--resource-group demo-rg-checkout \
--output table
If that comes back empty for a workload that's supposed to survive a promotion, what you have is a slide, not an architecture. I've run migrations where we moved more than fifty applications onto AKS, and I promise you, not one of those decisions came off a flashcard.
Gotcha: An autoscale rule that exists is not the same as an autoscale rule that helps. Check the minimum and maximum instance counts before you trust it. A rule with
--max-count 2on a workload expecting a ten-times spike will scale, hit the ceiling, and fall over anyway. It will look configured in every audit.
Skill 2: Cost Discipline
Here's how this problem shows up. A company moves to Azure, nobody is quite sure how much capacity they need, so an engineer picks a generous virtual machine size just to be safe. It works, nobody complains, and everyone moves on to the next thing.
Then eighteen months later, there's a server sized for a traffic spike that never arrived, storage piling up because nothing ever cleans it out, and finance asking why the bill went up again while nobody in the room can answer.
Across the whole industry, Flexera's 2025 State of the Cloud report puts wasted cloud spend at around 27%, and that number has barely moved in years.
Now here's the part people get wrong. They assume cost optimization just means picking the cheaper option, and it's far more nuanced than that. You might move a workload to serverless to stop paying for idle time, but at very high volume, serverless can actually cost you more than the server you were trying to replace. The cheaper option isn't always cheaper, and knowing the difference is the skill.
The analogy I use for this one: a cost alert that's configured but never actually fires is a smoke detector with the battery taken out. It's still on the wall, it still passes the inspection, and it will not wake you up when the room is on fire.
I've audited environments where every single one had a cost alert configured, and not one of them would have actually fired. So go check yours:
# List every budget on the subscription with its amount and current spend
az consumption budget list \
--output json \
--query "[].{name:name, amount:amount, timeGrain:timeGrain, spent:currentSpend.amount}"
If a budget comes back with no notifications attached, or the threshold sits at 100% of a number nobody has revisited in a year, that alert is decoration. Configuring the alert itself is the easy part. Picking a threshold that would actually change someone's behaviour before the money is gone is the skill.
Gotcha:
az consumption budget listis still a preview command, and it returns budgets scoped to the subscription. A budget someone created at the management group or billing account scope will not show up here, so an empty result doesn't always mean nobody set one. Check the broader scope before you declare the environment ungoverned.
The habit to build is weaving cost into your design from the very first decision. On every project, ask yourself one question: is there a way to build this that costs less and still solves the problem? That's what the business is actually paying you for.
Skill 3: Security by Default
Skill three is the one almost nobody practices. It's security, and specifically treating security as a way of thinking from the very first decision instead of a checklist you run at the end.
Here's why nobody practices it. A secure system and an insecure system look completely identical from the outside. Everything works, everything responds, the users are happy, right up until somebody finds the gap. And then you're not looking at a bug anymore, you're looking at a breach. IBM's 2025 Cost of a Data Breach report puts the average at roughly $4.44 million.
So what does practicing this actually look like? When you design something, you're already asking who can reach this, what's exposed that shouldn't be, and if this one component gets compromised, how far can the damage spread before anyone notices.
Both of those questions have a lab behind them. Conditional Access policies and MFA in Entra ID covers who can reach this, and securing a web app with managed identity and Key Vault covers the credential sprawl that turns one compromised component into six.
In practice that means managed identities instead of a secret sitting in your code, least privilege instead of handing everyone the Contributor role, and Conditional Access actually scoped to the right applications.
The fastest check I know is counting how many identities hold Contributor at subscription scope:
# Find every Contributor assignment at subscription scope, including inherited ones
az role assignment list \
--role Contributor \
--scope "/subscriptions/$(az account show --query id --output tsv)" \
--include-inherited \
--output json \
--query "[].{principal:principalName, type:principalType, scope:scope}"
Then check the other side of the same coin, which is how much of the estate has stopped storing credentials altogether:
# Which resources run on a system-assigned managed identity?
az resource list \
--query "[?identity.type=='SystemAssigned'].{name:name, type:type, group:resourceGroup}" \
--output table
Warning: Contributor can't grant roles, which is why people hand it out freely thinking it's the safe middle ground. It can still delete every resource in the scope, and it can read the secrets those resources hold. Treat a long Contributor list as a real finding, not a formality.
This matters more every single month, because AI is helping all of us ship code faster than ever, and Veracode's 2025 analysis found that nearly half of AI-generated code, around 45%, shipped with a security vulnerability in it. When code goes out the door that fast, somebody has to catch what's wrong before it reaches production, and that somebody is the cloud engineer.
The way you build this skill is to get into the habit of stress testing your own work. Take something you've designed and ask what breaks if these credentials leak, and how far someone can actually get. I've done this work for clients in regulated industries where a single over-permissioned identity is the difference between passing an audit and failing one. Using groups to manage role assignments is the boring fix that prevents most of it.
Auditing Your Own Environment
Three skills, three questions, three answers. Run this against any subscription you own:
#!/usr/bin/env bash
SUB_ID=$(az account show --query id --output tsv)
echo "== Budgets configured =="
az consumption budget list --output tsv --query "length(@)"
echo "== Contributor assignments at subscription scope =="
az role assignment list \
--role Contributor \
--scope "/subscriptions/$SUB_ID" \
--output tsv --query "length(@)"
echo "== Resources on a system-assigned managed identity =="
az resource list \
--query "length([?identity.type=='SystemAssigned'])" \
--output tsv
A real subscription I looked at recently came back like this:
== Budgets configured ==
0
== Contributor assignments at subscription scope ==
14
== Resources on a system-assigned managed identity ==
2
Zero budgets, fourteen Contributors, two managed identities. That's an environment that will surprise finance and won't survive an audit, and now you have three concrete problems to reason about instead of a service list to memorize. Fixing any one of them gives you a decision you can defend out loud, which is exactly what the interview is testing.
Pro tip: Run this before your next interview and bring the numbers with you. "I audited my own subscription, found fourteen Contributor assignments, and cut it to three using groups" is a better answer than any certification on your profile. It's evidence you can make a decision and live with it.
And if the audit turns up gaps, they are fixable the same afternoon. Configuring diagnostic settings on Azure resources closes the visibility half, and resource locks closes the accident half.
The Bigger Lesson
The biggest mistake I see is that people measure their progress by the wrong thing. They count the certifications they've collected and the hours of courses they've watched. All of that feels productive, but none of it tells you whether you're actually getting better.
There's only one question that does. What can you solve today that you couldn't solve thirty days ago?
Because at the end of all of this, you're not being paid to build the fanciest architecture with the newest services. You're being paid to make the business money or to save the business money, and every one of these three skills ties straight back to that.
A year from now, you can be sitting there with five more certifications and still no offers, wondering why nothing changed. Or you can spend that same year getting genuinely good at three things: designing systems that fit the problem, controlling what they cost, and securing them from the very first decision. Those are skills you can defend in any room.
If you want the longer version of why hands-on practice doesn't automatically turn into production judgment, I wrote about that in why cloud labs don't prepare you for real work.
Three field notes cover the other half of this. Four cloud skills that actually get you hired is the short version of what mid-level postings keep asking for, and four projects that make a cloud resume impossible to ignore is what to build once you have decided to stop collecting badges. If you are aiming at the AI side of the market specifically, the AI roles showing up most in cloud postings maps where those skills land.
I also walked through all three of these on camera, if you'd rather watch it: Your Azure Cert Won't Get You Hired. These 3 Skills Will.
