DevOps and cloud engineer roadmap

Learn to move around folders, create and edit files, and see what is running with commands like ls, cd, cat, nano, ps and top. You can practise free on your own PC using WSL on Windows or a virtual machine. Use the terminal every day until it feels normal.

Every file has an owner and permissions for read, write and run. Learn chmod, chown and sudo, and why you should not do everything as the root user. Learn to install software with apt and to read log files in /var/log.

A bash script is a file of commands that runs top to bottom. Learn variables, if/else, loops and how to pass arguments. Start by automating something you really do, such as backing up a folder every night.

Learn IP addresses, ports, DNS (which turns names into IP addresses), HTTP and HTTPS. Learn what a firewall and a load balancer do. Tools like ping, curl, dig and ss help you find where a connection breaks.

SSH gives you a secure terminal on another computer over the internet. Use SSH keys instead of passwords, and never share your private key. Learn to copy files with scp and to set up an SSH config file.

Git saves every change to your files, so you can see who changed what and go back. Learn branches, merges and pull requests. In DevOps, even server settings and pipelines live in Git.

Nginx can serve web pages and pass traffic to an app running behind it (a reverse proxy). Learn to write a simple config, check it and reload it. Then add free HTTPS with a Let's Encrypt certificate.

A container packs an app with everything it needs to run. You describe how to build it in a Dockerfile, build an image, and run containers from that image. This ends the "it works on my machine" problem.

Docker Compose starts many containers from one file, for example a web app, a database and a cache. One command starts the whole set and another stops it. It is great for local development and small servers.

Use small base images, put steps in an order that makes good use of the cache, and use multi-stage builds to leave build tools out of the final image. Do not run the app as root inside the container. Never put passwords or keys inside an image.

CI (continuous integration) means every code push is built and tested automatically. CD (continuous delivery or deployment) means passing code is released with little or no manual work. This lets teams release small changes often and with less fear.

You write a workflow file in YAML (a simple settings format) inside .github/workflows. It runs jobs like test, build and deploy when you push code or open a pull request. Keep secrets in GitHub's secret settings, never in the file.

Use Python when a task needs JSON, APIs or more complex logic, such as cleaning old cloud resources. Learn to read files, call APIs and handle errors. Go is also popular for DevOps tools, so you may learn it later.

A registry stores Docker images, for example Docker Hub, GitHub Container Registry or a cloud provider's registry. Tag images with a version or Git commit, not only "latest". This makes it easy to roll back to the last good version.

The cloud means renting computers, storage and services from a provider like AWS, Azure or Google Cloud and paying for what you use. Learn regions, zones, and the difference between virtual machines, managed services and serverless. Pick one cloud and learn it well; the ideas carry over to the others.

Each big cloud has a free tier or free credits for new accounts, with limits that change over time, so read the current rules on the provider's site. Set a budget alert on day one. Delete everything you create once you finish practising.

IAM decides which person or program can do what in your cloud account. Give each one only the permissions it needs (least privilege). Turn on multi-factor login and never use the main root account for daily work.

Learn virtual machines (such as EC2), object storage (such as S3), virtual networks (VPC) and a managed database (such as RDS). Understand public and private subnets and security groups, which act like firewalls. Build a small app using all four.

Instead of clicking in the cloud console, you describe servers and networks in Terraform files. Terraform shows a plan of changes and then makes them. OpenTofu is a free, open-source fork that works almost the same way.

Terraform keeps a state file that remembers what it created; store it safely in remote storage with locking, never in Git. Modules are reusable blocks, like a standard network setup. Always read the plan before you apply it.

Entry certificates such as AWS Certified Cloud Practitioner, Azure Fundamentals (AZ-900) or Google Cloud Digital Leader show you know the basics. Exam fees are paid and change over time, so check the official page. Employers care more about real projects you can explain, so build first and certify later if it helps.

Kubernetes is a system that starts containers, restarts them when they crash and spreads them over many machines. Learn pods, deployments, services, config maps and secrets. Practise locally with kind or minikube before using a cloud Kubernetes service.

Helm packages Kubernetes files into charts you can install with settings. GitOps tools like Argo CD keep the cluster in sync with what is in a Git repository. Then every change is a reviewed pull request, not a manual command.

Prometheus collects numbers (metrics) like requests per second, errors and memory use. Grafana draws them as dashboards. Learn the basic signals to watch: traffic, errors, response time and how full your servers are.

Collect logs from all servers into one searchable place. Traces follow one request through many services so you can see the slow part; OpenTelemetry is the common standard. Alert only on problems that need a human, or people will start ignoring alerts.

Scan images and code for known security holes in your pipeline. Keep secrets in a secret manager, patch systems regularly and limit network access between services. Follow the rule of least privilege everywhere.

SRE sets goals like "99.9% of requests succeed" (an SLO) and an error budget for how much failure is acceptable. When something breaks, the team writes a blameless post-mortem to learn, not to punish. Google's free SRE books explain this well.

Tag every resource with its team and project so you know who spends what. Switch off unused servers, pick the right size and use autoscaling. Show costs to teams regularly so they can make better choices.

Write runbooks: short step-by-step guides for common problems. During an incident, one person leads, others fix, and someone keeps notes. Practise with game days where you break things on purpose in a safe test setup.