Hire Microsoft Azure developers

Azure is the cloud most enterprises already have through their Microsoft relationship, and hiring for it means finding someone who understands identity as much as infrastructure.

What Microsoft Azure actually is

Microsoft Azure is the second largest cloud platform, offering the usual range of compute, storage, networking, database, identity and analytics services. Its distinguishing commercial characteristic is its integration with the Microsoft estate: organisations already running Windows, Active Directory, Microsoft 365 and SQL Server frequently find Azure is the path of least resistance and is often already partly paid for.

That origin shapes the platform. Identity is unusually central, and Microsoft Entra, the identity service, is the backbone through which access to almost everything is granted. Engineers who understand identity, directory structure and conditional access are far more useful on Azure than engineers who know only the compute and storage services, because identity is where both the capability and the mistakes concentrate.

The practical complication is naming. Microsoft renames services and consoles with some frequency, and documentation, job specifications and candidate knowledge frequently refer to the same thing by different names depending on when they were written. This is a genuine source of confusion in hiring and it is worth normalising for rather than treating as a knowledge gap.

The part that separates seniors from mid-levels

The resource hierarchy is the first thing to understand, because it governs both permissions and cost. Management groups contain subscriptions, which contain resource groups, which contain resources. Role assignments and policies apply at each level and inherit downward. Getting this structure right early determines whether permissions can be scoped sensibly and whether anyone can tell which team is spending what. Getting it wrong is painful to correct once workloads depend on it.

Identity is the second and the area where Azure differs most from its competitors. Managed identities allow a resource to authenticate to another resource without any stored credential, which removes an entire class of secret management problem. An engineer who reaches for managed identities by default, rather than storing connection strings and keys, is describing both better security and less operational work.

The third is networking, which behaves differently from other platforms in ways that catch experienced people out. Virtual networks, network security groups, private endpoints and the various gateway types determine reachability, and the defaults are frequently more open than intended. Private endpoints in particular are how platform services are brought inside a network boundary, and their absence is a common finding in a security review.

Where Microsoft Azure is used

The label “Microsoft Azure developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Enterprise IT

Organisations already committed to Microsoft, where Azure is the default and often pre-purchased.

.NET application hosting

App Service, Functions and container services running .NET workloads with first-class tooling integration.

Hybrid infrastructure

Connecting on-premises data centres to cloud resources, an area where Azure invests heavily.

Data platforms

Synapse, Data Factory and Fabric for analytics, often alongside existing SQL Server estates.

Identity and access management

Entra as the identity provider for an organisation's applications, both in and outside Azure.

Regulated workloads

Government and healthcare environments using Azure's compliance and sovereign offerings.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Support status of the tools in this stack

Azure does not version the platform as a whole, so currency is judged by the services and patterns someone has used recently, with the added complication that Microsoft renames services periodically.

Microsoft Azure itself is not versioned as a single product, so the useful equivalent is the support status of the tools a Azure engineer works with daily. The table is read from public release data rather than written by hand, so it states what is supported now. It is worth having in front of you during an interview: asking which of these a candidate has upgraded, and what broke, gets you further than asking how many years they have used each.

Source: endoflife.date public release data, read 2026-09-25. A tool with no published end-of-life dates sets its support boundary by ecosystem practice rather than by policy.

The practical use of this is in judging an estate rather than a person. A team running several of these past their support dates is usually not behind by accident; it is behind because upgrades were never anyone's job. That is worth knowing before you hire, because it tells you whether the first six months will be building new things or paying down what was deferred.

The toolchain around it

Nobody hires for Microsoft Azure alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

Microsoft Entra

Identity and access. The most important service on the platform to understand properly.

Resource groups and management groups

The hierarchy governing permissions, policy and cost attribution.

App Service, Functions or AKS

Compute. App Service is the quickest path for web applications; AKS where orchestration is warranted.

Azure SQL or PostgreSQL Flexible Server

Managed databases, with Azure SQL familiar to teams coming from SQL Server.

Key Vault

Secrets, keys and certificates, ideally accessed through managed identities rather than credentials.

Bicep or Terraform

Infrastructure as code. Bicep is the native option and Terraform is common in multi-cloud organisations.

Azure Monitor and Log Analytics

Metrics, logs and alerting, with a query language that takes some learning.

Azure Policy

Governance enforced at the platform level rather than by convention.

Related skills that frequently appear on the same specification: .NET, AWS, DevOps, Kubernetes, Terraform.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

Identity and managed identities

The most distinctive and most important part of the platform.

• Strong answer: Uses managed identities rather than stored credentials, understands role assignment scope and inheritance, and can explain conditional access.
• Warning sign: Stores connection strings in application settings when a managed identity would work.

Resource hierarchy and governance

Determines whether permissions and cost can be managed at all.

• Strong answer: Structures subscriptions and resource groups deliberately, uses policy to enforce standards, and can attribute cost by team.
• Warning sign: Everything in one subscription and one resource group.

Networking and private endpoints

Where Azure security reviews find the most issues.

