The Linux Skills You Need for Cloud and DevOps Jobs

Why Linux comes first

Cloud servers, containers and most of the tools DevOps engineers use every day run on Linux. When you launch a virtual machine on AWS or Azure, the default choice is usually a Linux image. When you build a Docker image, the base is almost always a small Linux distribution. When a Kubernetes pod misbehaves, you end up inside a Linux shell reading files and checking processes. Even Azure, which many people associate with Windows, runs a large share of its customer workloads on Linux.

If you are uncomfortable on the command line, everything else in cloud is harder. You will copy commands you do not understand, you will panic when something fails, and interviews will expose the gap within minutes. If you are confident there, cloud, containers and Kubernetes start to make sense much faster, because you can see what is really happening underneath.

The good news: you do not need to know every command or memorise man pages. You need a solid working set, practised until it feels natural, plus the habit of troubleshooting calmly. This guide covers exactly that: what to learn, the commands that matter, the mistakes beginners make, and an eight-week plan you can follow even with unreliable power and data.

What employers actually check

Junior cloud, DevOps, support and site reliability roles rarely ask you to recite obscure flags. What they test, in technical interviews and take-home tasks, tends to fall into a few patterns:

• Can you find your way around a server? Log in over SSH, find a config file, read a log, edit a file without a graphical editor.
• Can you diagnose a problem? "The website is down. What do you check first?" They want a logical order, not a lucky guess.
• Do you understand permissions and users? Why a service cannot read a file, why you should not run everything as root.
• Do you understand basic networking? Ports, DNS, whether a service is listening, the difference between "cannot connect" and "connected but got an error".
• Can you automate? A small shell script that does something useful, written clearly.

Notice that most of these are about reasoning, not memory. The commands are the tools; the skill is knowing which one to reach for and why.

Setting up somewhere to practise

You need a real terminal. Reading alone does not build the reflexes you need under interview pressure. Options, roughly from cheapest to most realistic:

For most people in Nigeria and across Africa, a sensible combination is WSL or a local virtual machine for daily practice, because it works offline when data is expensive or the network is patchy, plus an occasional cloud VM when you want to practise SSH, security groups and public access.

If you do use a cloud account, set a budget alert on day one and stop or delete VMs when you finish a session. A forgotten VM billed in dollars to a naira card is an unpleasant surprise, especially with exchange-rate swings and card limits. Free tiers have conditions and time limits, so read the current terms on the provider's site.

To install Ubuntu under WSL on a Windows 10 or 11 machine, open PowerShell as administrator and run:

wsl --install -d Ubuntu

Restart when asked, create a username and password, and you have a Linux terminal.

1. Moving around and managing files

Everything in Linux is organised as one tree starting at /. Learn the important directories early: /home (user files), /etc (configuration), /var/log (logs), /tmp (temporary files), /usr/bin (programs) and /opt (optional software).

The core commands:

• pwd, ls, cd to see where you are and move around. Learn ls -la to show hidden files and details.
• mkdir, touch, cp, mv, rm to create, copy, move and delete. mkdir -p creates nested folders; cp -r copies folders.
• cat, less, head, tail to read files, including tail -f to watch a log as it grows.
• find and grep to locate files and text.
• nano or vim to edit files. Learn at least one well enough to open, edit, save and quit without searching the internet.

A short worked example you should be able to do without notes:

mkdir -p ~/projects/site/logs
cd ~/projects/site
echo "hello" > index.html
cp index.html index.backup.html
ls -la
find ~ -name "*.html" 2>/dev/null
grep -rn "hello" ~/projects

Understand the difference between absolute paths (/etc/nginx/nginx.conf) and relative paths (../logs), and what ~, . and .. mean. Many beginner errors are simply being in the wrong directory.

Also learn redirection and pipes, because they turn small commands into powerful ones:

ls /etc | wc -l              # count entries in /etc
cat access.log | grep 404 | wc -l   # count 404 errors
df -h > disk-report.txt      # save output to a file
echo "extra line" >> disk-report.txt  # append instead of overwrite

