Azure administrator to DevOps engineer: the path from tickets to pipelines

You hold AZ-104, you spend your days in the portal closing tickets, and you can feel the ceiling. The good news: you are closer to DevOps than a career changer will ever be. The bad news: the skills you are missing are exactly the ones admin work never forces you to build. Here is the delta, in the order that actually works.

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

An Azure administrator becomes a DevOps engineer by adding a delivery skill set on top of Azure knowledge they already have: real Git fluency, one scripting language written properly, infrastructure as code starting with Bicep, then CI/CD with GitHub Actions — in that order. It usually takes months of deliberate practice, and the fastest route is automating your own admin toil.

I want to be precise about who this article is for, because "DevOps career path" content is usually written for nobody in particular. This is for the person who passed AZ-104, administers Azure for a living — resource groups, RBAC assignments, VM sizing, the occasional 2am storage account panic — and has noticed that the interesting problems keep going to the people who write pipelines. You are not starting over. You are translating something you already know into a different medium.

The mindset shift comes before the skills

Admin work and DevOps work draw on the same Azure knowledge, but they point in opposite directions. Admin work is reactive and portal-first: a ticket arrives, you open the portal, you click until the problem is gone, you close the ticket. The unit of work is the incident. DevOps work is proactive and code-first: you notice a class of problem, you write something — a script, a template, a pipeline — that makes the whole class of problem stop existing, and you put that something in Git where the team can review it, improve it, and run it forever.

Same platform. Same resources. Same RBAC model you already understand better than most developers ever will. The difference is that the admin expresses Azure knowledge in clicks, and the DevOps engineer expresses it in code that a machine replays. Once you internalize that framing, the skill list below stops looking like a mountain of new topics and starts looking like what it is: a change of medium.

The admin fixes the ticket. The engineer deletes the category of ticket. Both used the same Azure knowledge — one wrote it down in Git.

There is a psychological hump here worth naming. The portal feels safe because you can see everything, and code feels risky because a bad template can flatten a resource group. That instinct is backwards. Clicks leave no record, cannot be reviewed before they run, and cannot be repeated exactly. Code can be all three. The whole discipline of DevOps is built on preferring the thing you can review and replay over the thing you can only witness.

The skill delta, in the order that works

Most "become a DevOps engineer" lists are alphabetical soup — Docker, Kubernetes, Terraform, Jenkins, Ansible — with no sequencing. Sequencing is the whole game, and for an Azure admin specifically, the right order is different from the right order for a developer. Here is mine, with reasons. If you want the general-audience version of tool ordering, I wrote it up separately in what order to learn DevOps tools; what follows is that logic tuned for someone coming from AZ-104.

1. Git fluency — beyond clone and commit

First, because everything else lives inside it. Not "learn Git" the way courses mean it — you can learn clone, add, commit, push in an afternoon. I mean the team workflow: branching for a change, opening a pull request, responding to review comments, resolving a merge conflict without panic, reading someone else's diff and saying something useful about it. In a DevOps role Git is not a topic you covered once; it is the water you swim in daily. Every script, template, and pipeline you build for the rest of this path should be committed to a repo from day one, precisely so the workflow becomes boring to you. Boring is the goal.

2. One scripting language, written properly

Second, because IaC and pipelines both assume you can script. As an Azure admin you likely have PowerShell already — that counts, and it counts for more than you think. The upgrade is in how you write it: scripts with parameters and error handling instead of pasted one-liners, checked into Git, written as if a colleague will run them unsupervised. Add Bash or Python when you can, because so much of the DevOps ecosystem assumes one of them; I compared the two honestly in Python vs Bash for DevOps, and the short version is Bash for glue, Python for anything with logic. The free class on scripting for cloud engineers is built for exactly this jump.

3. Infrastructure as code — Bicep first, then Terraform

Third, and here Azure admins hold an advantage nobody tells them about: every deployment you have ever clicked through was an ARM deployment underneath. You have been generating infrastructure as code for years without reading it. Bicep is a clean syntax over that same model, which means you can take a resource you built by hand, export it, and study what your clicks look like as code — the single best on-ramp to IaC I know. Start with the free Bicep class, get comfortable with deployments you can review and repeat, then add Terraform, which dominates job postings and brings the state-file model you will need in most shops. The trade-offs between them are real and I laid them out in Bicep vs Terraform — but as a sequencing question for an ex-admin, Bicep first is the answer.

