Skip to content
Get Daily Deck Careers

Cloud and DevOps

Keeping systems running and making deployment boring. Harder to enter straight from graduation, but unusually durable once you are in.

Last reviewed 6 August 2026.

What the job is actually like

Automating the things that would otherwise be done by hand, and being the person who works out what happened when something broke at an awkward hour. A lot of configuration, pipelines, monitoring and permissions. The best outcome of your work is that nobody notices it, which suits some people and frustrates others. On-call is a real part of many of these roles and should factor into the decision.

This suits you if

  • You are bothered by manual repetition and will automate it unprompted
  • You stay methodical when something is broken and people are waiting
  • You like breadth — a bit of networking, a bit of security, a bit of everything

Probably not, if

  • You want to build features users see; you will mostly build things engineers use
  • Being woken by an alert would make the job unbearable

A roadmap

Lengths are what this typically takes alongside other commitments, not a promise. The "prove it" line matters more than the timeline — that is what someone hiring will look at.

  1. Linux and networking

    The command line, processes, permissions, and what DNS, TCP, TLS and HTTP actually do. Almost every later problem turns out to be one of these wearing a costume.

    Typically
    Two to four months
    Prove it
    Diagnosing why a service is unreachable using only the terminal, and explaining the chain of causes.

  2. One cloud provider

    Compute, storage, networking and identity on a single provider. Identity and permissions are the part people skip and the part that causes incidents. Do not learn three providers shallowly.

    Typically
    Three to five months
    Prove it
    A running deployment you built yourself, with access properly scoped rather than everything left wide open.

  3. Infrastructure as code

    Terraform or equivalent. The shift is from clicking in a console to describing the desired state in a file that lives in version control.

    Typically
    One to two months
    Prove it
    Tearing your entire environment down and rebuilding it from the repository, with nothing done by hand.

  4. Containers and CI/CD

    Docker, then an automated pipeline that tests and deploys on push. Kubernetes only after this is comfortable — most people reach for it far too early.

    Typically
    Two to four months
    Prove it
    A pipeline that takes a commit to production without manual steps, and rolls back cleanly when it should.

  5. Observability

    Logs, metrics, traces and alerts that mean something. Alerting that cries wolf is worse than no alerting, and learning that distinction is the skill.

    Typically
    Ongoing
    Prove it
    A dashboard that would let a stranger tell whether your system is healthy.

What AI has changed

Writing a config file, a pipeline definition or a shell script is now fast and cheap, and that was a meaningful chunk of junior work. What has not become easier is understanding a distributed system well enough to know why it broke, or judging whether a generated configuration is safe to apply to production. Infrastructure code is unusually dangerous to accept unchecked — a plausible looking permission policy can quietly expose data, and the failure is silent until it is not. That raises the value of people who can read a change and reason about its blast radius before it runs.

Common mistakes

  • Learning Kubernetes before Linux and networking, then being unable to debug anything underneath it.
  • Collecting cloud certifications with no running system to point at. The certificate proves you can pass an exam.
  • Leaving permissions wide open in personal projects, then carrying the habit into work.
  • Building automation nobody asked for instead of removing the manual step people actually complain about.
  • Expecting to enter this straight from graduation. Many arrive after a couple of years in support or development.

This path is worth being honest about on entry: fewer employers hire directly into it from graduation, because much of the value is judgement earned by having seen things go wrong. A common and entirely respectable route in is a couple of years in support, testing or development, automating your own team’s annoyances until that becomes the job.

The compensation for the slower entry is durability. The specific tools churn, but the underlying skill — understanding how systems fail — has aged well through every wave of tooling so far.

This is one view, not the answer

Career advice is opinion shaped by a moment in time, and this page says which moment. Weigh it against people actually doing the job now — their account of the last six months is worth more than any guide.