What DevOps actually is + your first terminal session

What DevOps actually is

Section 1 of 5 · ~3 min

Strip away the buzzwords and DevOps is one idea: shorten the loop between writing code and running that code reliably in production.

For years, software shipped like a relay race between two teams that didn’t talk. Developers wrote features and threw them over the wall. Operations — separate team, separate manager, separate incentives — took that code and tried to keep it alive on real servers. Developers were rewarded for change; ops was rewarded for stability. So releases became rare, giant, and terrifying: weeks of frozen code pushed in one deployment, on a weekend, so there was time to mop up when it failed. Every engineer over 35 has a “release weekend” story that ate a Sunday.

Real world: Think of a restaurant where the kitchen invents dishes but never sees customers, and delivery riders deliver food they never watched being cooked. When a customer gets a cold biryani, the kitchen blames the rider and the rider blames the kitchen — and nobody fixes the food. DevOps is making one team own the dish from stove to doorstep: the cook rides along, sees the lid leak, and fixes the packaging that same evening.

DevOps collapses the wall. One team — or at least one shared workflow — owns the whole journey: write the code, build it into something runnable, deploy it, observe how it behaves, and feed what you observe back into the next change. That journey is a loop, and everything you will learn in the next 89 days is a tool for making one lap of it faster and safer:

A named example makes it concrete. GitHub — the company — deploys its main application dozens of times on a normal working day. An engineer merges a pull request; a GitHub Actions pipeline builds the code, runs the tests, and rolls the change out to production while dashboards confirm nothing degraded. The release stopped being an event and became a side effect of merging good code. That pipeline replaced exactly the release weekend described above — not through heroics, but by automating every step of the loop until pushing code was boring.

Notice what that implies about the job. A DevOps engineer is not “a sysadmin with a new title” or “a developer who knows YAML”. The job is building and operating the loop itself: the Linux systems everything runs on (days 1–20), the containers that package code identically everywhere and the pipelines that ship it (days 21–45), the cloud that hosts it (days 46–65), the Kubernetes clusters and Terraform code that run it at scale (days 66–85), and the habits — observation, incident response, honest postmortems — that keep it reliable (days 86–90).

So when an interviewer asks “what is DevOps?”, skip the poetry about culture. Say: “DevOps is shortening the loop between writing code and running it reliably in production — using automation so releases are small, frequent, and boring.” Then be ready to walk the loop in the diagram above, because today you take your first step onto it: the terminal, where every DevOps task ultimately happens.

Hands-On Lab

Section 2 of 5 · ~2 min

Budget about 20 minutes. Open your Ubuntu terminal (if you have not set up WSL2 yet, do Day 0 first — macOS and Linux users can use their built-in terminal as-is). Type every command yourself instead of pasting; finger memory is the point today.

# 1. Who is this session running as? Linux always has an answer.
whoami
# Output:
# pushkar          <- your Ubuntu username, chosen during first-boot setup

# 2. Where am I right now? pwd = "print working directory".
pwd
# Output:
# /home/pushkar    <- your home directory; every shell session starts somewhere

# 3. What is in this directory? A fresh home prints nothing — silence is a result too.
ls
# (no output — your home directory is empty for now)

# Point ls somewhere non-empty: the filesystem root you will map out tomorrow.
ls /
# Output:
# bin  boot  dev  etc  home  lib  media  mnt  opt  proc  root  run  sbin  snap  srv  sys  tmp  usr  var

# 4. What machine and kernel am I on? -a = "all details".
uname -a
# Output — note the "microsoft" tag that marks a WSL2 kernel:
# Linux DESKTOP-4F2K9 6.6.87.2-microsoft-standard-WSL2 #1 SMP ... x86_64 GNU/Linux

# 5. Which program is interpreting my commands? $SHELL is a variable the shell fills in.
echo $SHELL
# Output:
# /bin/bash        <- bash, the default shell on Ubuntu 24.04

# 6. Everything I just typed, numbered. Your session leaves a trail — get used to reading it.
history
# Output:
#     1  whoami
#     2  pwd
#     3  ls
#     4  ls /
#     5  uname -a
#     6  echo $SHELL
#     7  history

Before you close the terminal, read each output line once more and say out loud what it told you: who you are, where you are, what is here, what machine this is, what shell is listening, and what you did. Those six questions are the first thing you will ask on every unfamiliar server for the rest of your career.

Real Errors I Hit

Section 3 of 5 · ~2 min

Both of these happened in my own WSL2 Ubuntu 24.04 session while writing this lab. Read the error text slowly — learning to parse errors is the actual skill.

Real error: Five minutes in, I got curious about what root keeps in its home directory and ran ls /root.

ls: cannot open directory '/root': Permission denied

Why: /root is the home directory of the root user, and its permissions (drwx------) shut everyone else out — my normal user is not even allowed to read the file list. Linux enforces this per directory, no exceptions for the curious.

Fix: Borrow root’s privileges for a single command: sudo ls /root. WSL2 asks for your password, then prints the listing. You will learn exactly what sudo does — and why you should not prefix everything with it — on Day 5.

How you’d spot it in prod: Permission denied in a service log or a failed CI step almost always means the process runs as a user that lacks rights on a path. Check who the process runs as and who owns the path before changing anything — the fix is usually ownership, not sudo everywhere.

Real error: Typing fast, I transposed two letters and ran sl instead of ls.

sl: command not found

Why: The shell searched every directory listed in my $PATH variable for an executable named sl and found nothing. It did not guess what I meant — the shell is completely literal. (Desktop Ubuntu 24.04 may instead offer sudo apt install sl via its command-not-found helper; sl really exists — it is a joke package that drives a steam locomotive across your terminal.)

Fix: Retype the command. Better habit: press Tab to auto-complete names, so typos get caught before Enter, and use history to re-run what worked.

How you’d spot it in prod: command not found in a pipeline log usually means the tool is not installed on the CI runner or $PATH differs from your laptop. The fix belongs in the environment — an install step in the pipeline — not in retyping.

DevOps Interview Questions

Section 4 of 5 · ~1 min

The four questions below come straight from real screening rounds, and this day’s answer bank renders right after this note. Cover each answer, say your own version out loud first, then compare — recalling before revealing is what makes it stick for interview day.

Go Deeper

Section 5 of 5 · ~1 min

Optional extras if you have ~30 more minutes today:

• 10 min — Run man man in your terminal. The manual system explains itself; skim the first two screens and learn to quit (q), search (/pattern), and jump (n). You will use man on all 89 remaining days.
• 20 min — Read §1 “Introduction to Linux” of the Linux for DevOps guide for the wider story of why Linux runs effectively the entire server-side internet.