Week 2: Networking Basics & Git for Ops

1. IP Addressing, DNS & Ports

Every device on a network gets an IP address — a numeric identifier like 203.0.113.10 (IPv4, four 8-bit octets). Addresses starting with 10., 172.16.–172.31., or 192.168. are private: they only mean something inside your own network and get translated to a public address by NAT before reaching the internet. You'll see this exact split again in Week 8 as an AWS VPC's public and private subnets.

10.0.0.0/8       # private -- 10.0.0.0 to 10.255.255.255
172.16.0.0/12    # private -- 172.16.0.0 to 172.31.255.255
192.168.0.0/16   # private -- 192.168.0.0 to 192.168.255.255
203.0.113.10/32  # a single public address (the /32 means "just this host")

The /N suffix is CIDR notation: it says how many leading bits of the address are the fixed "network" part, leaving the rest for individual hosts. A /24 fixes the first 24 bits (the first three octets), leaving 8 bits — 256 addresses — for hosts on that network. Smaller numbers mean bigger networks; you'll size VPC subnets with exactly this math in Week 8.

Humans don't remember IP addresses, so DNS (Domain Name System) maps names to them. Resolving api.example.com walks a chain: your OS checks its local cache, then asks a configured resolver (often your ISP's or a public one like 1.1.1.1), which — if it doesn't already know the answer — asks a root server, then a .com TLD server, then the authoritative nameserver for example.com, which finally returns the real IP.

$ dig api.example.com +short
203.0.113.10

$ dig api.example.com
;; ANSWER SECTION:
api.example.com.   300   IN   A   203.0.113.10
# 300 = TTL in seconds -- how long resolvers may cache this answer

$ nslookup api.example.com

Once you have an IP, a connection still needs a port — a 16-bit number that tells the receiving machine which service to hand the traffic to. A handful of ports show up constantly in this course:

22    SSH        # remote shell access (Week 1)
53    DNS        # name resolution
80    HTTP       # unencrypted web traffic
443   HTTPS      # encrypted web traffic (TLS)
3306  MySQL
5432  PostgreSQL
6379  Redis

Communication over these ports follows the request/response model: a client opens a connection and sends a request; the server processes it and sends back a response with a status code (200 OK, 404 Not Found, 500 Internal Server Error) and, usually, a body. Every HTTP API you'll call from a CI pipeline or a Terraform provider follows this exact shape.

2. TLS/HTTPS Basics & Firewalls

Plain HTTP sends everything — headers, cookies, request bodies — in cleartext; anyone on the network path can read or modify it. TLS (Transport Layer Security) wraps that traffic in encryption, and HTTPS is just "HTTP over TLS." The handshake happens before a single byte of your actual request is sent: the client and server agree on a cipher, the server proves its identity with a certificate signed by a trusted certificate authority, and both sides derive a shared encryption key for the rest of the connection.

$ openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN=example.com
issuer=C=US, O=Let's Encrypt, CN=R3
notBefore=Jan  2 00:00:00 2026 GMT
notAfter=Apr  2 23:59:59 2026 GMT

A firewall is a set of allow/deny rules applied to incoming and outgoing traffic, usually by port and source address. On a single Linux host, ufw (Uncomplicated Firewall) is a friendly front end for the kernel's packet filter:

sudo ufw default deny incoming     # deny everything unless explicitly allowed
sudo ufw default allow outgoing
sudo ufw allow 22/tcp               # SSH
sudo ufw allow 80/tcp                # HTTP
sudo ufw allow 443/tcp               # HTTPS
sudo ufw enable
sudo ufw status verbose

Cloud providers add a second layer on top of the host firewall — AWS calls it a security group, and you'll configure one for real in Week 8. The principle is identical: deny by default, allow only the specific ports and sources a service actually needs.

3. Reading a curl -v Trace End to End

curl is the single most useful debugging tool for anything HTTP-shaped, and -v (verbose) shows every stage of the request/response model in order — DNS, connection, TLS, headers, body. Learning to read this output on sight will save you from guessing when an API call fails in a pipeline.

$ curl -v https://api.example.com/health
*   Trying 203.0.113.10:443...
* Connected to api.example.com (203.0.113.10) port 443
* TLS handshake, Client hello (1):
* TLS handshake, Server hello (2):
* TLSv1.3 connection using TLS_AES_256_GCM_SHA384
* Server certificate: CN=api.example.com
> GET /health HTTP/1.1
> Host: api.example.com
> User-Agent: curl/8.5.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< content-type: application/json
< content-length: 15
<
{"status":"ok"}
* Connection #0 to host api.example.com left intact

Lines starting with * are curl's own status messages: DNS resolution, the TCP connection, and the TLS handshake, all happening before your request is sent. Lines starting with > are the exact bytes curl sent — the request line and headers. Lines starting with < are what the server sent back — the status line and response headers — followed by the response body with no prefix at all. If a trace stops after the * lines, the problem is networking or TLS, not your application; if it stops after the > lines with no < response, the server accepted the connection but never answered — often a slow backend or a security group blocking the return path.

curl -I https://api.example.com          # headers only, no body (HEAD request)
curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" https://api.example.com
curl --resolve api.example.com:443:203.0.113.99 https://api.example.com
                                          # force a hostname to resolve to a specific IP,
                                          # useful for testing a new server before the DNS cutover

4. Git Branching Workflows for Ops

Treating infrastructure config the same way you treat application code — version-controlled, reviewed, and reversible — is a core DevOps habit. The pattern is a feature branch per change, a pull request for review, and a protected main branch that only changes through a merge:

git checkout -b add-nginx-rate-limit
# ...edit nginx.conf...
git add nginx.conf
git commit -m "Add rate limiting to /api routes to stop the scraper traffic we saw Tuesday"
git push -u origin add-nginx-rate-limit
# open a pull request in the GitHub UI, request a review, merge once approved

This matters more for infrastructure than for application code: a bad application deploy usually breaks a feature, but a bad infrastructure change can take down everything at once. A required review before merge is a second set of eyes on exactly the kind of change — a firewall rule, a DNS record, a Terraform resource — that's easy to get subtly wrong and expensive to get wrong in production.

Once changes are merged, Git history itself becomes an audit trail: every infrastructure change has an author, a timestamp, a message explaining why, and a full diff of exactly what changed.

git log --oneline --graph -- nginx.conf
# a94f2c1 Add rate limiting to /api routes to stop the scraper traffic we saw Tuesday
# 7b1e0aa Increase client_max_body_size for file uploads
# 3d40912 Initial nginx reverse proxy config

git blame nginx.conf              # who last touched each line, and in which commit
git show a94f2c1                  # the full diff and commit message for one change
git tag -a v1.4.0 -m "Nginx config as deployed to prod, 2026-08-03"

When something breaks in production and you need to know "what changed and who approved it," git log and git blame answer that in seconds — no separate change-management system required. If a merged change turns out to be wrong, git revert creates a new commit that undoes it, which is safer in a team setting than rewriting history with git reset.

5. Hands-on Exercise

6. Knowledge Check

Four quick questions. Expand each to check your answer.