Almost everything in DevOps runs on Linux. Jenkins agents, Docker containers, Kubernetes nodes and most cloud servers are Linux machines, and when something breaks, you end up in a terminal on one of them. People who skip Linux to get to the “real” DevOps tools usually come back to it a few months later, after a troubleshooting session that went badly.
The short answer: you do not need to become a Linux system administrator, but you do need to be comfortable at the command line. That means moving around the file system, managing files and permissions, reading logs, checking processes and services, basic networking commands, and simple Bash scripts. With daily hands-on practice, most beginners get there in three to four weeks.
Linux is the first module in our DevOps training in Pune for exactly this reason: every tool after it assumes you can find your way around a server.
Why Linux comes first
A container is a Linux process with some isolation around it. A Kubernetes node is a Linux server running a few extra services. A CI/CD pipeline is usually a series of shell commands. When a deployment fails, the clues are in log files, process lists and network checks, all of which you read with Linux commands.
Interviewers know this. A DevOps interview can easily start with something like “a service is down on a server, walk me through how you would check it”, long before anyone mentions Kubernetes.
The commands you will use every week
Moving around and working with files
pwd
ls -la
cd /var/log
cp app.conf app.conf.bak
mv old.txt archive/
rm -r build/
mkdir -p releases/v2
find / -name "*.log" -mtime -1
Get used to ls -la, which shows hidden files and permissions, and to making a backup copy before you edit any config file.
Reading files and logs
cat config.yaml
less /var/log/syslog
tail -f /var/log/nginx/error.log
grep -i "error" app.log
grep -r "DATABASE_URL" /etc/myapp/
tail -f and grep are probably the two commands you will type most when debugging. Being able to follow a log live while you reproduce a problem saves a lot of guessing.
Permissions and users
chmod 640 secrets.env
chmod +x deploy.sh
chown appuser:appuser /opt/myapp
sudo -u appuser whoami
id
“Permission denied” is one of the most common errors in pipelines and containers. Learn how to read the rwx letters in ls -l output and what the numbers in chmod 755 mean.
Processes and services
ps aux | grep java
top
kill -15 <pid>
systemctl status nginx
systemctl restart nginx
journalctl -u nginx --since "10 minutes ago"
Most Linux servers use systemd to manage services. systemctl and journalctl together answer the questions “is it running?” and “why did it stop?”.
Disk, memory and networking
df -h
du -sh /var/log/*
free -m
ss -tulpn
curl -I http://localhost:8080/health
ping -c 3 db.internal
nslookup api.example.com
A full disk takes down more applications than people expect. df -h and du -sh find it quickly. ss -tulpn shows which ports are listening, and curl tells you whether the app is actually answering.
Bash scripting: how much is enough?
You should be able to write a short script that uses variables, an if check, a for loop and exit codes. A realistic example is a script that checks whether a service is healthy and restarts it if it is not:
#!/bin/bash
if ! curl -sf http://localhost:8080/health > /dev/null; then
echo "Health check failed, restarting"
sudo systemctl restart myapp
fi
That is the level most DevOps roles need from day one. Longer automation usually moves into Python, Ansible or pipeline files, but shell scripts remain the glue between them.
A three-week practice plan
- Week 1: Install Ubuntu in a virtual machine or use WSL on Windows. Use only the terminal for an hour a day: files, directories, permissions, users and editing with
vimornano. - Week 2: Install Nginx, break it on purpose (wrong config, wrong port, stopped service) and fix it using logs,
systemctlandss. Fill the disk with a large file and find it withdu. - Week 3: Write three small Bash scripts: a log cleaner, a health check like the one above, and a backup script. Put them in a Git repository with a short README.
If Git is new to you too, our guide to Git for DevOps beginners pairs well with week three. After that, follow the rest of the DevOps roadmap for freshers.
Coming from Windows or a non-Linux job?
Plenty of people start DevOps with no Linux experience: Windows administrators, testers, support engineers and developers who have always used an IDE. The terminal feels slow for the first week and normal by the third. If you already run Linux servers, you are ahead; our plan for moving from system administrator to DevOps builds on that.
Frequently asked questions
Which Linux distribution should I learn for DevOps?
Ubuntu is the easiest place to start and is widely used on cloud servers. Learn the differences with a Red Hat family distribution (RHEL, Rocky Linux or Amazon Linux) later, mainly the package manager: apt on Ubuntu and dnf or yum on Red Hat systems.
Do I need a Linux certification for DevOps jobs?
It is not required. Hands-on ability matters more, and interviewers test it directly. A certification such as RHCSA can help if you are aiming for operations-heavy roles, but projects you can explain count for more.
Can I practise Linux on a Windows laptop?
Yes. WSL (Windows Subsystem for Linux) gives you an Ubuntu terminal inside Windows, and a free virtual machine with VirtualBox works too. A free-tier cloud server is another option once you are comfortable.
What Linux questions come up in DevOps interviews?
Expect questions like how to find what is using a port, how to check why a service stopped, what file permissions 644 and 755 mean, how to find large files filling a disk, and the difference between a soft and hard link. Our list of DevOps interview questions includes several.





