How to become a cloud engineer

Ten questions people ask on the way in — no degree, no experience, how much code, how much Linux, how long, how hard, what the day looks like — answered in one place by someone who came in from a cockpit rather than a computer science course.

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

To become a cloud engineer: learn one cloud platform deeply rather than three shallowly, pair a role-based certification with three or four real projects you can explain, and aim your first application one rung below the title you want. From a standing start, expect four to nine months to job-ready and one to four more to hired. No degree is required, some scripting is, and the part almost everyone skips is the portfolio — which is the part that actually gets you interviewed.

I did not arrive here from a computer science degree. I flew helicopters, then spent years in enterprise IT, then moved onto Azure and eventually into security and DevSecOps. The route was slower than a bootcamp advert promises and faster than the people telling me it was impossible believed. That is the honest middle this note sits in.

This used to be ten separate pages on this site — no experience, no degree, which skills, how long, do I need to code, do I need Linux, what does the day look like, is it hard, the roadmap, the career change. They are one question asked ten ways by someone standing at the same starting line, so they are one page now.

What a cloud engineer actually does

Strip the job titles away and the work is this: you build and run the infrastructure other people's software depends on. You decide what should exist, put it there in code so it can be rebuilt, control who can reach it, watch it, pay for it, and fix it when it breaks.

A normal day is less dramatic than the videos suggest. Standup for fifteen minutes. A ticket becomes a pull request — a change to a template, reviewed by a colleague, merged, deployed by a pipeline. A cost alert fires mid-morning and you make a small decision about a tier nobody will ever thank you for. An afternoon deploy half-breaks and you spend an hour in logs working out whether to roll back or push forward. Some of it is genuinely boring: waiting for a replication to finish, updating a runbook, chasing a vendor.

What the day-in-the-life videos leave out is that most of the time you are reading rather than typing — documentation, logs, someone else's template from two years ago — and that the valuable output is usually a decision rather than a keystroke. If that sounds dull, the job may not suit you. If it sounds like puzzle-solving with real consequences, it will.

Do you need a degree?

No. Cloud is one of the more credential-agnostic corners of tech, because the work produces artifacts a stranger can inspect. But "no degree required" is not the same as "nothing required" — the degree was signalling three things, and you have to signal them another way.

Where no-degree candidates actually get filtered is more specific than "employers are snobs", and both filters have workarounds. The first is the keyword screen: applicant-tracking software matches your résumé against the posting, and a degree field left blank matters far less than missing the exact service names the posting lists. Mirror the posting's vocabulary — the real service names, not paraphrases. The second is the referral gap: degree-holders arrive with a cohort who refer each other, and you do not have one. You build a substitute by being visible where the work is discussed rather than by applying harder into a void.

Do you need to code?

You need to write code. You do not need to be a software engineer, and conflating those two is what scares off people who would be good at this. Automating a task is not the same as building a program: you are writing glue that calls an API, loops over some resources, and fails cleanly, not shipping a product with a user interface and a release cycle.

Notice where "write fluently" appears and where it does not. The screen is not asking whether you can invert a binary tree. It is asking whether you can automate a repetitive change without breaking production, and whether you can read what a tool hands you well enough to catch it being wrong.

Do you need Linux?

Yes, more than most Windows-background people expect, and less than the Linux purists imply. Linux finds you even on a Microsoft-first platform: containers are Linux, most build agents are Linux, a great deal of tooling assumes a POSIX shell, and a large share of the virtual machines you will operate run it.

The exact Linux you need on the job is narrow and learnable. Move around a filesystem and read logs without flinching. Manage permissions and users. Understand systemd well enough to know why a service did not start. Use ssh properly, including keys. Write and read a shell script. Package management, basic networking commands, and enough text processing to slice a log file. That is the working set, and it is weeks of deliberate practice, not years.

What a hiring manager is really screening for is whether you panic in a terminal. If you came from Windows, the honest advice is to stop treating Linux as a separate subject to study later and start using it for ordinary tasks now, so the unfamiliarity wears off before it costs you an interview.

The skills that matter, in the order that pays

Not every skill weighs the same, and the order matters because you want to be employable at each step rather than only at the end.