4. CI/CD — GitHub Actions, with OIDC from day one

Fourth, because a pipeline is just Git plus scripts plus IaC with a trigger attached — which is why it comes after those three, not before. Learn GitHub Actions: workflows that run on push, build, test, and deploy to Azure. And learn authentication the modern way from the start — OIDC federated credentials, where the pipeline proves its identity to Azure with a short-lived token and no secret is stored anywhere. Your admin background pays off again here, because setting up OIDC is an Entra ID and RBAC exercise, and you already speak that language. The free classes on GitHub Actions and Actions-to-Azure with OIDC walk the whole thing end to end.

5. Containers and AKS — last, not first

Fifth, deliberately. Kubernetes is the shiniest word on every DevOps list and the worst place for an ex-admin to start, because it assumes everything above — Git workflow, scripting, declarative config, pipelines — and punishes you for missing any of it. Learn Docker basics, then AKS, after the first four are solid. A candidate who can explain an OIDC-authenticated pipeline deploying Bicep is more hireable than one who has poked at a cluster and can do nothing else. I will hedge honestly: if your target employer is deep into Kubernetes, you may need to pull this forward — but that is the exception, not the default order.

The bridge move: automate your own toil

Everything above is the syllabus. This section is the strategy, and if you take one thing from this article, take this.

Do not build your DevOps portfolio out of tutorial projects. Build it out of your own job. Pick the thing you do in the portal every week — the VM right-sizing review, the access-request cleanup, the monthly cost report, the snapshot rotation, whatever your particular toil is — and move it through the skill ladder one rung at a time:

1. Script it. Turn the clicks into PowerShell (or Bash, or Python) with parameters and error handling. Commit it to a repo. You just practiced skills one and two on a problem you understand completely.
2. IaC it. If the task creates or configures resources, express that part in Bicep. Now the change is reviewable and repeatable instead of witnessed.
3. Pipeline it. Put a GitHub Actions workflow in front of it — on a schedule, or on a PR merge — authenticated to Azure with OIDC. Now the toil runs itself and leaves an audit trail.

This works for three reasons. First, motivation: you are automating something that genuinely annoys you, which survives the weeks when a toy project would get abandoned. Second, depth: because you know the task cold, every failure teaches you about the tooling rather than about the problem domain. Third — and this is the one that matters in six months — the project is the interview story. "I did X manually every week, so I scripted it, templated it, and put it in a pipeline; here is the repo, and here is what broke along the way" is the exact shape of answer a hiring manager is listening for. It proves initiative, it proves the tools, and it is unfakeable in a way certifications are not. One honest caveat: check your employer's policy before pointing personal repos at work subscriptions — the pattern also works fine in a free-tier subscription with a recreation of your toil.

The cert question: AZ-104 to AZ-400

You will wonder whether to chase AZ-400, the DevOps Engineer Expert cert that pairs with the AZ-104 you already hold. Short answer: yes, but as an accompaniment to the hands-on ladder above, never as a substitute for it. The exam forces breadth — release strategies, artifact management, monitoring — that self-directed building can leave patchy, and the AZ-104-plus-AZ-400 pairing tells a coherent story on a résumé: platform first, delivery second. I wrote a full breakdown of that jump, what the exam actually covers, and how to prepare without wasting months in AZ-104 to AZ-400, so I will not repeat it here. If you want to gauge where you stand today, the free exam practice bank has real-style questions for both.

The honest gap: many "DevOps engineer" jobs are ops jobs with a pipeline

Here is the part the roadmap articles skip. Title inflation in this corner of the market is severe, and a meaningful share of postings titled "DevOps engineer" describe the job you are trying to leave — ticket-driven operations — with a Jenkins server bolted on. If you grind through the skill ladder above and land in one of those, you will have changed titles without changing work, and the ceiling will still be there.

You can usually tell from the posting itself. Read for who owns the code:

