Back to Blog
Linux
Command Line
Beginners

Linux for Beginners: The Command Line Skills Every DevOps Engineer Needs

OpsQuiz TeamAugust 15, 20262 min read51 views

Almost every server you'll ever touch in a DevOps role runs Linux, whether it's a bare-metal box, a cloud VM, or the node underneath a Kubernetes pod. You don't need to memorize every command that exists. You need a working mental model of how Linux is organized, plus the handful of commands you'll reach for daily.

The filesystem is one tree, not drive letters

Unlike Windows with its C:\ and D:, Linux has a single filesystem tree starting at / (root). Everything, disks, network shares, USB drives, gets mounted somewhere inside that one tree. A few directories you'll see constantly:

  • /etc - system-wide configuration files (nginx.conf, sshd_config, and similar live here)
  • /var - variable data that changes over time: logs (/var/log), caches, spool files
  • /home - each user's personal files and settings
  • /tmp - temporary files, often cleared on reboot
  • /proc - not real files at all, but a live window into the running kernel and processes

Finding your way around

pwd                 # print your current directory
ls -la               # list files, including hidden ones, with details
cd /var/log          # change directory
cat /etc/os-release  # print a file's contents
less large-file.log  # view a large file one screen at a time

Permissions: the part that trips everyone up early

Run ls -l on any file and you'll see something like -rwxr-xr--. Read it in three groups of three: owner, group, everyone else. Each group can have read, write, and execute permission.

chmod 755 script.sh      # owner: rwx, group: r-x, everyone: r-x
chmod +x script.sh       # just add execute permission for everyone
chown alice:devops file  # change the file's owner and group

A private SSH key is a good example of why this matters: chmod 600 ~/.ssh/id_rsa means only the owner can read or write it. SSH itself will refuse to use the key if permissions are looser than that.

Processes: what's actually running

A process is a running instance of a program. Linux gives every process a PID (process ID) and tracks its state.

ps aux              # snapshot of every process running right now
top                 # live, updating view of CPU/memory usage per process
kill 4821           # ask a process to shut down gracefully (SIGTERM)
kill -9 4821        # force-kill it immediately (SIGKILL), no cleanup chance

The difference between kill and kill -9 matters in production: a graceful SIGTERM gives an app a chance to close database connections and finish in-flight work. SIGKILL doesn't ask, it just ends the process on the spot.

Piping and redirection

Linux's real power comes from chaining small, focused commands together instead of relying on one command to do everything.

cat access.log | grep "500" | wc -l   # count how many lines contain "500"
ps aux | grep nginx                    # filter process list down to nginx
echo "hello" > output.txt              # write, overwriting the file
echo "world" >> output.txt             # append instead of overwriting

The pipe (|) takes one command's output and feeds it as input to the next. This one habit, composing small commands, is behind a huge amount of everyday Linux troubleshooting.

Installing software

Most distributions have a package manager that handles downloading, installing, and updating software along with its dependencies:

apt update && apt install nginx     # Debian/Ubuntu
dnf install nginx                  # Fedora/RHEL/CentOS Stream

Where to go next

These fundamentals show up constantly once you start working with Docker, since containers are ultimately just isolated Linux processes, and later with Kubernetes nodes, which are themselves Linux machines under the hood. Try the Linux quiz on OpsQuiz to test what you've just learned, then move on to our Docker for beginners guide.

    Welcome to OpsQuiz!

    Real scenario-based DevOps questions, hands-on practice, and clear explanations for every answer.