Hire Azure Developers in India
Almost nobody sets out to hire Azure developers in India because they compared clouds and Azure won. They run Microsoft already, the estate arrived with the licensing agreement, and the job is to work sensibly inside decisions somebody else made years ago. That single fact should change who you interview.
Why an Azure Hire Usually Sits Closer to IT Than to Your Product Team
There is a pattern behind most Azure adoption, and recognising it tells you what kind of person will actually succeed in the role.
The choice was made above engineering
Companies rarely arrive at Azure through a technical bake off. They arrive because they already pay Microsoft for Windows Server, SQL Server, Microsoft 365 and Entra ID, because a renewal conversation put credit on the table, and because the finance team preferred one supplier relationship to two. By the time an engineer is asked for an opinion, the tenant exists, the directory is populated with every employee, and the first subscriptions have already been created by somebody in central IT.
That origin story shapes everything. On a greenfield cloud the first questions are architectural. On a typical Azure estate the first questions are political and procedural: which team owns this subscription, who approves a new resource group, why does policy refuse to let me create a public IP, and who do I ask to get an exception. An engineer who has only worked on self service cloud accounts finds this maddening. An engineer who has worked in an enterprise finds it normal and gets on with it.
The directory belongs to the whole company, not to you
On other clouds, identity is a thing you build for the workload. On Azure, identity usually predates the workload by a decade. The Entra tenant your application authenticates against is the same directory that governs laptop sign in, mailbox access, Teams and the HR system. Conditional Access policies written by a security team you have never met apply to service accounts you created this morning.
This is genuinely good for security and genuinely awkward for delivery. It means your engineer cannot simply create identities to solve a problem, and it means a change that would take five minutes on a personal account requires a conversation with the people who own the directory. Hire someone who expects that conversation instead of someone who treats it as an obstacle to route around.
Governance arrives before the second workload
An enterprise that has committed spend to Azure tends to build guard rails early, because the alternative is a hundred teams creating resources in a hundred different shapes. Management groups, policy assignments, naming conventions, mandatory tags, allowed regions, restricted SKUs. Half of this exists before the second real workload lands. Your new hire will spend more time reading policy definitions than they will spend choosing between two database services.
Where a product shaped engineer struggles
Someone whose instinct is to ship fast and refactor later will have a bad time. Not because they lack skill, but because the estate rewards different habits. The valuable behaviours here are reading before changing, understanding the blast radius of a scope, writing down why an exception was granted, and knowing which decisions are reversible and which are not. If your Azure work genuinely is a small greenfield product with its own tenant, say so plainly in the brief, because the person you want is different.
If you are still deciding what the role even is, or whether you need cloud people at all, the wider hire developers in India page walks through how the engagement types differ before you commit to a specific skill.
What Does an Azure Engineer Actually Do in a Week?
Job adverts describe this role as designing and building scalable cloud solutions. The real week has a lot more reading, waiting and negotiating in it than that sentence suggests.
Access requests, most days
A developer cannot see a resource group. A data analyst needs read on a storage account but not on the one next to it. A contractor is leaving. This is unglamorous and constant, and the engineers worth keeping are the ones who turn the fourth identical request into a group, a role assignment at the right scope, and a short page explaining how to ask next time.
Working out why policy said no
A deployment fails with a message about a policy assignment nobody recognises, inherited from a management group two levels up. Half the job is tracing which assignment matched, deciding whether the rule is right, and either fixing the deployment or arguing for a scoped exemption. Both outcomes need writing down.
The infrastructure work itself
Bicep or Terraform changes, a new spoke network, a private endpoint for a storage account, a pipeline that promotes to a second region. This is the part people picture when they write the job description, and it is perhaps a third of the week on a good week.
Reading the invoice
Not the portal cost view, the actual billing export. Which subscription grew, which resource group inside it, whether a reservation is being wasted because somebody resized every virtual machine to a different family. On an enterprise agreement, cost questions arrive from finance with a deadline attached.
Change process, ticket by ticket
Larger Azure customers usually have a change advisory process, a maintenance window and an approval chain. A cloud engineer who has never worked inside one underestimates how much time it takes and how much of the skill is writing a change record clearly enough that someone unfamiliar with the system will approve it.
Keeping the estate current
AKS versions age out of support. Node images, runtime stacks for App Service, TLS settings, provider versions and agent pools all keep their own clocks. Somebody has to own that calendar, and if nobody does you find out about it during an audit or an outage rather than during a planning session.
If you read that list and thought it sounded like an internal IT job, that is the honest impression and it is worth trusting. Azure engineering in an established estate is closer to running a shared utility than to building a product. Candidates who want to build products will be restless by month three, and you will have paid for that discovery.
Identity First: Entra ID, Tenants, Subscriptions and Management Groups
If you only test one thing properly, test this. Compute decisions can be changed in a weekend. Identity decisions follow you for years, and some of them cannot be undone at all without rebuilding.
Entra ID is a directory, not an access management service
Microsoft renamed Azure Active Directory to Microsoft Entra ID, and the rename confused a generation of job adverts, but the substance is unchanged. Entra ID is a directory of people, groups, devices and application identities. It is the thing your staff sign into. It is not, on its own, the system that decides who may restart a virtual machine.
That second job belongs to Azure RBAC, which is a separate assignment model layered over your resources. The two systems share the same identities and nothing else. A candidate who talks about them interchangeably has not spent long in a real tenant, because the first time you need to explain to an auditor why someone with a high directory role could not read a resource group, the distinction stops being academic.
What actually nests inside what
The hierarchy is worth being able to draw from memory. A tenant contains a root management group. Management groups nest inside each other and hold subscriptions. Subscriptions hold resource groups. Resource groups hold resources. Policy and RBAC both flow downward through that chain, which is why a permissive assignment high up is so much more dangerous than the same assignment at the bottom.
The subscription is the boundary people most often get wrong. It is a billing container, a quota container and a security container all at once, and teams routinely design it for only one of those three. One subscription per environment, per business unit, per product, or some hybrid of all three: there is no universally correct answer, but there is a wrong one, which is deciding by accident and discovering the shape you ended up with two years later.
Two permission planes and the elevation switch between them
Ask a candidate what happens when a Global Administrator needs to fix a subscription they have no access to. The answer involves a deliberate elevation that grants User Access Administrator at the root scope, which is a powerful and auditable action. Someone who knows that also knows it is meant to be temporary, and that leaving it switched on quietly hands the directory administrators standing control over every resource in the estate.
The related trap is group nesting. Access granted through a group that contains another group that contains a third feels tidy and becomes impossible to reason about. When somebody asks who can delete this database, a healthy estate answers in one query rather than in an afternoon of investigation.
Service principals, managed identities and the app registration graveyard
Every automation in Azure authenticates as something. The good answer is a managed identity, where the platform holds the credential and no secret ever appears in a pipeline variable or a configuration file. System assigned identities live and die with the resource they belong to. User assigned identities outlive their resources, which is useful for shared access and dangerous when nobody removes them.
The bad answer is an app registration with a client secret, created by a developer three years ago, holding Contributor at subscription scope, with an expiry date nobody tracks. Most established tenants have several. Ask a candidate how they would find them and what order they would clean them up in. Listen for whether they check sign in activity before deleting anything, because removing the identity that a nightly job depends on is a memorable way to start a new position.
Conditional Access, privileged roles and the account you must never lose
Conditional Access is where an enterprise expresses its actual security posture: which sign ins require multifactor, from which devices, from which locations, for which applications. Privileged Identity Management adds time bound, approved activation for sensitive roles so nobody carries them permanently. Both sit in the paid Entra tiers, so check which plan your organisation holds before designing around them.
Then there is the emergency access account. Every tenant needs at least one identity excluded from the Conditional Access policies that could otherwise lock everybody out, stored properly and monitored for use. A candidate who raises break glass accounts without being prompted has been present when a policy change locked a company out of its own directory, and that experience is worth a great deal to you.
Why identity mistakes are the hardest thing on this page to unwind
Here is the specific reason to spend interview time here. Most Azure mistakes are recoverable with money and downtime. Identity mistakes are recoverable with a project.
Consider moving a subscription from one tenant to another, which comes up after an acquisition or after somebody creates production in the wrong place. The subscription can move. What does not move with it is every RBAC assignment, because those reference identities that do not exist in the destination directory, and every managed identity attached to resources inside it, which stops working because the identity lived in the old tenant. Key Vault access policies, federated credentials on app registrations, and anything that trusted the old tenant identifier all need to be rebuilt. It is doable. It is a project with a plan and a rollback, not a change ticket.
Two tenants after a merger are worse, because directories do not merge. You migrate identities, re-establish trust, or run both for years while deciding. Anyone who has lived through that will tell you about it at length, and you should let them, because the scar tissue is the qualification.
Landing Zones and Governance, or Why an Enterprise Estate Looks Nothing Like a Startup's
A startup's cloud grows outward from one working application. An enterprise estate grows downward from a set of rules written before the first application existed. Both approaches are reasonable. They produce very different jobs.
What a landing zone actually is
Strip away the marketing and a landing zone is a pre built, pre governed place for a workload to arrive in. Subscription created from a known pattern, network already peered to the hub, identity and role assignments already wired, logging already forwarded to the central workspace, policy already applied, tags already mandatory. A team asks for somewhere to deploy and gets a subscription that already complies with everything the organisation cares about.
Microsoft publishes a reference architecture for this in the Cloud Adoption Framework, along with implementations you can deploy. The reference is genuinely useful and it is also far larger than most mid sized companies need. A candidate who has adopted it wholesale without pruning has created an estate their colleagues cannot understand. Ask which parts they left out and why. That answer separates people who have implemented a landing zone from people who have read about one.
Azure Policy, and the difference between audit and deny
Policy is the mechanism that makes governance real rather than aspirational. Definitions describe a condition and an effect. Effects include auditing a resource, denying its creation outright, modifying it as it is created, and deploying something alongside it when a requirement is missing. Initiatives group definitions so you can assign a coherent set in one action.
The interesting judgement is not knowing the effects. It is knowing the order to introduce them in. Assign deny to an estate that has been running for three years without it and you will break deployments in teams you have never spoken to, on a Tuesday, with no warning. The sequence that works is audit first, publish the non compliance report, give teams a deadline they were consulted about, then switch to deny for new resources while existing ones are remediated. An engineer who has done this describes it as a communication exercise with a technical component, which is exactly right.
Blueprints, template specs and deployment stacks
You will still find Azure Blueprints in older estates, bundling policy assignments, role assignments and templates into a versioned artefact. Microsoft has published a deprecation path away from it and points teams towards template specs, deployment stacks and third party infrastructure as code instead. Do not take my word for the current status, because these timelines move: check the Azure documentation for the version you are on before you build anything new on Blueprints. What matters for hiring is whether the candidate knows the direction of travel or is still recommending it as the default.
Naming, tagging and the boundaries you cannot change later
Naming conventions feel like bureaucracy until the day someone has to find every resource belonging to a decommissioned product across forty resource groups. Tags feel like bureaucracy until finance asks which business unit owns a line item. Both are cheap to establish and expensive to retrofit, and several Azure resource types cannot be renamed at all once created, so the convention has to exist before the first deployment rather than after the first audit.
Resource groups deserve their own thought. They are a lifecycle boundary, not a filing cabinet. Things that are created together, deleted together and permissioned together belong in one. Teams that use them as folders end up unable to delete anything safely, because the group contains a mix of disposable test resources and the storage account holding four years of records.
The governance signal to listen for
Ask what they would do on day one in an estate with no policy at all and forty subscriptions already running. The weak answer designs the perfect management group hierarchy on a whiteboard. The strong answer starts by finding out what is actually there, assigns audit only policies to measure it, and produces a compliance picture before proposing a single restriction. You cannot govern what you have not yet counted.
Compute Choices, and the Situations Where Each One Is Wrong
Anyone can list the options. What you are testing is whether they can argue against their own preference, because that is the skill that stops an estate filling up with the one service the last contractor liked.
App Service, and the ceiling it hides
App Service is often the right answer and is dismissed too quickly by people who find it unfashionable. Deployment slots, built in certificate management, autoscale rules and a runtime somebody else patches remove a lot of undifferentiated work from a small team.
It goes wrong in two predictable ways. The first is outbound connection exhaustion: an application opening a new connection per request to a database or an external API will run out of source ports on the plan and start failing in a way that looks intermittent and blames the network. The second is the shared plan trap, where five applications sit on one plan because it seemed economical and then one of them consumes the memory during a traffic spike and takes the others down with it. Ask a candidate what they would check first when an App Service application slows down under load and see whether connection handling appears in the answer.
Functions, and the cold start you did not budget for
Event driven code with no server to look after is a genuinely good deal for scheduled jobs, queue processing and webhook handling. On a consumption model you also pay only for what runs, which suits work that arrives in bursts.
It is the wrong choice for anything with a strict latency requirement on the first request. A scaled to zero function with a heavy dependency graph can take seconds to answer a cold invocation, and putting that behind a customer facing endpoint produces complaints that are hard to reproduce because the second request is always fast. There are hosting plans that keep instances warm, and the available plans and their behaviours change often enough that you should read the current Azure Functions hosting documentation rather than trusting anyone's memory, including mine. The interview question is not which plan. It is whether the candidate asks what the latency requirement is before choosing.
Container Apps, for teams who want containers without a cluster
Container Apps sits in a useful middle. You get containers, revisions, traffic splitting and scaling driven by event sources through KEDA, including scale to zero, without operating a Kubernetes control plane or writing manifests. For a set of microservices that need to scale on queue depth rather than on CPU, it is frequently a better fit than the cluster people reach for by reflex.
It is wrong when you genuinely need the Kubernetes API. Custom operators, admission controllers, DaemonSets, service meshes with specific requirements, or a platform team that has already standardised on Kubernetes tooling across clouds. Choosing Container Apps and then fighting to reproduce cluster behaviour inside it wastes the simplicity you chose it for.
AKS, and the tax nobody puts in the business case
Azure Kubernetes Service is the right answer when you have enough services, enough teams and enough traffic that a shared scheduling layer pays for itself, or when you are running workloads that assume Kubernetes. Microsoft manages the control plane; you still own node pools, upgrades, networking mode, ingress, secrets, autoscaling behaviour and the observability stack.
The tax is ongoing. Kubernetes releases move and support windows expire, so upgrades are a recurring calendar item rather than a project. The networking model is chosen at cluster creation and changing it later usually means building a new cluster. Node image maintenance, capacity planning and the internal knowledge required to debug at three in the morning all belong to you. A team of eight running four services does not need this, and if a candidate reaches for AKS in that scenario without asking a single question, you have learned something useful. For the deeper cluster conversation, our DevOps engineers in India page goes through what operating one actually demands week to week.
Virtual machines, which are still correct more often than fashion admits
Plenty of Azure workloads belong on virtual machines and the reasons are usually commercial rather than technical. Licensed software that is only supported on a specific operating system build. A vendor application with an installer and no container image. An existing Windows Server or SQL Server estate where existing licences reduce the cost of running the same thing in Azure. A workload with a compliance requirement that is easier to evidence when you control the whole machine.
Where virtual machines go wrong is when nobody owns them. Unpatched images, no configuration management, snapshots taken by hand before a change, and a machine that cannot be rebuilt because the last three fixes were applied by remote desktop and never written down. If the estate you are hiring into is mostly virtual machines, say so in the brief and screen for configuration management and patching discipline, not for serverless enthusiasm.
Making the candidate defend a decision
Give them a real shape and let them choose. An internal application, a few hundred users inside the company, sensitive data, a Windows development team, and a deadline. Then push. Why not Functions. Why not the cluster the platform team already runs. What would change your answer. What would you regret in a year. Somebody with judgement will name the thing they are trading away. Somebody without it defends the first answer harder.
Networking Is Where Azure Catches People Out
Compute choices are visible and get argued about in design reviews. The connectivity diagram is the thing that quietly decides whether the estate is workable, and it is where the most confident candidates fall over.
Peering does not chain
Two virtual networks peered together can talk. Peer a third to one of them and it cannot reach the other. Peering is not transitive, and that one property drives almost every topology decision that follows. Engineers arriving from other clouds assume routing will just work and design a mesh that becomes unmanageable at about the sixth network.
The consequence is that any hub and spoke design needs something in the middle doing the routing, and that something has to be deliberately chosen. A firewall appliance, a network virtual appliance, or a managed wide area networking service that handles the transit for you. Ask a candidate to draw connectivity for three spokes that must reach a shared services network but must not reach each other. Watch whether route tables appear in the drawing without prompting.
What belongs in the hub
A hub is not a network with a nice name. It holds the things every spoke depends on and nobody wants duplicated: the gateway to your own data centre or offices, the firewall, DNS resolution, shared identity infrastructure, and often the jump path administrators use to reach private resources. Everything in it is a shared fate component, which means a change there affects every workload at once.
The failure mode is a hub that accumulated services because someone needed somewhere to put them. A database in the hub. An application in the hub. Now your central network has a change window driven by a product team, and the firewall cannot be upgraded without coordinating with people who do not know they depend on it.
The private endpoint that still resolves to a public address
This is the single best Azure screening question I know, and it fails more senior candidates than anything else on this page.
A private endpoint gives a platform service a network interface with a private address inside your subnet. Traffic can now reach that storage account or database privately. The part people miss is that reaching it requires name resolution to cooperate. Public DNS for those service names resolves through a private link alias, and unless your virtual network is using DNS that returns the private address, the client will happily resolve the public one and take the public path, or fail if public access has been disabled.
So the endpoint exists, the portal shows it as approved, the connection is refused or is quietly not private at all, and everyone blames the firewall. The fix involves a private DNS zone for that service, linked to the right networks, with the record for the resource in it, plus a resolution path from wherever the client actually sits, including the on premises side if traffic arrives over a gateway. A candidate who has been through this will start talking about DNS before you finish describing the symptom.
Service endpoints are not the same thing
Service endpoints predate private endpoints and still turn up. They keep traffic to a platform service on the Azure backbone and let the service restrict access to a subnet, but the resource keeps its public name and public address, and access from your own data centre is a different conversation entirely. They are simpler and cheaper. They are not equivalent, and a candidate who treats them as interchangeable will design something that does not satisfy the requirement your security team actually wrote down.
Route tables, forced tunnelling and the appliance in the middle
Once a firewall exists, traffic has to be pointed at it, and that means user defined routes attached to subnets. This is where asymmetric routing appears: return traffic taking a different path from the outbound leg, the firewall dropping it as unrecognised, and an application failing in a way that looks like packet loss. Forced tunnelling, where internet bound traffic is pushed back to your own data centre for inspection, adds latency and a dependency on a link you do not control.
None of this is exotic. All of it is invisible in a design document that only shows compute. Ask for the diagram with arrows on it.
Address space, and the acquisition that ruins it
Somebody has to allocate address ranges before the first network exists, with room for growth, without colliding with the ranges already used on your own network or by any company you might buy. Overlapping ranges cannot be peered, and the remedies are all unpleasant: renumber a live environment, or introduce translation and live with the complexity forever.
An engineer who asks for your existing address plan in the first week is showing you they have been burned. That is a good sign. If you are designing this from scratch rather than hiring into it, our cloud architecture services in India covers the topology work as a scoped piece rather than as a role.
Cost, Reservations, and the Agreement That Quietly Decides Your Architecture
On Azure, more often than on any other cloud, the commercial arrangement drives technical choices. Pretending otherwise produces designs that get rejected for reasons the engineer never saw coming.
The agreement usually predates the architecture
Larger Azure customers buy through an enterprise agreement or a Microsoft customer agreement, sometimes through a partner under a cloud solution provider arrangement. Each of those puts a different structure between your engineers and the meter: who can create subscriptions, where the billing hierarchy sits, which discounts apply, and what commitments have already been made for the year.
The practical consequence is that a design can be technically excellent and commercially unacceptable. A proposal to move a workload to a service outside the committed spend will lose to a slightly worse design that consumes what has already been paid for, and it will lose without a technical discussion. An engineer who has worked in this environment knows to ask about the agreement early. One who has not will be surprised, repeatedly, and will read the surprise as politics.
Reservations, savings plans and the shape of your commitment
Discounts on steady workloads come from committing ahead of time, usually for a term of one or three years, in exchange for a lower rate. Reservations are tied more closely to what you actually run, so a virtual machine reservation applies to a particular family in a particular region and stops applying if somebody resizes the machine to something else. A savings plan trades some of that specificity for flexibility across compute services.
Rates, terms and eligibility change, so check current Microsoft pricing documentation rather than a number in a blog post, including this one. What you are testing in an interview is understanding of the mechanism: that a reservation is a financial instrument attached to a technical shape, that unused commitment is money already spent, and that a well meant right sizing exercise can quietly strand a purchase somebody in finance defended to a board.
Azure Hybrid Benefit and the licences you already own
This is a genuinely Azure specific lever and it is routinely missed by engineers who came from elsewhere. Organisations with existing Windows Server or SQL Server licences under Software Assurance can apply them to equivalent Azure compute rather than paying for the licence again inside the hourly rate. Whether it applies, to which resources, and under what conditions is a licensing question with real conditions attached, so it belongs with whoever manages your Microsoft agreement.
Why it matters for hiring: this is one of the few places where the right architecture depends on what your legal agreements say. A candidate who has never heard of it will design as though every machine is licence inclusive, and the difference on a large Windows estate is not a rounding error.
Development and test subscriptions
Microsoft offers subscription types intended for non production work at different rates, with eligibility conditions attached about who may use them and for what. They are useful and they are also a common source of quiet non compliance, because a development subscription that ends up serving real users is a problem for your agreement rather than for your architecture. Ask a candidate how they keep the boundary honest.
What a cost aware engineer actually looks like
They read the billing export rather than the summary tile. They can tell you which line item grew and which resource group it belongs to. They notice storage sitting on a performance tier that no longer matches how it is accessed. They know that logging and network egress are architecture decisions with invoices attached rather than background noise. And they raise cost in a design review, before the build, rather than in a panic six months later when finance escalates.
Bicep or Terraform? The Honest Trade
Both are good. Neither is universally right. What you want from a candidate is the ability to say why one loses, which is harder than it sounds because most engineers have a favourite and defend it as though it were a principle.
What Bicep actually is
Bicep is a domain specific language that compiles to Azure Resource Manager templates. Resource Manager is doing the deployment either way, so Bicep is best understood as a much better authoring experience over the same engine rather than as a competing tool. That relationship gives it two real advantages: there is no state file to store, protect or repair, and new resource types and properties are usable as soon as the Resource Manager API exposes them, because there is no intermediate provider to wait for.
Two mechanisms are worth testing. Deployment mode matters, because a complete deployment at resource group scope will remove resources that are not described in the template, which is either exactly what you want or a very bad afternoon. And the what if operation, which previews the changes a deployment would make, is the closest equivalent to a plan step. A candidate who deploys without previewing is telling you how their last team worked.
What Terraform gives you, and what it costs
Terraform earns its place when Azure is not the whole picture. One workflow that also covers your DNS provider, your identity provider, your monitoring vendor and a second cloud is worth real money in consistency and in the time your team spends context switching. The module ecosystem is mature, the plan output is legible to reviewers, and a lot of engineers are already fluent.
The costs are equally real. State has to live somewhere durable, be locked so two pipelines cannot collide, and be treated as sensitive because it can contain secrets. Provider coverage lags the Azure API, so a brand new service or property may not be expressible until the provider catches up, which is what the escape hatch provider that talks to the Resource Manager API directly exists for. And drift becomes something you manage explicitly, because Terraform believes its state until it is corrected.
How the decision usually goes
If your estate is entirely Azure, your team is closer to Microsoft tooling than to HashiCorp tooling, and nobody has strong Terraform experience, Bicep is the path of least resistance and there is no shame in it. If you already run Terraform elsewhere, or you manage significant infrastructure outside Azure, or your engineers are fluent in it, use Terraform and do not fragment your workflow for purity.
The worst outcome is the split estate: some resources in Bicep, some in Terraform, some clicked into the portal during an incident and never brought back. Ask any candidate what they would do with an estate in that state. The mature answer is to stop the bleeding first by blocking portal changes in production, then bring resources under management in order of consequence, importing rather than recreating anything that holds data. Anyone whose first instinct is a full rewrite has not had to explain a rewrite to a finance director. Where this is a bounded piece of work rather than a permanent job, our cloud architecture services in India can take it as a project instead.
Azure DevOps or GitHub Actions?
A lot of writing on this subject assumes everyone has already moved. In Microsoft centred companies, plenty have not, and there are decent reasons for that.
Why so many Azure shops still run Azure DevOps
Azure DevOps bundles repositories, boards, pipelines, artefact feeds and test management into one product with one permission model, and for organisations that adopted it years ago that integration is the whole point. Classic release pipelines with approval gates map neatly onto a change process that already had approval gates. Self hosted agents sit inside the corporate network and reach systems that a public runner cannot. Audit trails live in one place, which matters when someone has to evidence who approved a production change.
Treating that as legacy in an interview is a mistake. An engineer who has run a complicated release process through Azure DevOps has skills that transfer, and dismissing the tool tells your candidate you have not understood the environment they would be joining.
Where GitHub Actions is genuinely better
Workflows live beside the code in the repository, so a pipeline change gets reviewed like any other change. The marketplace of actions is enormous. Contributors already know it, which shortens onboarding. And Microsoft's own investment has clearly moved in that direction, which shows up in how quickly new integrations appear there first.
The friction in an enterprise is usually network and control rather than features. Reaching private resources means self hosted runners, which somebody has to maintain and secure. Approval and environment protection needs designing to match a process that predates it. And organisation wide policy about which third party actions may be used is a real piece of work that teams tend to discover late.
The question that matters more than the product
Ask how the pipeline proves who it is when it deploys. The answer you want is workload identity federation: a short lived token exchanged for Azure access, with no secret stored anywhere in the CI system. Both products support this pattern.
The answer you often get is a service principal secret pasted into a variable group or a repository secret, created by someone who left, holding Owner at subscription scope, with an expiry that will surprise everybody on a Sunday. That single answer tells you more about the estate you are inheriting than an hour of architecture discussion.
Migration, and why it stalls halfway
Teams that move usually move the easy things first. New repositories go to GitHub, the build pipelines follow, and then the migration stops, because the remaining work is the release pipeline with eleven approval stages, the self hosted agent pool with a hand configured tool on it, and the artefact feed three other teams consume. Two years later there are two systems, two sets of credentials and two places to look during an incident.
If that is your situation, hire someone who has finished a migration rather than someone who has started one. The interesting experience is in the last twenty per cent.
How Do You Screen an Azure Engineer in an Hour?
Put a broken system in front of them and make them debug it out loud. Withhold detail deliberately, so there is no correct answer available, only a method. You are watching what they ask first, what they eliminate, and whether they reach for evidence or for a story.
The deployment succeeded and the site returns 502
Pipeline green, resource updated, browser shows a bad gateway. The weak response redeploys. The next weakest declares it a platform problem.
What you want is somebody who immediately separates the platform from the application. Resource Manager reported success because it created what the template described; whether the process inside actually started is a different question with a different log. From there the list is short and they should walk it: the container listening on a port the platform is not sending traffic to, an application that exceeded its startup window and was killed before it finished booting, a missing configuration value so the process crashed on start, a runtime version changed underneath it, a slot swapped before it had warmed up, or a health probe pointing at a path that was never implemented. Listen for whether they name where they would look, not just what they suspect. The candidates who have lived this go straight to the application log stream and the container start output rather than to the deployment history.
The private endpoint that resolves to a public address
Describe it plainly. A storage account was locked down and given a private endpoint. The application inside the virtual network can still reach it, but a packet capture shows traffic leaving over the internet. Nothing errors. What is happening?
This is the question I would keep if I could only ask one. The endpoint is a networking object; making clients use it is a naming problem. Somebody who has done this describes the private DNS zone for the service, the link between that zone and the network, whether the record for the resource was actually created, and what the virtual network is using for resolution in the first place. The best answers go one step further and ask where the client sits, because a request arriving from your own data centre over a gateway resolves through your DNS servers and needs a forwarding path to reach the Azure resolver at all. Candidates who only ever clicked the box that offers to create the zone for them do not know the box exists to do this.
The function that takes eight seconds to answer the first request
An HTTP triggered function is fast in testing and slow in production, but only sometimes, and only the first request after a quiet period. Product is describing it as flaky.
You want cold start named quickly, then reasoning rather than a memorised fix. Where did the eight seconds go: platform instance allocation, runtime start, dependency loading, or the application's own initialisation work such as opening a connection pool or fetching configuration and secrets on first use. Then the options, with trade offs attached: a hosting plan that keeps instances warm, reducing what happens during startup, moving initialisation out of the request path, or accepting that this workload should not be behind a synchronous endpoint at all. A candidate who answers only with the name of a more expensive plan has skipped the diagnosis and gone to the shop.
A subscription hits a quota nobody knew existed
Scaling event at ten in the morning, new instances refuse to start, error mentions a limit. The team has never heard of it.
Quotas in Azure apply per subscription, per region, and often per resource family rather than globally, which is precisely why they surprise people: capacity existed in the region, in the same subscription, for a different machine family. A good answer covers where to read current usage against limits, that increases are requested rather than instant, that some limits are adjustable and some are hard, and that the numbers change often enough to be looked up rather than remembered. The senior answer arrives at the real defect, which is that a quota consumed to ninety per cent should have been an alert weeks earlier rather than a discovery during an incident. Anybody who has run a large estate treats headroom as something monitored.
The role assignment that appears to do nothing
You granted a developer a role. They still cannot do the thing. Nothing has changed for twenty minutes.
Several distinct causes hide behind identical symptoms and separating them is the skill: the assignment was made at the wrong scope so it does not cover the resource in question, a deny assignment or a lock is overriding it, the role does not include the action the operation actually performs, the token in the user's session predates the change and has not been refreshed, or the permission needed is a directory permission rather than a resource one. Ask what they would check in what order. Strong candidates ask which operation, exactly, and against which resource, before offering any theory at all.
What you are really listening for
Across all five, the pattern separating people is whether they gather evidence before forming a theory. Weak candidates produce a plausible cause in fifteen seconds and then defend it. Strong ones ask two or three clarifying questions, say out loud what each answer would rule out, and are comfortable saying they would need to look at something before committing. That last behaviour is the one that predicts how they will act during your incident, at an hour when nobody is watching.
Seniority, and What Each Level Can Safely Be Trusted With
Years on a CV mean less here than usual, because an engineer can spend five years raising tickets against an estate somebody else designed. A more useful measure is scope: how far up the hierarchy you would let this person make a change unsupervised.
Junior
Works inside a resource group. Deploys what a pipeline tells them to deploy, raises access requests correctly, reads a policy failure and can explain which rule matched. Writes Bicep or Terraform that somebody reviews before it is applied. No standing production permissions, and no assignments above resource group scope. Useful on a team with more requests than hands. A poor choice as your only Azure person, because the mistakes that hurt in this estate are exactly the ones needing judgement about scope.
Mid
Owns a subscription's worth of work. Builds and maintains the infrastructure for a set of applications, publishes modules the rest of the team consumes, and clears most failures without help while recognising the ones worth handing upward. Networking and identity are usually the two areas still catching up, because those are where self assurance runs ahead of exposure for the longest. By this point the person has typically written a role assignment far broader than it needed to be, and has since worked out exactly why that was a problem.
Senior
Drop them into a tenant they have never opened and a week later you get an assessment that holds up under challenge, ordered by what the damage would be rather than by what is quickest to patch. Works confidently at management group scope. Holds the policy model, the identity design, the upgrade calendar and the connectivity diagram. Follows a fault from the application into the network rather than bouncing it back to whoever raised it. Turns down work that would make the estate more brittle, and explains the refusal in terms a product manager accepts. This is the level most teams actually need and the one they most often try to save money on.
Principal or cloud architect
Decides shape rather than implementation. Whether the subscription model should be rebuilt. Where the boundary sits between what a platform team provides and what each product team runs. What is standard, who may deviate, and how an exception gets recorded. Also the person who can hold a conversation with procurement about the agreement without needing a translator. Demand for this is far smaller than the market suggests, and where it exists, a standing slot of a few hours each week shifts more than a full time appointment further down the ladder would.
The hiring error that comes up most on Azure estates is trading one senior appointment for two mid level ones because the budget line reads better that way. It seldom pays off. Both of those people produce changes somebody has to check, and neither of them can be the checker, which means you have bought output and lost oversight. On a tenant where a role assignment placed one level too high is a reportable security event, oversight was the whole point of the more expensive hire.
Four Situations That Bring Teams to Us
Nothing below describes a named client. Each one is a composite, drawn from the shapes of brief that arrive here repeatedly. Where a description matches your own quarter, the sentence to act on is the last one in that box.
The estate that arrived with the licensing renewal
Nobody designed it. A renewal put Azure credit on the table, three teams started using it independently, and eighteen months later there are twenty two subscriptions, no management groups, no policy, tags applied by two teams out of five, and a bill finance cannot break down by product. Everything works. Nothing is governed. The instinct is to hire someone senior and ask them to tidy it up, which fails because tidying is not a task, it is a sequence of decisions about ownership that only your organisation can make. Start by getting the estate written down and the risks ranked, then hire against what was found.
Two tenants after an acquisition
The company you bought has its own Entra tenant, its own subscriptions and its own security policies, and your integration plan assumed identity would be a formality. It is not. Directories do not merge, guest access is a partial answer with real limits, and moving subscriptions across tenants breaks role assignments and managed identities that then have to be rebuilt. This needs somebody who has done a tenant migration rather than somebody who is confident it will be fine. Ask candidates directly whether they have, and let the ones who have talk for as long as they want.
A regulated workload that has to evidence where data sits
A customer or a regulator wants to know which region holds the data, who can reach it, and how that is proven. The technical work is real: region selection, private connectivity so nothing traverses a public path, customer managed keys, diagnostic settings routed to a workspace with a retention period somebody has actually decided on, and access that is time bound rather than standing. Be careful how the compliance position itself is worded, because that belongs with your counsel and your auditor rather than with any engineer. What a good hire delivers is closed gaps and evidence that the controls exist and operate.
The .NET team that inherited the infrastructure
A capable application team, usually strong on C# and Entity Framework, has ended up owning the App Service plans, the networking and the pipelines because there was nobody else. They are competent and stretched, and the infrastructure gets attention only when it breaks. Sometimes the answer is an Azure specialist beside them. Sometimes it is more application capacity so the existing engineers can go back to the product, which is what our .NET developers in India page covers. Decide which shortage is actually hurting before you write the advert.
Working With an Azure Engineer in India: Hours, Access and Handover
Here is the arithmetic without decoration, then what it means for a role where a lot of the work is answering other people.
The overlap, calculated
Indian clocks sit at UTC+5:30 and never change, because the country does not observe daylight saving. So a working day running 09:30 to 18:30 locally occupies 04:00 through 13:00 UTC in January and exactly the same nine hours in July. Every row below is that one conversion applied to a different city.
| Where you are | When the Indian day happens in your clock | Live overlap with a 09:00 to 17:00 day |
|---|---|---|
| London (GMT, winter) | 04:00 to 13:00 | 09:00 until 13:00, so four hours |
| London (BST, summer) | 05:00 to 14:00 | 09:00 until 14:00, so five hours |
| Sydney (AEST, winter) | 14:00 to 23:00 | Three hours, all of it your afternoon |
| Sydney (AEDT, summer) | 15:00 to midnight | Two hours, late afternoon |
| Auckland (NZST, winter) | 16:00 to 01:00 | One hour, right at the end of your day |
| New York and Toronto (EST) | 23:00 the night before, through to 08:00 | None. The Indian day ends an hour before yours opens |
| New York and Toronto (EDT) | Midnight through to 09:00 | None in practice. It ends as yours begins |
| San Francisco (PST or PDT) | 20:00 the night before to 05:00, or 21:00 to 06:00 | None, in either half of the year |
Go back over the North American rows. On unshifted hours, neither American coast shares a single working minute with an ordinary Indian day. Not a narrow window. Zero. Where a supplier suggests otherwise, either somebody's hours have quietly been moved without it appearing in the proposal, or a few overlapping minutes at the boundary are being counted as if they were a working relationship.
Serving North America therefore means an Indian day beginning after lunch. Buy three hours against a New York morning and your engineer is still at the keyboard well into their own night. Someone gives up their evening for that, permanently. The arrangement survives when it is on the table during hiring and priced into the role from the start. It collapses when the candidate learns about it in week six, and the way it collapses is that they leave rather than complain.
Why the overlap question is sharper for this role than for most
A backend developer with a well specified ticket can produce a good day of work with no overlap at all. An Azure engineer in an established estate cannot, because a large share of the job is answering other people: access requests, policy exceptions, why a deployment failed, whether a change is safe. Those are questions with a person waiting at the other end.
Two things make it workable. Give the role enough autonomy that most requests do not need your approval, which means agreeing the permission boundary properly rather than routing everything through one person on your side. And move as much as possible from conversation to written queue, so the work waiting in the Indian morning is unambiguous. Teams that do both get good value from the offset. Teams that keep every decision in a synchronous meeting will find the arrangement frustrating no matter who they hire.
Where the offset genuinely helps
Maintenance windows. On an Azure estate a great deal of disruptive work has to happen outside business hours: cluster upgrades, failover tests, firewall changes, certificate rotations, subscription moves. For a European or North American company those land in somebody's evening or weekend. Seen from India, a 22:00 to 02:00 window in New York is early to mid morning. The person doing the work is awake, at a desk, with a colleague nearby to argue with, instead of alone at home in the dark thirty seconds from a decision about production. That is a structural advantage and it is one of the few honest reasons to prefer this arrangement for infrastructure work specifically.
What it does not give you is cover around the clock. Covering one window well is not the same as covering all of them, and continuous cover is additional people you are choosing to pay for. It is a perfectly reasonable thing to want. Put it in the budget as headcount you decided to buy, not as something the map gave you at no charge.
Access, and who keeps the keys
The Azure specific version of this question is who holds the highest directory roles, and the answer should be you. Global Administrator, the billing relationship and the ability to change Conditional Access stay on your side. The engineer gets a named identity in your own tenant rather than a shared account, with Azure permissions granted at the narrowest scope that lets the work happen, and privileged roles activated for a period with approval where your licensing supports that.
Everything else on that list belongs in writing with us before the start date. Reachable environments and the route in. Standing permissions or activation per piece of work. Destination for the activity log and the name of whoever reads it. Device and network requirements. And the exact sequence that runs on the final day of the engagement to remove every credential. There is nothing exotic in any of it, and settling it early is time you will not spend disagreeing in the middle of an outage.
Handover, in writing or not at all
When the working days barely touch, the handover note is the interface. It needs to say what was done, what was left, what is waiting on somebody, and what would worry the writer if they were the one picking it up. Skip that and you get one fault diagnosed twice, in two timezones, by two engineers who never exchanged a word, which is a worse outcome than having no offset team at all. Agree the format and where it lives in the first week, and treat a missing handover as a defect rather than as a personality trait.
The Questions You Should Ask Before You Sign Anything
These come up in nearly every conversation and they deserve straight answers rather than reassurance.
How do I know the work is any good when I never see the person?
By making the work visible instead of trusting a status update. Every infrastructure change arrives as a pull request with a plan or a what if output attached, reviewed by someone on your side before it is applied. Portal changes to production are blocked rather than discouraged. The activity log is exported where your team can read it. If you can see what changed, who approved it and what it was expected to do, distance stops being the variable that worries you.
How do we assess English and communication properly?
Not with a friendly introductory call, which everyone passes. Give the candidate a real situation with something at stake and ask them to explain it to a non technical stakeholder. Have them write a change record for a risky deployment and read it as though you were approving it. Written clarity matters more than accent or fluency in this role, because when the overlap is thin, the written artefact is the relationship.
Who owns what gets built?
You do, and that should be stated in the contract before work begins rather than assumed from custom. Ownership of code and configuration, assignment of any intellectual property created, confidentiality, and how personal data is handled if the workload touches any. Where regulation is involved, GDPR being the usual example for European customers, that is a conversation for your own counsel rather than something an engineering vendor should be interpreting for you. What we can do is agree the terms in writing up front so nothing is left to interpretation.
What happens if it does not work out?
If the engineer we placed on your Azure estate is not right, say so and a replacement is in front of you within 48 hours, drawn from a shortlist rather than presented as your only option. Plan for it at the start, because the moment it matters is a bad moment to be negotiating. Agree notice and handover arrangements with us in the contract before anyone begins, and decide in advance what a knowledge transfer contains: the documentation standard, where runbooks live, and the rule that no environment may depend on a person for its rebuild. The protection is not a clause. It is that the estate is described in a repository rather than in somebody's head.
Which costs are we not seeing yet?
Ramp up, mostly. An Azure estate takes longer to learn than an application does, because the knowledge is spread across policy assignments, network topology, half remembered exceptions and the reasons behind them. Expect several weeks before someone is genuinely useful on an undocumented estate, and expect to spend your own team's time explaining. There is also management overhead: someone on your side has to answer questions, approve changes and own the relationship. Budget that person's hours honestly rather than assuming the arrangement manages itself.
How is security handled on your side?
Access from managed devices, named accounts rather than shared ones, no credential leaving your systems, and everything revocable by you in a single action. Where you have specific device, network or logging requirements, they are agreed before work begins and applied. We describe what we do rather than pointing at a badge, and if your procurement process requires particular certifications from a supplier, raise it early so nobody discovers a mismatch late.
Engagement Models, and When Hiring Is the Wrong Instrument
Everything above has been an argument for putting a person in the role, so it is only fair to mark out where that is the wrong call. Ask one question: does the work stop?
Designing a subscription and management group model, building a landing zone, moving an estate into version control, migrating a tenant: those finish. Hiring a permanent person for a three month piece of work leaves you with a person, a completed project and no obvious second one, and the usual result is quiet boredom followed by a resignation. Access requests, custody of the policy model, the upgrade calendar, the steady drip of questions from other teams: none of that has a completion date, and permanent work is what a permanent person is for.
Dedicated engineer, embedded
An engineer who works to your board, attends your standups, follows your change process and is reviewed by your people. The right shape when the work is continuous and the estate needs somebody who accumulates context rather than someone who arrives, delivers and leaves.
Scoped project with a defined finish
A landing zone to build, a network topology to redesign, an estate to bring under infrastructure as code, a migration to run. Defined outcome, agreed acceptance, and a handover to whoever will run it afterwards. Our cloud architecture services in India is where this kind of work sits.
Retained review time
A few hours a week of senior attention: reviewing designs before they are built, reading the policy compliance report, checking the identity model has not drifted, and being available when something unfamiliar appears. Useful for teams that have capable engineers but nobody with enterprise Azure depth.
Running the project first and recruiting afterwards tends to work better than the reverse, because by then the advert can describe a real system with real conventions instead of a hypothetical one. If the estate is really a delivery problem rather than an Azure problem, the DevOps engineers in India page sets out how that role differs, because the two get confused in job adverts constantly.
How Hiring an Azure Engineer Through Us Works
We hold engineers on the bench instead of opening a search the day your brief lands. It is the whole reason a shortlist can reach you 48 hours after we first speak, and why a start date 7 days out is a real date rather than a hopeful one. The steps below fill the gap between those two moments.
Describe the estate, not the job title
How many subscriptions, whether management groups exist, what the identity picture looks like, what runs where, and what is currently painful. Twenty minutes on this changes the shortlist more than any other input, because Azure roles vary enormously depending on how governed the estate already is.
Settle hours and access before anyone is proposed
Overlap window, whether maintenance windows are in scope, the permission boundary, and who approves what. Agreeing this first means candidates are screened against a schedule and a scope they have genuinely accepted rather than one they find out about later.
Run your own technical conversation
Take the broken systems described further up, or better still, dig out something that genuinely went wrong in your own estate and make the candidate reason through it in front of you. Depth is yours to verify. Do not accept anybody's word for it, ours included.
Start read only, then widen the scope
The first week is reading the estate: subscriptions, policy assignments, network topology, identity, and what surprised them. Only after the two of you have gone through that write up together do write permissions and privileged roles get granted. As a side effect it is also the quickest read you will get on whether the appointment was a good one.
Frequently Asked Questions
Is an Azure developer just an AWS developer with different service names?
No, and the gap is organisational before it is technical. Azure work usually happens inside an estate somebody else designed, under an agreement procurement signed, with a directory that already existed because the company runs Microsoft 365. The person you hire spends more of the week inside identity and governance than a comparable AWS hire, and far less of it picking services from a blank page. Hire someone who is comfortable working inside constraints they did not set.
What is the first thing to test in an Azure candidate's identity knowledge?
Ask them to separate an Entra directory role from an Azure RBAC role assignment. They are two permission systems that live on top of the same tenant, and confusing them is how people end up with far more access than anyone intended. A good answer covers where each one is granted, how inheritance runs from a management group down through a subscription to a single resource, and why holding Global Administrator does not by itself give you anything inside a subscription.
How much overlap do we get with an Azure engineer working from India?
India sits at UTC+5:30 with no seasonal change, so a 09:30 to 18:30 working day there is 04:00 to 13:00 UTC in every month of the year. Out of that, London retains four hours through winter and five once the clocks move. Sydney sees two or three, all late in its own afternoon. New York, Toronto and San Francisco see nothing whatsoever on unshifted hours. Serving North America means moving the Indian day deliberately, agreeing it in writing, and hiring against that schedule rather than revealing it afterwards.
Should I insist on an Azure certification?
Read it as a syllabus rather than a verdict. AZ-104 says somebody sat an administration exam, AZ-305 a design exam, AZ-400 a delivery one. None of them prove the person has watched a private endpoint resolve to a public address at midnight and worked out why. Use the certificate to guess what vocabulary they arrive with, then spend the interview making them debug a broken system out loud, because that is the part that separates candidates.
Bicep or Terraform for a new Azure estate?
If everything you run is Azure and your team already lives in Microsoft tooling, Bicep is the lower friction choice. It is first party, it tracks the Resource Manager API as new resource types appear, and there is no state file for anyone to corrupt. Terraform earns its overhead when you also manage things outside Azure, when you want one workflow across providers, or when your engineers already know it well enough that switching would cost more than it saves.
Our CI still runs on Azure DevOps. Does that make hiring harder?
Not really. A lot of Microsoft centred companies still run production through Azure DevOps and plenty of strong engineers have spent years in it. What matters more than the product name is how the pipeline proves who it is. Ask whether deployments authenticate through workload identity federation or through a secret stored in a service connection. The answer tells you more about the health of the estate than the choice of CI tool ever will.
Who should hold Global Administrator once we bring in an offshore engineer?
You should. Keep the highest directory roles and the billing relationship on your side, give the engineer a named account in your own tenant rather than a shared login, and grant Azure permissions at the smallest scope that lets the work happen. Where your licensing supports it, make privileged roles time bound and approved instead of standing. Access routes, device policy, log retention and what happens on the final day are all worth settling in writing before the first deployment.
We inherited an Azure estate nobody documented. Hire first, or assess first?
Read it first. A job description written before anyone has opened the subscriptions, the policy assignments and the network topology almost always describes the wrong role, because it is built on what you assume is there. A short assessment produces a list of what actually exists and which parts are dangerous. The description you write after that is a different document, and the person it attracts is a better fit for the work in front of them.