A warning about rm: there is no recycle bin. rm -rf on the wrong path deletes it permanently. Get into the habit of running ls on a path before you delete it.

2. Users, groups and permissions

Many real production problems are permission problems: a web server that cannot read its files, an SSH key rejected because it is too open, a script that will not execute.

Learn to read the output of ls -l:

-rwxr-x--- 1 deploy www-data 1204 Oct  2 09:14 deploy.sh

• The first character is the type (- file, d directory, l link).
• Then three sets of rwx: owner, group, everyone else.
• deploy is the owner, www-data is the group.

So here the owner can read, write and execute; the group can read and execute; others have no access.

The commands to change this:

chmod 755 deploy.sh        # rwx for owner, r-x for group and others
chmod u+x backup.sh        # add execute for the owner only
chown deploy:www-data app/ # change owner and group
sudo chown -R www-data:www-data /var/www/site
chmod 600 ~/.ssh/id_ed25519   # SSH private keys must be private

Learn the number shortcuts: read is 4, write is 2, execute is 1, so 7 = rwx, 6 = rw-, 5 = r-x, 4 = r--.

Then users and groups: whoami, id, sudo adduser, sudo usermod -aG groupname user, and the files /etc/passwd and /etc/group. Understand why you run things as a normal user and use sudo only when needed, and why chmod 777 is never the right fix, even though half the answers online suggest it. In an interview, saying "I would give the service user read access to that directory rather than opening it to everyone" shows real understanding.

3. Processes and services

A server is a collection of running processes. You need to see them, understand what is using resources, and control them.

• ps aux and top (or the friendlier htop) to see what is running and what is using memory or CPU.
• kill PID to stop a stuck process, and kill -9 PID only as a last resort.
• free -h, df -h and du -sh to check memory and disk. A full disk causes a surprising number of outages.
• systemctl to start, stop, restart, enable and check services.

A practical exercise: install a web server and manage it as a service.

sudo apt update
sudo apt install -y nginx
systemctl status nginx
sudo systemctl restart nginx
sudo systemctl enable nginx     # start on boot
curl -I http://localhost

Then break it on purpose. Stop the service and run curl again. Add a deliberate typo to /etc/nginx/sites-enabled/default, run sudo nginx -t to see the configuration test fail, and read the error. Practising failure is how you become calm about it.

Also learn package management for the two big families: apt on Ubuntu and Debian, and dnf (or yum on older systems) on Red Hat-style distributions such as RHEL, Rocky Linux, AlmaLinux and Amazon Linux. Most cloud images you meet will be one of these.

4. Logs and troubleshooting

When something breaks, the answer is usually in a log. Learn where logs live and how to search them:

ls /var/log
sudo tail -n 50 /var/log/nginx/error.log
sudo tail -f /var/log/nginx/access.log
journalctl -u nginx --since "1 hour ago"
journalctl -p err -b              # errors since last boot
grep -i "error" /var/log/syslog | tail -20

On Ubuntu, general system messages are in /var/log/syslog; on Red Hat-style systems, /var/log/messages. Systems using systemd also keep logs you read with journalctl.

More important than any single command is a troubleshooting order. When told "the site is down", a strong candidate works through something like this:

1. Is the server reachable? ping, or try SSH.
2. Is the service running? systemctl status nginx.
3. Is it listening on the expected port? ss -tlnp.
4. Does it respond locally? curl -I http://localhost.
5. What do the logs say? journalctl -u nginx and the application's own logs.
6. Is the machine healthy? df -h, free -h, top.
7. Is something in between blocking it? Firewall (ufw status), cloud security group or network security group, DNS.

Being able to say "I checked the logs and found this" is one of the strongest signals in an interview. Being able to explain the order you checked things in is even stronger.

5. Networking from the command line

Cloud is networking. You do not need to be a network engineer, but you must be comfortable with:

• ip a to see addresses, ip route to see the default route.
• ping to test basic reachability (bearing in mind that many cloud setups block ping).
• curl to call a website or API and see exactly what comes back. curl -v shows the full conversation.
• ss -tlnp (or the older netstat -tlnp) to see which ports are open and which process owns them.
• dig or nslookup for DNS checks.
• ssh and scp to connect to and copy files to remote servers.

