Cloud & DevOps

One small VM — the cheapest instance you can rent — taken from a fresh image to an HTTPS site on a domain you own, entirely by hand, with a runbook precise enough for a stranger to repeat.

1. Lock the door first. A non-root sudo user, your public key installed, then PasswordAuthentication no and PermitRootLogin no in sshd_config. Keep your first session open until a second one connects.
2. Close everything else. Default-deny inbound with ufw or nftables, allowing only 22, 80 and 443. Confirm from outside with nmap rather than trusting your own config.
3. Serve something real. nginx or Caddy in front of an application on a private port — not a static index page. The app runs as its own unprivileged user under systemd with Restart=always.
4. Get a real certificate. Point a domain at the box, issue with certbot, apply the intermediate profile from Mozilla's SSL configuration generator, and prove renewal works with a dry run.
5. Verify and harden. Score A or better on SSL Labs, enable unattended-upgrades, install fail2ban, and note how many SSH attempts the logs already show.
6. Write the runbook, then test it. Every command in order with its purpose and its verification step. Rebuild from a blank instance following only the runbook, and fix every step that failed.

Scope guard: no configuration management, no Docker, no hosting panel. The point is doing by hand exactly what Terraform replaces two topics from now.

Ten minutes of setup that prevents the most common beginner disaster, followed by a week of running something real and reconciling the bill against your own prediction.

1. Secure the root account. MFA on root, then stop using it. Do daily work as an IAM or Identity Center user with MFA of its own.
2. Set a budget with teeth. An AWS Budget at your real limit, alerting at 50%, 80% and 100% of both actual and forecast spend, to an address you read daily.
3. Tag from the first resource. project and owner on everything, then activate them as cost allocation tags. Untagged spend is unattributable spend.
4. Predict before you build. Write down what you expect a week of your workload to cost, derived from the pricing pages, before you launch anything.
5. Run something for seven days. A small instance, a scheduled Lambda, an S3 bucket taking traffic — anything that actually accrues charges.
6. Reconcile and clean up. Cost Explorer grouped by service and by tag. One page: predicted, actual, the largest surprise, and what you would change. Then delete what you no longer need and confirm the spend drops.

Scope guard: stay inside the free tier where you can, but do not skip the reconciliation. Reading a bill is the skill; avoiding one is not.

An application you have already built, containerised properly and deployed to a managed container service, with image size, vulnerability count and cold start measured before and after.

1. Measure the naive version. A single-stage Dockerfile from the default base image. Record image size and cold start. That is the number you have to beat.
2. Go [multi-stage](https://docs.docker.com/build/building/multi-stage/). Build dependencies in one stage, copy only artefacts into a slim or distroless runtime. Target under 200MB, and use dive to find which layer is carrying the weight.
3. Drop privileges. A non-root USER, a read-only root filesystem, no secrets in layers or build args. Verify by inspecting the built image history, not by reading your own Dockerfile.
4. Handle signals and health. A real healthcheck endpoint, and a process that exits cleanly on SIGTERM — a PID 1 that ignores signals is why deploys hang for thirty seconds.
5. Scan it. Run trivy, then fix or explicitly accept every HIGH and CRITICAL. Record the before and after counts.
6. Ship it. Push to a registry and deploy to a managed service — Cloud Run, ECS Fargate, Fly.io or App Runner. Measure cold start again and publish the before/after table.

Scope guard: one service, one Dockerfile, no Kubernetes. Orchestration hides whether the image underneath is any good.

The server you built by hand in the first topic, expressed as Terraform, then destroyed and rebuilt from nothing to prove the definition is complete.

1. Remote state on day one. An S3 backend with locking. Local state is how two people destroy each other's infrastructure.
2. Define all of it. Network, security groups, compute, DNS record and certificate — every resource in your runbook, written from the provider documentation rather than copied from blog posts.
3. Parameterise one axis. A single variable set producing dev and prod from the same code — different instance size, different domain. No copy-pasted directories.
4. Destroy, then apply from nothing. Diff the rebuilt environment against the original — instance metadata, installed packages, certificate presence — and fix every difference you find. Differences mean your definition is incomplete.
5. Make drift visible. Change something in the console by hand, run terraform plan, and read what it says. Then write down what plan cannot detect.
6. Gate it in CI. fmt, validate and tfsec on every pull request, plan output posted to the PR, and apply behind a manual approval.

Scope guard: one environment pair, no modules until the flat version rebuilds cleanly. Prove reproducibility before adding abstraction.

An SLO for the service you deployed, an alert that fires on error budget rather than CPU, and a blameless postmortem of a failure you caused on purpose.

1. Pick one SLI a user would notice. Availability as successful requests over total, or latency as the fraction served under 300ms. Write down exactly which requests count and which are excluded.
2. Set a target you can defend. 99.5% over 28 days is roughly 3.4 hours of error budget. Say why that number and not four nines, including what the extra nines would cost to reach.
3. Instrument it. Emit the metric from the service, scrape it, and build one dashboard showing the SLI, remaining budget and burn rate, following Implementing SLOs.
4. Alert on burn rate, in two windows. Fast burn — 2% of budget in an hour — pages. Slow burn — 10% over three days — opens a ticket. No CPU alerts on this dashboard.
5. Break it deliberately. Stop the database, saturate CPU, or inject 500ms of latency under load. Do it without pre-warning yourself and let the alert find you.
6. Write the postmortem. Timeline to the minute, time to detect, time to mitigate, contributing factors, and action items with owners — following the Google SRE example. No person appears as a cause.

Scope guard: one service, one SLI, one incident. Almost nobody enters this field with a written postmortem — it is the strongest single artefact you can bring.