• Strong answer: Uses private endpoints for platform services, understands network security groups, and does not leave data services publicly reachable.
• Warning sign: Platform services exposed to the internet with only firewall rules.

Cost management

Architecture decisions are financial decisions here as on any cloud.

• Strong answer: Knows what drives their spend, uses reservations where load is steady, and has reduced a bill measurably.
• Warning sign: Has never seen the cost of infrastructure they designed.

Infrastructure as code

Portal-managed infrastructure is unreproducible.

• Strong answer: Everything in Bicep or Terraform, changes reviewed, and can explain why they chose one over the other.
• Warning sign: Builds in the portal and documents afterwards, or not at all.

Choosing compute

Azure offers several overlapping options and the choice matters.

• Strong answer: Can argue for App Service, Container Apps, Functions or AKS based on the workload and the team.
• Warning sign: Uses one service for everything, particularly AKS where App Service would do.

An incident they handled

Operational judgement is learned in production.

• Strong answer: Describes diagnosis using Azure Monitor, the mitigation and the change that followed.
• Warning sign: Has designed infrastructure but never operated it.

Warning signs in a Microsoft Azure codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

Stored credentials where a managed identity would work

• What you see: Connection strings and keys in application settings.
• What it costs: Credentials to rotate, to leak and to manage, for a problem the platform solves natively.
• The fix: Use managed identities for service-to-service authentication. It is both more secure and less work.

Flat subscription structure

• What you see: All workloads in one subscription with no resource group discipline.
• What it costs: Permissions cannot be scoped, cost cannot be attributed, and one mistake affects everything.
• The fix: Separate by environment and workload. Do it before the estate grows, because moving resources later is painful.

Public platform services

• What you see: Databases and storage accounts reachable from the internet, protected only by firewall rules.
• What it costs: A misconfigured rule becomes an exposure rather than an inconvenience.
• The fix: Use private endpoints so services are reachable only from within the network boundary.

Portal-built infrastructure

• What you see: Resources created by hand with no code representation.
• What it costs: Nothing reproducible, configuration nobody can explain, and disaster recovery that has never been tested.
• The fix: Define in Bicep or Terraform and import what exists. Restrict portal write access to production once under code.

AKS where App Service would do

• What you see: A Kubernetes cluster running a handful of web applications.
• What it costs: A large operational surface for capability the team does not use.
• The fix: Use the simplest service that meets the requirement. App Service and Container Apps cover most web workloads.

No cost attribution

• What you see: A single bill nobody can break down by team or workload.
• What it costs: Spend grows without anyone accountable, and reduction efforts have nowhere to start.
• The fix: Tag consistently and enforce tagging with policy. Structure subscriptions so the bill maps to ownership.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a Azure engineer.

Junior

Deploys and operates within an established subscription structure. Needs review on identity and networking.

Mid-level

Owns the infrastructure for a workload including its definition in code, monitoring and alerts.

Senior

Owns architecture, the identity and governance model, networking, cost and the failure design across an environment.

Staff

Owns the landing zone, policy and compliance baseline across subscriptions, and the commercial relationship including reservations and licensing.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

Landing zone build

• Usual team: One senior engineer.
• What governs it: Subscription structure, identity and networking set here are expensive to change later.

Application migration

• Usual team: Two engineers plus application owners.
• What governs it: Scoped by how much the applications assume about their environment, particularly identity and file access.

Cost optimisation

• Usual team: One engineer, time-boxed.
• What governs it: Reservations, right-sizing and idle resources. Usually high return where nothing has been governed.

Security and identity review

• Usual team: One senior engineer.
• What governs it: Private endpoints, role assignments and conditional access. Findings are usually substantial.

Infrastructure as code adoption

• Usual team: One engineer.
• What governs it: Importing an existing portal-built estate takes longer than building new, and reveals undocumented configuration.

Migration work you may actually be hiring for

A large share of Microsoft Azure work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

On-premises infrastructure to Azure

• Why teams do it: Reduced hardware ownership, elasticity, and integration with an existing Microsoft identity estate.
• What to watch: Identity integration is usually the first and largest piece of work. Applications that assume domain-joined servers, local file shares or Windows authentication need explicit rework rather than a lift and shift.

Stored credentials to managed identities

• Why teams do it: Removing secrets from configuration entirely, which eliminates rotation and leakage risk.
• What to watch: Straightforward and high value. The work is assigning the right roles at the right scope; resist granting broad permissions to make it work quickly.

A flat subscription to a structured landing zone

• Why teams do it: Scoped permissions, enforceable policy and cost attribution by team.
• What to watch: Far easier before the estate grows. Moving existing resources between subscriptions is possible for some resource types and not for others, so check before planning.

Portal-managed resources to Bicep or Terraform

• Why teams do it: Reproducibility, review and real disaster recovery.
• What to watch: Import rather than recreate, and expect to find configuration nobody documented. Choose Bicep for Azure-only estates and Terraform where other platforms are in play.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a Azure engineer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• How the subscription and resource group structure is organised, since this governs everything else.
• Whether identity is integrated with an existing on-premises directory.
• Which compute services are in use, because App Service and AKS imply different skill sets.
• Whether infrastructure is defined in code, and in Bicep or Terraform.
• What the current spend is and whether reduction is part of the brief.
• Whether the work is a migration, a build, or governance remediation.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