Some examples worth trying:

dig +short skill-sch.com
curl -sS -o /dev/null -w "%{http_code}\n" https://skill-sch.com
sudo ss -tlnp | grep ':80'
ssh -i ~/.ssh/mykey.pem ubuntu@203.0.113.10
scp -i ~/.ssh/mykey.pem backup.tar.gz ubuntu@203.0.113.10:/tmp/

Know the common ports by heart: 22 (SSH), 80 (HTTP), 443 (HTTPS), 53 (DNS), 3306 (MySQL), 5432 (PostgreSQL). Understand the difference between a connection refused (nothing listening, or a firewall rejecting) and a timeout (often a firewall or security group silently dropping traffic). That one distinction solves a lot of "I cannot reach my VM" problems on AWS and Azure.

Learn SSH keys properly: generating a key with ssh-keygen -t ed25519, what goes in ~/.ssh/authorized_keys, and why the private key never leaves your machine or goes into a Git repository.

6. Shell scripting

Once you repeat a task twice, script it. Learn variables, if statements, loops, exit codes and how to pass arguments to a script. Here is a small, realistic script that checks whether a list of websites is up:

#!/usr/bin/env bash
set -euo pipefail

SITES=("https://skill-sch.com" "https://example.com")

for site in "${SITES[@]}"; do
  code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$site" || echo "000")
  if [[ "$code" == "200" ]]; then
    echo "$(date '+%F %T') OK   $site"
  else
    echo "$(date '+%F %T') FAIL $site (status $code)"
  fi
done

And a simple backup script that takes an argument:

#!/usr/bin/env bash
set -euo pipefail

SRC="${1:?Usage: backup.sh <folder>}"
DEST="$HOME/backups"
mkdir -p "$DEST"
tar -czf "$DEST/$(basename "$SRC")-$(date +%F).tar.gz" "$SRC"
echo "Backup saved to $DEST"

Make it executable with chmod +x backup.sh and schedule it with cron (crontab -e), for example `0 2 * /home/you/backup.sh /home/you/projects` to run daily at 2am.

Things that separate good scripts from bad ones: quoting variables ("$var"), set -euo pipefail so errors are not silently ignored, clear messages, and a usage line when arguments are missing. A short, tidy script on GitHub with a README explaining what it does is a great first portfolio piece. See our guide to cloud portfolio projects for how to present it.

Beyond the basics: what to add next

Once the six areas above feel natural, add these. They come up quickly in real cloud work:

• Environment variables (export, env, .bashrc) and how tools such as the AWS and Azure CLIs read credentials and settings.
• Archives and transfers: tar, gzip, rsync.
• Text processing: awk, sed, sort, uniq, cut. For example, finding the top IP addresses in an access log: awk '{print $1}' access.log | sort | uniq -c | sort -rn | head.
• Firewalls: ufw on Ubuntu, firewalld on Red Hat-style systems, and how they relate to cloud security groups.
• Git from the command line: clone, commit, branch, push.
• Containers: Docker is Linux processes, namespaces and filesystems underneath. Your Linux skills make Docker practice and later Kubernetes far easier to understand.

Common mistakes beginners make

• Only watching videos. You will feel you understand, then freeze at a real prompt. Type every command yourself.
• Running everything as root or prefixing every command with sudo. It hides permission problems instead of teaching you to solve them.
• Using chmod 777 to fix access. It works and it is wrong. Fix ownership or group membership instead.
• Copying commands without reading them, especially curl ... | bash installers and anything with rm -rf.
• Ignoring error messages. The message nearly always tells you what is wrong. Read it slowly before searching.
• Never breaking things on purpose. Troubleshooting is a skill you only build by fixing failures.
• Leaving cloud VMs running with SSH open to the world and no budget alert. Stop them, restrict port 22 to your IP where possible, and use keys rather than passwords.
• Committing secrets or private keys to GitHub. Use a .gitignore and check before you push.

An eight-week practice plan

The original four-week plan works if you can study for several hours a day. Most people learning alongside a job, school or family do better with eight weeks at around an hour a day, plus a longer session at the weekend. Adjust to your situation; consistency matters more than speed.

