Cloud Network Engineer

Built-in commands only. Nothing to install, no account, nothing to sign up for.

1. 1

   Watch a name turn into an address

   Every connection starts by looking up a name. Run this against a site you use daily, then against a site in another country. Notice you get different addresses — sometimes several.

   Windows

   nslookup bbc.co.uk

   macOS

   dig bbc.co.uk +short

   Linux

   dig bbc.co.uk +short

2. 2

   Trace the path out

   This lists every router your traffic passes through to reach that address. Read the hostnames down the left — you can usually see it leave your house, reach your provider, and cross into a backbone network.

   Windows

   tracert bbc.co.uk

   macOS

   traceroute bbc.co.uk

   Linux

   traceroute bbc.co.uk

3. 3

   Find where the time goes

   Look at the millisecond figures. Somewhere there is a jump — 8ms to 90ms between two hops. That jump is usually the moment your traffic goes long-distance. Now trace somewhere far away and compare where the jump happens.

4. 4

   Break it on purpose, then put it back

   Add a line to your hosts file pointing a site you use at 127.0.0.1, and try to load it. Watch how the failure looks from the browser — the error will not tell you what you just did. Then delete the line. This is the single most useful thing on this list: you have now seen a name-resolution fault from the user's side, which is what half of all "the internet is down" tickets actually are.

   Windows

   notepad C:\Windows\System32\drivers\etc\hosts   (run as Administrator)

   macOS

   sudo nano /etc/hosts

   Linux

   sudo nano /etc/hosts

5. 5

   Optional — watch the actual conversation

   If you want to go further, install Wireshark, capture for ten seconds while loading one page, and filter for "http" or "dns". You will see the individual messages between your machine and the server. This is the one step that needs an install, which is why it is last.

One free single-file download (Terraform). No account, no cloud provider, no credit card, and nothing here can cost you money — you will be creating files on your own disk, not servers. Delete the binary afterwards if you like.

1. 1

   Get the tool

   Download Terraform from terraform.io — it is a single executable. Put it somewhere on your PATH, or just work in the folder you downloaded it to. Check it runs.

   Any

   terraform -version

2. 2

   Describe something that does not exist yet

   Make a new empty folder and create a file called main.tf. You are not writing instructions here — you are describing a desired end state, and that distinction is the whole idea.

   Any

   terraform {
     required_providers {
       local = { source = "hashicorp/local" }
     }
   }
   
   resource "local_file" "hello" {
     filename = "${path.module}/out/hello.txt"
     content  = "built by terraform\n"
   }

3. 3

   Ask what it WOULD do

   Initialise, then run a plan. Read the output properly. It tells you exactly what will be created, changed or destroyed, and nothing has happened yet. This preview-before-acting habit is most of what separates infrastructure people who are safe from ones who are not.

   Any

   terraform init
   terraform plan

4. 4

   Make it real

   Apply it. Look in the out/ folder — the file exists. Now run plan again: it reports no changes, because reality already matches your description.

   Any

   terraform apply
   terraform plan

5. 5

   Break reality and watch it notice

   Delete the file it made, by hand. Run plan again. It has detected drift — reality no longer matches the description — and it tells you precisely how to get back. Apply again and it repairs itself. This is the moment the idea usually lands.

   Any

   terraform plan
   terraform apply

6. 6

   Add three more, then destroy everything

   Change the resource to create three files instead of one using count = 3. Plan, apply. Then run destroy: everything it made is gone, and only your description remains. You can rebuild it identically, forever, from four lines of text. That property is what the whole cloud industry is built on.

   Any

   terraform destroy

Paper and a pen. Deliberately no tools — the constraint is the point, because architecture is thinking, not diagramming software.

1. 1

   Draw what you actually have

   Your home network, on one sheet. Router, every device, how each connects. If you did the exposure trial you already have the inventory; if not, list them from memory and then check — the gap between what you remembered and what is really there is itself the first finding, and it is the same gap every organisation has.

2. 2

   Draw the lines nothing crosses

   Now mark what can reach what. On a normal home network the honest answer is everything reaches everything — your work laptop, your smart bulb, a guest's phone, the doorbell camera all sit in one flat space. Draw that reality, not the reality you would prefer.

3. 3

   Name the thing that actually matters

   Of everything on that page, what would genuinely hurt to lose or have taken? Usually one or two things: the machine with your work on it, the drive with the family photos. Circle them. Everything else on the diagram exists, in security terms, mainly as a route toward those.

4. 4

   Pick the worst device and follow it

   Choose the least trustworthy thing on the network — the cheapest smart device, the one that has not had a firmware update in three years. Trace, on the diagram, exactly what it can reach if someone takes it. That path is your blast radius, and drawing it is more persuasive than any risk score you could write down.

5. 5

   Redesign it, on a second sheet

   Draw the version where that cannot happen. A separate network for untrusted devices. The important machine somewhere the doorbell cannot reach. Guest access that is genuinely separate. You do not have to build it — you have to be able to justify it.

6. 6

   Now write down what your design costs

   This is the step that separates architecture from wishful thinking. What breaks? Casting to the TV probably stops working. Someone has to maintain two networks. A guest cannot print. Write the honest list, then decide which trade-offs you would actually accept and which you would not. If you cannot articulate the cost of your own design, you will lose every real architecture argument you ever have.