1. Networking and identity. You can draw a private network from memory — subnets, a firewall rule, why one resource can or cannot reach another — and you understand who is allowed to do what and how that is granted. This is the half most beginners skip and most interviews open with.
2. One cloud platform, deep. One provider's core services — compute, storage, networking, identity — known well enough to pick the right one and defend the choice. Depth in one beats a shallow tour of three, and the shape transfers when you need the second.
3. Linux and scripting. You live in a terminal without flinching and can write a script that calls an API, loops over resources, and fails cleanly.
4. Infrastructure as code. The skill that separates someone who administers a cloud from someone who engineers it, and the one on nearly every mid-level posting.
5. CI/CD. A pipeline that builds, tests and deploys, authenticated without a stored secret.
6. Observability. Logs and metrics in one place, a query that answers a real question, an alert that means something.
7. Cost. Reading a bill, attributing spend, and knowing which decisions are expensive. The skill most juniors ignore and most managers notice.

The skill nobody puts in the posting sits underneath all seven: being able to explain a decision out loud. Certification tests recall. Hiring tests wiring — whether you can connect these things into something that works and say why you connected them that way.

Is it a hard job?

Yes, in four specific ways, and it is worth naming them rather than pretending the difficulty is generic.

On-call. The 3am page is the part that is genuinely hard, and no amount of enthusiasm makes it pleasant. It is survivable when the rota is sane and the runbooks exist, and corrosive when they are not. Ask about on-call in interviews; the answer tells you a lot about a team.

Blast radius. Your typo has a user count. A mistake in a template can take down something a thousand people depend on, and learning to work carefully without becoming paralysed is a real skill that takes time.

Ambiguity. Production has no answer key. Most of the hard problems are ones nobody has written up, and the work is narrowing possibilities under time pressure rather than recalling a fact.

The treadmill. The platform changes under your feet. What you learned three years ago is partly wrong now, and staying current is permanent rather than a phase you finish.

What looks hard from the outside but mostly is not: the sheer number of services, which you learn a handful at a time as you need them; the maths, which is arithmetic and rounding rather than anything exotic; and the memorization, because the documentation is open in front of you at work and in most interviews the reasoning matters more than the flag.

How long does it take?

When people ask this they are actually asking three different questions and mashing the answers together. Separating them is the most useful thing you can do before you start.

• Time to pass. How long to study for and clear an exam. A fundamentals certificate is a few weeks; a role-based one is a couple of months for most people. This clock is short and it is the only one the certificate-sellers talk about.
• Time to job-ready. How long until you can do entry-level work: stand up resources, break them, fix them, script a little, read a bill, explain what you built. This is the four-to-nine-month clock, and passing an exam is maybe a third of it.
• Time to hired. How long from job-ready to an offer. You only partly control this one — local market, application volume, whether you network, and luck. One to four months is normal, and longer is not a sign you did something wrong.

A certification says you can pass an exam. A portfolio says you can do the job. You need both, and the second is the part almost everyone skips.

Move faster if you already work in IT or write scripts. Move slower if you are fitting this around a full-time job and a family — and if you are, that is the normal case, not the exception.

The path, in order

If you want the whole thing as a sequence rather than a set of topics, it is short enough to hold in your head.

1. Bridge first, if you need it. The month most people skip: Git, a terminal, how networking actually works, what a server is. Starting a cloud course without these is why people stall in week three.
2. Fundamentals, once. Learn the vocabulary and the shape of the platform, and take the fundamentals exam to force the foundation in. It is a checkpoint, not the goal.
3. Go role-based. The administrator certification assumes hands-on work with networks, storage, compute, identity and governance, and it maps to a job title employers really post.
4. Build three or four real things and document them. In code, in a public repository, with the decisions written down. This is the step that converts study into evidence.
5. Aim one rung below the title you want. Cloud support, cloud operations analyst, junior administrator, service desk with a cloud focus. These hire year-round and they put you inside a real environment.
6. Apply as a routine. Tailor the résumé to each posting's vocabulary, talk to humans rather than only to forms, and keep building while you apply.

Doing it with bills to pay

Most people reading this have a job and a rent payment, and the plan has to survive that. Do not quit. The single highest-risk version of this move is the one where you leave your income and study on savings, and almost nobody has to do it that way.

