Improve Chapter 01 hosting options lesson

docs/lessons/01_where_to_start/1.11_where_to_host.md

@@ -1,57 +1,120 @@
 # 1.11 Where to Host
 
-
+Choosing where to run Linux is an operational decision, not just a
+preference. The right environment depends on what you need to learn, what
+failure modes you can tolerate, how much you can spend, and who will be
+responsible for patching, backups, access, and recovery.
 
 !!! abstract "What you will learn"
-    - Explain where **1.11 Where to Host** fits in day-to-day Linux operations.
-    - Use current Linux tooling to inspect, change, and verify the relevant system behavior.
-    - Connect the concept to a real operational scenario: a first-week junior admin onboarding into a small cloud team.
+    - Compare local installs, virtual machines, containers, cloud instances, and dedicated servers.
+    - Choose a hosting option that matches the lesson goal and risk level.
+    - Collect basic evidence about a Linux environment before changing it.
+    - Avoid common cost, security, and cleanup mistakes in learning labs.
 
 !!! example "Field story"
-    Imagine a first-week junior admin onboarding into a small cloud team. Your job is not to memorize a command; it is to build a short evidence trail, choose a low-risk change, and prove whether the system improved.
+    A junior admin wants to practice package upgrades, firewall rules, and SSH
+    access. A production server would be too risky, and a local container would
+    hide too much of the boot and networking stack. A small disposable VM or
+    short-lived cloud instance gives them realistic practice with a clear
+    rollback and cleanup plan.
 
 !!! success "Operator principle"
-    Identify the OS, distribution, support window, and package source before changing anything.
-
-## Hands-on practice
+    Pick the smallest environment that teaches the skill without putting real
+    data, real users, or uncontrolled costs at risk.
 
-Run these on a disposable VM, container, or lab machine unless the lesson explicitly says otherwise.
-
-1. Inspect the current state with a read-only command related to this topic.
-2. Save the command and output in a short lab note.
-3. Make one reversible change or simulate the change in a sandbox.
-4. Re-run the inspection and explain what changed.
-
-## Check your understanding
+## Common hosting choices
 
-- What evidence would tell you that this system is healthy?
-- What is the riskiest command in this lesson, and how would you make it safer?
-- How would you explain section 1.11 to a teammate during an incident handoff?
+Use the hosting option that matches the kind of Linux behavior you need to
+observe.
 
+| Option | Best for | Watch out for |
+| --- | --- | --- |
+| Local dual boot or spare machine | Hardware, installation, disk layout, firmware, and desktop Linux practice | Partitioning mistakes, missing backups, and hardware-specific driver problems |
+| Local virtual machine | General administration, package management, services, networking, and rollback practice | VM resource limits and networking modes that differ from production |
+| Container | Command-line practice, packaging experiments, and quick disposable tests | Containers do not behave like full hosts: no normal boot flow, kernel ownership, or full init system by default |
+| Cloud virtual machine | SSH, firewalls, DNS, public networking, cloud images, and remote administration | Billing, exposed services, weak keys, forgotten disks, and provider-specific defaults |
+| Dedicated or rented server | Bare-metal performance, storage, hosting, and long-running services | Higher cost, slower recovery, provider support boundaries, and greater security responsibility |
 
-Depending on your goals, how deep you want to dive, and your economic capabilities, there are multiple places where you can host Linux.
+## Start with a disposable lab
 
-**Local Machine**: If you have a powerful enough computer, you can create a partition and install Linux directly onto it. This gives you an authentic experience and the complete ability to control your environment. 🛠️💻
+For most early lessons, a local VM is the safest default. It is close enough to
+a real server to practice services, logs, package managers, users, and network
+configuration, but it can be snapshotted and rebuilt quickly.
 
-**Virtual Machine**: If you don't want to affect your system or you are using an OS like Windows or macOS, you could set up a Virtual Machine (VM). Tools like VirtualBox allow you to emulate a Linux environment within your current OS, providing a safe sandbox to test and learn. 🔮💼
+Before making changes, capture a short baseline:
 
 ```bash
-# Download and install VirtualBox
-sudo apt install virtualbox
+hostnamectl
+cat /etc/os-release
+uname -a
+ip addr show
+df -h
 ```
 
-**Cloud Instances**: For a hands-on approach and the chance to simulate real-world experience, cloud platforms like AWS, Google Cloud, or Azure can be used to create Linux instances. This way, you can learn and apply your knowledge in a practical cloud environment. Be aware; this option could incur costs. ☁️💲
+Record where the system runs, how it was created, and how you will recover it:
 
-```bash
-# Create an EC2 instance on AWS
-aws ec2 run-instances --image-id ami-0abcdef1234567890 --count 1 --instance-type t2.micro
+```text
+Environment: local VM in VirtualBox
+Distribution: Ubuntu 24.04 LTS
+Network mode: NAT
+Snapshot: before-package-upgrade-2026-05-14
+Rollback plan: revert to snapshot if SSH or package management breaks
+Cleanup plan: delete VM after the lab
 ```
 
-**Dedicated Server**: If you need a dedicated Linux environment accessible from anywhere, you could rent a server from a provider like DigitalOcean or Linode. This option not only gives you the full experience but also exposes you to network management and remote system administration.🌐🏢
+## Cloud labs need guardrails
 
-```bash
-# Connect to your remote server
-ssh username@your_server_ip
-```
+Cloud instances are excellent for practicing SSH, public networking, DNS, and
+remote administration. They also make it easy to spend money or expose a weak
+service to the Internet.
+
+Use these checks before creating a cloud lab:
+
+1. Set a budget alert or spending limit if the provider supports it.
+2. Use the smallest instance type that can run the lesson.
+3. Allow SSH only from your current IP address when possible.
+4. Use SSH keys, not password login.
+5. Name temporary resources with an expiration date.
+6. Delete unused instances, volumes, snapshots, IP addresses, and load balancers when the lab is done.
+
+After a cloud lab, verify cleanup from the provider console or CLI. A stopped
+VM may still have billable disks, snapshots, or static addresses.
+
+## Match the environment to the lesson
+
+Use a full VM or server when the lesson involves boot behavior, systemd,
+kernel modules, real network interfaces, storage layout, firewalls, SSH, or
+multi-user administration.
+
+Use a container when the lesson is about shell commands, package inspection,
+file layout, basic scripting, or disposable experiments that do not need a
+complete host.
+
+Use a cloud instance when the lesson needs public Internet routing, DNS
+records, provider firewalls, remote SSH, or practice with infrastructure you
+can reach from anywhere.
+
+Avoid practicing destructive storage, firewall, bootloader, or account-lockout
+changes on any host you cannot rebuild or access through an out-of-band
+console.
+
+## Hands-on practice
+
+Run these steps on a disposable VM, container, or cloud instance.
+
+1. Choose one environment for a Chapter 01 lab and write down why it is the
+   right risk level.
+2. Capture the baseline commands above.
+3. Identify the rollback path: snapshot, rebuild command, backup, rescue
+   console, or deletion and recreation.
+4. If the lab is in the cloud, identify every billable resource attached to it.
+5. Destroy or revert the lab when finished, then verify that no unwanted
+   resources remain.
+
+## Check your understanding
 
-Remember to consider factors like cost, learning objectives, and system requirements which will help you determine the best hosting solution for your Linux journey. Happy exploring!🎈🎉
+- Why is a local VM often a better first lab than a public cloud server?
+- What Linux topics are poorly represented by a container?
+- What evidence would you collect before changing a remotely hosted server?
+- What resources can keep costing money after a cloud VM is stopped?
+- How would you make a firewall or SSH lesson recoverable before starting it?