Microsoft Azure work is counted by the US Bureau of Labor Statistics under Network and Computer Systems Administrators. That classification is broader than the technology itself, so treat the figures as the shape of the market a Azure engineer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 314,340 people in this occupation, with a median annual wage of $99,130.

The spread matters more than the midpoint. The 90th percentile is about 2.5 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a Azure engineer can sit at $62,640 and $155,050 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for Microsoft Azure frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Network and Computer Systems Administrators, the gap between the highest and lowest of the 28 metro areas covered here is a factor of about 1.7. San Jose sits at the top with a median of $133,360; Pittsburgh sits at the bottom with $80,440. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. Washington, D.C., Baltimore, Austin, Raleigh, Tampa, Charlotte each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

Infrastructure knowledge without identity depth. Identity is where Azure differs most. Ask about managed identities and role scope specifically.

Portal-driven habits. Ask how their infrastructure is defined. Manual estates are a real operational liability.

Service naming confusion. Microsoft renames things. Normalise for this rather than treating unfamiliar current names as a gap.

No cost accountability. Ask what their last environment cost. Architecture without cost awareness produces expensive surprises.

Hiring Microsoft Azure developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of Azure engineer who will be available.

• New York, NY $119,390 median
• Seattle, WA $104,440 median
• San Jose, CA $133,360 median
• Washington, D.C. $125,430 median
• San Francisco, CA $129,680 median
• Dallas-Fort Worth, TX $103,260 median
• Los Angeles, CA $106,290 median
• Boston, MA $116,770 median
• Chicago, IL $103,170 median
• Atlanta, GA $101,000 median
• Austin, TX $104,520 median
• Phoenix, AZ $93,730 median
• Philadelphia, PA $100,460 median
• Minneapolis-St. Paul, MN $102,790 median
• Denver, CO $105,090 median
• Detroit, MI $96,400 median
• Houston, TX $101,430 median
• Charlotte, NC $89,990 median
• San Diego, CA $105,170 median
• Salt Lake City, UT $99,110 median
• Miami, FL $97,180 median
• Portland, OR $102,950 median
• Baltimore, MD $122,950 median
• Tampa, FL $101,560 median
• Orlando, FL $91,800 median
• Raleigh, NC $103,380 median
• Kansas City, MO $91,980 median
• Pittsburgh, PA $80,440 median

Frequently asked questions

Azure or AWS?

Azure if your organisation is already invested in Microsoft, because identity integration, existing licensing and enterprise agreements usually make it both cheaper and easier. AWS if you are starting without that commitment and want the largest service catalogue and hiring pool. Both are capable, and for most enterprises the existing Microsoft relationship is the deciding factor rather than any technical comparison.

Do we need Azure-specific people or will cloud engineers transfer?

Core concepts transfer well: networking, compute, storage and infrastructure as code are conceptually similar across platforms. What does not transfer as readily is Azure's identity model, which is genuinely distinctive and central to how the platform works. A strong AWS engineer becomes productive on Azure quickly, and identity is where they will need the most ramp.

What is the most common Azure security problem?

In reviews we see, platform services such as databases and storage accounts reachable from the internet, protected only by firewall rules rather than being brought inside the network with private endpoints. After that, over-broad role assignments at subscription scope that were granted to unblock something and never narrowed.

Should we use App Service, Container Apps or AKS?

App Service for straightforward web applications and APIs; it is the quickest path and requires the least operational work. Container Apps where you want containers without managing a cluster. AKS where you genuinely need orchestration, which usually means many services and several teams. Adopting AKS for a handful of applications buys operational burden without benefit.

How do we control Azure costs?

Structure the estate so the bill maps to ownership, which means subscription and resource group discipline plus enforced tagging. After that, the usual wins are reservations on genuinely steady workloads, right-sizing, removing idle resources, and reviewing log retention. Cost cannot be managed before it can be attributed, and attribution is where most organisations are stuck.

Is Azure better for .NET?

It has the smoothest path, with first-class tooling integration, deployment from the development environment, and services that assume the Microsoft stack. .NET runs perfectly well on other clouds and in containers anywhere. The advantage is real and it is about friction rather than capability.

What are managed identities and why do they matter?

They let an Azure resource authenticate to another Azure resource without any stored credential. The platform handles the identity and the token exchange. It removes an entire category of secret management, rotation and leakage risk, and it is one of the genuinely strong parts of the platform. An engineer not using them where available is creating work and risk unnecessarily.

Why is Azure documentation so confusing about service names?

Because Microsoft renames services and consoles reasonably often, so documentation, training material and candidate knowledge refer to the same thing by different names depending on vintage. It is worth accounting for in hiring: someone describing a service by its previous name is usually showing you when they learned it rather than a gap in what they know.