Fifteen hours a week around a full-time job is a realistic pace and gets you to job-ready in roughly six months. Ten hours a week works too and stretches it toward nine. What matters far more than the weekly number is that it is consistent: three evenings and a Saturday morning, every week, beats an eight-hour Sunday once a fortnight. The honest cost before you start is an exam fee, a cheap subscription for practice, and several hundred hours of evenings you would otherwise spend elsewhere. Anyone telling you those costs are zero is selling something.

Who this is not for

A plan that never admits an exception is worthless. Skip this, or wait, if you would have to quit your job with no financial cushion to make it work. Skip it if the actual work — troubleshooting, reading documentation, staring at logs until something clicks — sounds like a chore you would tolerate for the salary rather than something you would find interesting on a Tuesday. And skip it if what you want is a fast, guaranteed exit from a job you hate, because this is a months-long build rather than a rescue. Running toward the work survives the slog; running only away from something usually stalls the first time it gets boring.

Questions people also ask

How do I become a cloud engineer with no experience?

Learn one platform deeply, earn a role-based certification, and build three or four real projects in a public repository with the decisions written down. Then apply one rung below the title you want — cloud support, cloud operations, junior administrator — because those roles hire year-round and put you inside a real environment. The projects are what convert "no experience" into something a stranger can inspect.

Can you become a cloud engineer without a degree?

Yes. Cloud hiring screens for demonstrated ability, and a degree is one signal among several. Replace it with a current certification for fundamentals, a public portfolio for proof of ability, and a visible track record over time for staying power. The two places no-degree candidates actually get filtered are the keyword screen, which you beat by mirroring the posting's exact vocabulary, and the referral gap, which you close by being visible where the work is discussed.

How long does it take to become a cloud engineer?

Separate three clocks. Passing a fundamentals exam takes weeks and a role-based exam a couple of months. Becoming genuinely job-ready takes four to nine months of consistent work. Getting hired after that takes another one to four months, depending on your market and how you apply. From a standing start at eight to twelve hours a week, most career-changers are job-ready around month six to eight.

Do you need to know how to code to be a cloud engineer?

You need to write code, but not to be a software engineer. Fluency in a shell language and in infrastructure as code is the working requirement, plus enough Python to read and modify a script and enough YAML and JSON to edit configuration confidently. You are writing automation glue rather than shipping a product, and no interview is going to ask you to invert a binary tree.

Do you need Linux to be a cloud engineer?

Yes, and less than you fear. Containers, build agents and much of the tooling assume Linux even on a Microsoft-first platform. The working set is narrow: move around a filesystem, read logs, manage permissions, understand why a service did not start, use ssh with keys, and write a shell script. Weeks of deliberate practice rather than years, and what a hiring manager is really checking is that you do not panic in a terminal.

Is cloud engineering a hard job?

It is hard in four specific ways: on-call, blast radius, ambiguity, and a platform that changes under you. It is easier than it looks on the things people fear most — the number of services, the maths, and memorization — because you learn services as you need them and the documentation is open in front of you. The difficulty is real but it is not evenly distributed, and most of it is survivable on a team with sane practices.

What skills do you need to become a cloud engineer?

In the order that pays: networking and identity, one cloud platform in depth, Linux and scripting, infrastructure as code, CI/CD, observability, and cost. Underneath all of them sits the skill nobody lists in the posting, which is being able to explain a decision out loud. Certification tests recall; hiring tests whether you can wire these together and say why.

What does a cloud engineer do day to day?

Build and run the infrastructure other people's software depends on. A normal day is a short standup, a ticket that becomes a reviewed pull request, a cost alert that needs a small decision, a deploy that half-breaks, and an hour in the logs working out whether to roll back or push forward. Most of the time you are reading rather than typing, and the valuable output is usually a decision rather than a keystroke.

What first job should I aim for?

One rung below the title you want. Cloud support associate, cloud operations analyst, a cloud-heavy service desk, NOC technician, or security operations tier one. None has "engineer" in the name and every one sits within arm's reach of production systems, which is the experience the engineer posting is asking for. Twelve to eighteen months in that seat usually turns an outside applicant into an internal candidate.

Is it too late to switch to cloud?

No. Cloud hires on evidence, and a portfolio does not carry your age. What closed was the easy 2021 window when a certificate alone cleared a screen, not the opportunity, since most of the economy is still mid-migration. The honest caveat is that the bar is higher than it was, so arrive with proof rather than a printout.