You SSH into a new EC2 instance at 3 AM. The application is down. You need to find logs, check configs, kill a runaway process, and restart a service - all without a GUI, all in under five minutes. This is daily life for a cloud engineer, and it starts with knowing where everything lives on the Linux filesystem. Every Linux server you will ever touch in cloud - whether it is an Ubuntu EC2 instance, a container base image, or a GCP VM - uses the same directory structure. Learning it once means you are never lost. / ├── etc/ configs for all installed services ├── var/log/ application and system logs live here ├── home/ user home directories ├── opt/ third-party software installs ├── tmp/ temporary files (cleared on reboot) ├── proc/ virtual filesystem - live process info ├── usr/ installed programs and libraries └── root/ root user's home directory
A junior engineer on a Zerodha SRE team once restarted a failing service with `kill -9` and then manually ran the binary in a terminal. The process died the moment they logged out. The right tool is `systemctl` - it manages services that start on boot, restart on failure, and stay running independently of your SSH session. **systemd** is the init system on every modern Linux distro. It starts services in parallel at boot, tracks their state, and manages restart policies. Every cloud service you run - your app, nginx, PostgreSQL, the AWS SSM agent - runs as a systemd unit.
An EC2 instance was compromised because a junior engineer ran their application as `root` and the app's config file had `chmod 777` permissions. Anyone who got RCE into the app had full root access. Understanding permissions is not optional for cloud engineers - it is a security requirement. Linux permissions have three components for each file: **owner**, **group**, and **others** (everyone else). Each can have **read (r=4)**, **write (w=2)**, and **execute (x=1)** permissions.
Every cloud engineer connects to servers via SSH. Understanding SSH deeply - not just copy-pasting the `ssh` command - is what separates engineers who get locked out from those who never do. **SSH (Secure Shell)** uses asymmetric key cryptography. Your private key stays on your machine. The public key is stored on the server in `~/.ssh/authorized_keys`. The server challenges your client to prove it has the private key without ever sending it over the network.
Cloud instances start with a minimal OS. You install everything you need. Knowing your package manager - and avoiding common pitfalls - determines whether your instance is reproducible or a snowflake.
Ad-hoc commands work for one-time tasks. Shell scripts make operations repeatable, reviewable, and automatable. Cloud engineers write shell scripts for health checks, deployment hooks, log rotation, and EC2 user data.
You SSH into a new EC2 instance at 3 AM. The application is down. You need to find logs, check configs, kill a runaway p...
A junior engineer on a Zerodha SRE team once restarted a failing service with kill -9 and then manually ran the binary i...
An EC2 instance was compromised because a junior engineer ran their application as root and the app's config file had ch...
Every cloud engineer connects to servers via SSH. Understanding SSH deeply - not just copy-pasting the ssh command - is ...
Cloud instances start with a minimal OS. You install everything you need. Knowing your package manager - and avoiding co...
Ad-hoc commands work for one-time tasks. Shell scripts make operations repeatable, reviewable, and automatable. Cloud en...
Work through these steps on a fresh EC2 instance (Ubuntu 24.04 LTS in ap-south-1). The goal is to get a Node.js app runn...
Command Purpose systemctl status <svc> Check service state and recent logs journalctl -u <svc> -f Follow live logs for a...
Aligns directly with DevOps, Site Reliability (SRE), and Platform Engineering job descriptions.