Page 1 of 2
If you work anywhere near servers, you work with Linux. It runs the overwhelming majority of the world's web servers, cloud instances, and containers - when you spin up an AWS EC2 instance, deploy a Docker container, or SSH into a production box to see why something's on fire, you are almost certainly looking at Linux. Windows and macOS are designed around a person sitting in front of a screen; Linux servers are designed around a machine running unattended, doing one job, for years, with nobody physically present.
That difference shapes everything about how you interact with it. There's usually no desktop, no icons to click, no mouse. Everything happens through a shell - a text interface where you type commands and read text back. This feels intimidating at first if you've never used one, but it's actually a huge advantage once it clicks: everything you do in a shell can be typed once, saved, and run again identically a thousand times. That repeatability is the foundation of everything else in DevOps - automation, deployment scripts, infrastructure as code all ultimately boil down to "the same shell commands, run reliably, every time."
Unlike Windows with its C:\ and D:\ drives, Linux has a single unified filesystem starting at /, called root (not to be confused with the root user, which is a different thing with an unfortunately identical name). Everything - your files, your programs, your USB drive if you plug one in - lives somewhere under that one /.
A few directories you'll see constantly:
/etc # configuration files for almost everything on the system
/var # variable data - logs, caches, databases that grow over time
/home # personal directories for regular users, e.g. /home/alice
/usr # installed programs and the libraries they depend on
/tmp # temporary files, often wiped on reboot
A common beginner confusion: /root and / are not the same thing. / is the top of the entire filesystem. /root is just the home directory for the root user, the same way /home/alice is the home directory for a user named alice. You'll get lost fast if you mix these up when reading a path.
These commands are the muscle memory of working on Linux servers. You'll type them hundreds of times a day.
pwd # print working directory - "where am I right now?"
ls # list files in the current directory
ls -la # -l = long format (permissions, size, owner), -a = show hidden files too
cd /var/log # change directory
cd .. # go up one level
cd ~ # go to your home directory
mkdir new-folder # create a directory
rm file.txt # remove a file
rm -rf some-folder # remove a folder and everything inside it, no confirmation
cp source.txt dest.txt # copy a file
mv old-name.txt new-name.txt # move (or rename) a file
That rm -rf deserves a callout, because it's the single most feared command sequence in Linux for good reason: it deletes recursively (-r) and forcefully without asking (-f), and there is no trash can to recover from. Typing it against the wrong directory is a classic career-defining mistake. Always double-check your pwd before running it.
You'll spend a lot of time just reading files - configs, logs, scripts - without necessarily wanting to edit them.
cat file.txt # dump the whole file to the screen
less file.txt # scroll through a file page by page (q to quit)
head file.txt # show the first 10 lines
tail file.txt # show the last 10 lines
cat versus less is a real distinction, not just style: cat is fine for short files, but dumping a 50,000-line log file with cat floods your terminal. less lets you scroll and search (/searchterm) without that flood, and it's what you should reach for on anything log-sized.
For editing, nano is the friendliest starting point - it shows its shortcuts at the bottom of the screen (^X means Ctrl+X to exit). vim is far more powerful but has a real learning curve, most infamously that it has separate "insert" and "command" modes - pressing i to type text, then Esc to stop, then :wq to save and quit is the sequence that trips up nearly every beginner. It's worth learning eventually since it's preinstalled almost everywhere, but don't feel behind if nano is what you reach for first.
Every file on Linux has an owner (a user) and a group, and every process runs as some user. Permissions decide who can read, write, or execute that file, tracked separately for the owner, the group, and everyone else.
ls -l file.txt
# -rwxr-xr-- 1 alice devs 1024 Jan 5 10:00 file.txt
Read that permission string in three chunks of three: rwx (owner: read, write, execute), r-x (group: read, execute, no write), r-- (everyone else: read only).
chmod +x script.sh # add execute permission
chmod 644 file.txt # owner: read+write, group: read, others: read (numeric shorthand)
chown alice:devs file.txt # change the owner to alice, group to devs
The numeric shorthand (644, 755, etc.) is just those three permission bits per group written as a number: read=4, write=2, execute=1, summed. 755 means owner gets 7 (4+2+1, full access), group and others get 5 (4+1, read+execute but not write). It looks cryptic the first time but becomes second nature fast.
Real scenario-based DevOps questions, hands-on practice, and clear explanations for every answer.