A good week 8 project: launch a small Linux VM (or local VM), install nginx, serve a simple page, write a health-check script that runs from cron and logs results, write a backup script, and document every step in a README with screenshots of the commands. Then destroy the VM. That single project demonstrates most of what an interviewer wants to see.

Daily habit that works: spend ten minutes at the start of each session repeating yesterday's commands from memory before learning anything new. On days with no power or data, practise offline on your laptop's WSL or VM, or write commands and their meanings by hand and test them later.

A self-check before interviews

You are ready for most junior cloud interviews when you can do all of this without searching:

• [ ] Explain the Linux directory structure and where configs and logs live
• [ ] Read and change permissions and ownership, and explain the numbers
• [ ] Install, start, stop, enable and check a service
• [ ] Find why a service failed using systemctl status and journalctl
• [ ] Check disk, memory and CPU usage and find what is consuming them
• [ ] Show which ports are listening and which process owns them
• [ ] Generate an SSH key and connect to a remote server with it
• [ ] Explain "connection refused" versus "timeout"
• [ ] Write a script that takes an argument, loops, checks a condition and exits with a sensible code
• [ ] Schedule a job with cron
• [ ] Walk through your troubleshooting order for "the website is down"

Where Linux fits with certifications

There is no need to collect Linux certificates before starting cloud. Many employers care more about what you can demonstrate. That said, Linux skills underpin cloud certifications that do carry weight:

• AZ-900 and AWS Certified Cloud Practitioner (CLF-C02) are fundamentals exams that need little Linux, but the hands-on practice you do alongside them will.
• AZ-104 and AWS Certified Solutions Architect Associate (SAA-C03) assume you can work with VMs, networking and access, which is much easier with Linux confidence.
• CKA and CKAD are hands-on, terminal-based Kubernetes exams. Comfort in a Linux shell, including a text editor, is essential to finish in time.

If you want dedicated Linux credentials later, the Linux Foundation and Red Hat both offer them. Check the official sites for current exam names and prices, which are charged in dollars and change from time to time. For help choosing a cloud path, see AWS vs Azure: which to learn first.

How SKILL.SCH helps

Our Linux lessons run in the browser with CloudVision, which shows each command you type as a live diagram, so you can see what cd, mv or chmod actually did to the file tree. The Linux Arena in Cloud Arcade then turns the same skills into timed missions, which is good preparation for the pressure of a live technical interview or a hands-on exam. When you are ready to move on, our courses take you from Linux into cloud, containers and DevOps.

Frequently asked questions

Which Linux distribution should I learn?

Start with Ubuntu. It is widely used on cloud VMs, has good documentation and most tutorials assume it. Later, spend some time on a Red Hat-style system such as Rocky Linux, AlmaLinux or Amazon Linux so dnf and slightly different file locations do not surprise you. The core skills transfer almost entirely.

Do I need to stop using Windows?

No. Plenty of cloud engineers use Windows or macOS as their desktop and connect to Linux servers. WSL gives you a proper Linux terminal on Windows, which is enough for nearly everything in this guide.

How long until I am good enough for a job?

With steady practice, most people can reach the self-check list above in two to three months. Linux alone rarely gets you hired; it is the foundation you combine with one cloud platform, Git, and some automation. Our guide to cloud jobs for beginners in Africa covers the rest of the path.

Do I need to learn vim?

You need one terminal editor you can use comfortably. nano is easier to start with. Learning basic vim (insert mode, save, quit, search) is still worth it, because it is installed on nearly every server and appears in hands-on exams.

Can I practise without paying for cloud?

Yes. A local VM or WSL covers almost all Linux practice for free and works offline. Use a cloud free tier only when you specifically want to practise SSH to a public server, security groups and similar cloud features, and set a budget alert before you launch anything.

Next step

Linux is the skill that makes everything else in cloud click. Start today with a terminal and the week 1 commands, and keep going daily. If you want help choosing a learning path, or want to know which SKILL.SCH course fits where you are now, book a free consultation and we will help you plan your next three months.