• Real DevOps engineering roles say things like: write and review infrastructure as code, own the CI/CD pipelines, everything through pull requests, improve deployment reliability, on-call for systems you can actually change. The verbs are build, own, review, improve.
• Ops roles wearing the title say things like: support CI/CD tools, monitor pipelines, respond to incidents, maintain the DevOps platform, execute deployments. The verbs are support, monitor, respond, execute. Nothing in the posting implies you will write code that anyone reviews.

Two screening questions for the interview, once you get there: "Who reviews infrastructure code changes, and am I one of the reviewers?" and "Walk me through how a change I write gets to production." If the answers are vague, or production changes go through a separate team and a change-advisory board while you watch dashboards, you have found an ops job with a pipeline. That can still be a fine stepping stone — a support-the-pipeline role at a company with real engineering can become a build-the-pipeline role from the inside, and I have seen it happen — but walk in knowing which one you accepted.

What the first six months actually look like

To make the sequencing concrete: a realistic shape is Git and scripting as the standing daily habit from week one, Bicep from around month two once scripting feels natural, the bridge project moving rung by rung throughout, GitHub Actions and OIDC around months three to four, Terraform layered in once Bicep is comfortable, and AZ-400 study running alongside the building in the back half. Containers and AKS come after that. Treat the timeline as a sketch, not a contract — people with heavy on-call weeks will run slower, and that is fine. The order matters more than the speed. If you want the fully expanded version of this arc, from first commit to job-ready, the Azure DevOps zero-to-hero path lays it out stage by stage.

The self-paced classes linked throughout are free, with real labs — start with Bicep or GitHub Actions and you will know within a week whether this medium suits you. And if you already know that you stall without structure and other people in the room, that is the specific problem the live cohort exists to solve — same skills, fixed schedule, instructor present when the pipeline breaks.

Questions people also ask

Can an Azure administrator become a DevOps engineer?

Yes, and the transition is shorter than starting from zero, because the hard part — actually understanding Azure resources, identity, networking, and what breaks in production — is knowledge you already have. What you are missing is the delivery layer: Git used the way teams use it, one scripting language you can genuinely write, infrastructure as code, and CI/CD. Those are learnable in months, not years, especially if you practice them on the admin work you already do instead of on toy tutorials.

How long does it take to go from Azure admin to DevOps engineer?

For someone doing hands-on Azure administration daily, six to twelve months of deliberate practice is a realistic range to become interview-ready — treat any exact figure with suspicion, because it depends heavily on how much of your current job you can automate as practice. The people who move fastest are the ones who stop treating DevOps as an after-hours course and start scripting, then templating, then pipelining their actual admin tasks at work. That compresses the timeline because every hour of practice also produces evidence you can show.

Do I need AZ-400 to become a DevOps engineer?

No. Plenty of working DevOps engineers do not hold AZ-400, and no certification substitutes for a repo full of pipelines you built. That said, AZ-104 plus AZ-400 is the natural cert pairing for this exact transition: AZ-104 proves you understand the platform, AZ-400 proves you have studied how delivery works on it. Do the cert alongside the hands-on work, not instead of it. A candidate with AZ-400 and no Git history loses to a candidate with no AZ-400 and a real project, most of the time.

Should I learn Terraform or Bicep first as an Azure administrator?

Bicep first, if you are coming from Azure administration. Every portal deployment you have ever done was an ARM deployment underneath, so Bicep is a cleaner syntax for a model you already half-know — you can export a resource you built by hand and read what it looks like as code. That familiarity gets you productive in days. Learn Terraform second, because it dominates job postings and multi-cloud shops, and its state model is a genuinely new concept worth learning after you trust the IaC workflow itself.

Do Azure administrators need to learn to code for DevOps?

You need to script, which is a lower bar than software engineering. Nobody expects an ex-admin to design application architecture, but a DevOps engineer must be able to write and read PowerShell, Bash, or Python well enough to automate tasks, glue APIs together, and debug a failing pipeline step. If you have written PowerShell for admin work, you are closer than you think — the shift is writing scripts meant to be reviewed, versioned in Git, and run by a machine on a schedule rather than pasted into a console once.