CAREER PATH · NO CERTIFICATE REQUIRED

Help Desk → Cloud Infrastructure

You probably do not need to “start over.” You need to turn support instincts into infrastructure instincts, then prove you can troubleshoot systems you did not build.

Short version: Linux → networking → scripting → containers → one cloud → infrastructure-as-code → orchestration. Learn by breaking things, not by collecting increasingly decorative badges.

What help desk already gave you

Support work gets undersold. If you are good at it, you already practice several skills infrastructure teams care about:

Symptom triage: separating what the user reports from what the system is actually doing.
Scope: one user, one host, one subnet, one service, or everything?
State inspection: logs, process state, config, connectivity, permissions, recent changes.
Escalation: knowing when you have enough evidence to hand a problem upward without saying “it broke.”
Blast-radius awareness: learning that “restart it” is not always free.

The gap is mostly that cloud/infra moves those same habits down the stack and increases the radius of your mistakes.

1. Get comfortable living in Linux

You do not need to memorize every flag in find. You should be able to land on an unfamiliar Linux box and answer basic questions without a GUI:

What is running?
What is listening?
What failed?
Where are the logs?
Who owns this file/process/socket?
What changed?
Is the disk, memory, CPU, or inode situation stupid?

Useful territory: systemd, filesystems, permissions, processes, package management, SSH, shell pipelines, journald, basic performance tools. Build a VM, break SSH, fill a filesystem, botch permissions, repair it.

2. Networking stops being somebody else's problem

Learn enough networking that an error like “connection refused” means something different from “timeout” and “name does not resolve.” You should understand:

IP addressing and routing
DNS
TCP vs UDP
ports and sockets
NAT
firewalls/security groups
HTTP/TLS at a practical level

You do not need CCIE brainworms. You need to be able to follow a packet's plausible path and identify where reality diverges from your model.

3. Script away the repetitive bits

Bash is enough to start. Python is worth learning shortly after. The threshold is not “software engineer.” It is: if you need to do the same boring thing to 50 hosts, can you make the computer do it without creating 50 new problems?

Learn variables, loops, conditionals, exit codes, JSON/YAML parsing, HTTP APIs, and how to make scripts fail loudly instead of silently chewing through production.

4. Learn containers before Kubernetes

Kubernetes makes more sense when a container is not magical. Run Docker or Podman locally. Understand images, registries, volumes, port mappings, environment variables, process lifecycle, and why “works in my container” is merely a more sophisticated form of “works on my machine.”

5. Pick one cloud and build boring infrastructure

AWS, Azure, GCP, or another serious cloud is fine. The first platform matters less than learning the recurring concepts:

instances/VMs
virtual networks and subnets
object/block storage
IAM
load balancers
DNS
managed databases
logs/metrics

Build something boring: a small web service, private backend, database, monitoring, backups. Then destroy and recreate it.

6. Put the configuration in Git

Once you understand what the cloud resources actually are, learn Terraform/OpenTofu or the relevant IaC tool. Do not start by copying a 2,000-line “production-ready” module. Provision one network and one VM. Read the plan. Break state in a disposable environment. Understand why drift matters.

7. Then Kubernetes

Kubernetes is useful because it combines Linux, networking, storage, scheduling, permissions, declarative config, and distributed-systems failure modes in one place. It is also an excellent machine for exposing gaps in all of the above.

Start with Pods, Deployments, Services, ConfigMaps/Secrets, storage, scheduling, probes, RBAC, and networking. Then spend more time troubleshooting them than creating them.

Try three free Kubernetes break/fix labs

What I would not optimize for

Five entry-level certs: one relevant cert can help HR filters. Five usually proves you got good at exams.
Huge homelabs: a reproducible small lab you understand is better than 40 containers you copied from somebody's compose file.
Tool collecting: knowing twelve CI systems badly is not leverage.
Tutorial completion: if every lab ends exactly as the author intended, you are practicing typing.

A sane proof-of-skill portfolio

If you want an infra/cloud job, have a few things you can discuss without hand-waving:

A small Linux service you deployed and secured.
A cloud environment you created with IaC.
A containerized application with networking and persistent data.
A Kubernetes cluster where you can explain at least a few real break/fix scenarios.
A README that explains tradeoffs, failures, and what you would change — not just installation instructions.

That is enough to have a much better interview conversation than “I watched 34 hours of cloud videos.”

The actual transition: Help desk teaches you to resolve known problems inside somebody else's system. Infrastructure work increasingly asks you to reason about unknown problems in systems where your own changes may be the cause. Practice that.

Do one thing now

If you already know basic Kubernetes objects, do Lab 01: The Service Has No Endpoints. It takes about ten minutes and requires no email address. If it feels trivial, good. Move to the next one.