How to go from help desk to cloud engineer

The distance between resetting passwords and running production infrastructure is real, but it is smaller than it looks — and none of it is the part people spend their nights worrying about.

If you are on a help desk, you already know the thing most career-changers spend a year learning the hard way: software fails in specific, unglamorous ways, and someone has to be calm when it does. You have sat with the ticket at 4:50 on a Friday. You know what a user actually means versus what they typed. That instinct is not a footnote on the way to cloud engineering — it is a head start most bootcamp graduates do not have and cannot fake.

What you are missing is narrower than the job title suggests. You are not missing "intelligence" or "a computer science degree." You are missing the ability to build the thing you currently support. This is a guide to closing exactly that gap, written for someone doing it around a full-time support shift, with no cloud experience on the résumé today.

The gap nobody names out loud

Help desk is a reactive role. Something exists; it breaks; you restore it. Cloud engineering is a building role. Nothing exists; you create it, in a way that a stranger can read, reproduce, and tear down without asking you. The distance between those two is not knowledge of Azure menus. It is a change in what you produce at the end of a day.

This is why "I know a lot about IT" does not, on its own, move you across. A support engineer who has memorized every setting in the Azure portal is still, from a hiring manager's seat, someone who clicks. The cloud engineer writes the file that makes the click unnecessary — and then puts that file where the whole team can use it, review it, and blame it when it is wrong. The output changes from an action to an artifact.

You are not paid to know the portal. You are paid to make the portal unnecessary.

What transfers, and what you have been told matters but doesn't

Start by keeping what you already own. Ticketing discipline, incident habits, talking to non-technical people, reading a log without panicking, the muscle memory of "change one thing, then check" — all of it transfers directly and all of it is undervalued by people who came in through a certificate mill.

Now the harder half. A few things you may be grinding on will not move the needle as much as the internet implies:

• Collecting certifications past the first one. One foundational cert proves you are serious and gets you past a résumé filter. The second and third, with nothing built between them, mostly prove you are good at exams.
• Memorizing every service. Azure has hundreds. You will use a dozen for years. Depth in networking, identity, compute, and how they are deployed beats a shallow tour of the catalog.
• Waiting to feel ready. Nobody feels ready. The people who move are the ones who published something unfinished and iterated in public.

The three skills that actually move you

If you only had time for three things — and around a full-time job, you do only have time for three things — make them these.

1. Infrastructure as code

This is the single line between "support person who knows Azure" and "cloud engineer." Instead of clicking to create a virtual network, you describe it in a file — Bicep or Terraform — and a tool builds it from the file. The file is the deliverable. It can be reviewed, versioned, copied, and destroyed cleanly. The day you can hand someone a repository that stands up real infrastructure, you are doing the job, whatever your current title says.

2. One scripting language, used for real

PowerShell, the Azure CLI, or Python — pick one and use it to automate something you currently do by hand. Not a tutorial's example; a real annoyance from your actual week. Scripting is how you stop being the bottleneck, and "I automated a recurring task and here is the code" is a sentence that changes interviews.

3. Version control and a pipeline

Git is not optional and it is not hard to start. Once your infrastructure lives in a repository, the next step is a pipeline that deploys it when you merge — GitHub Actions connected to Azure with no stored secrets. This is the moment you stop being a person who runs commands and become a person who builds the thing that runs the commands. It is also the exact skill on every mid-level Azure job posting, which is not a coincidence.

A plan that fits around a full-time support job

Assume six to eight hours a week — two weeknight sessions and a Saturday morning. That is enough. Here is a shape that has worked, not a promise:

• Months 1–2: the ground. What the cloud actually is, the Azure hierarchy, identity, and access. Enough to earn the AZ-900 and, more usefully, to stop guessing. Read Class One first — it is free and it will tell you fast whether this path is yours.
• Months 3–5: build the core. Networking, compute, storage — but every topic delivered as something deployed, not something watched. This is where the portfolio starts.
• Months 4–7: the engineer's half. Git, infrastructure as code, a pipeline. Overlap it with the above deliberately; the tools are how you build everything else.
• Months 6–9: proof and the search. One or two builds you are not embarrassed by, a résumé that points at repositories, and the interview questions rehearsed out loud.

Nine months of six hours is a little over two hundred hours. Two hundred deliberate hours, spent building rather than watching, is enough to be dangerous — genuinely, hireably dangerous — at the junior end of cloud.

The part that gets people hired: proof

Here is the uncomfortable truth the tutorial economy avoids. The interview does not usually die on a trick question. It dies on a soft one: "Walk me through something you've built." The certificate has no answer to that sentence. A repository does.

So the goal of the whole pivot is not a wall of badges. It is two or three things you can put on the table — a governed subscription defined in code, a small application deployed by a pipeline, infrastructure a stranger could stand up from your README. That is what moves you from "help desk with a cert" to "we can hand this person production." Everything above is in service of producing exactly that.

Common questions