Optional Pre-Course Foundation Module
Total: 3–5 hours. Optional. Skip it if you scored 15+ on the assessment.
This module exists to close specific gaps, not to be a second course. Read only the sections your assessment score pointed you to. Nothing here is AWS-specific — it is the vocabulary the 14 days assume.
| § | Topic | Time | Needed for |
|---|---|---|---|
| 1 | HTTP basics | 45 min | Days 4, 5, 8, 10, 11 |
| 2 | REST & API design | 30 min | Days 5, 11, 14 |
| 3 | SQL, transactions, indexes | 60 min | Days 6, 7, 12 |
| 4 | Networking basics | 45 min | Days 2, 10, 11 |
| 5 | Java & Spring Boot refresher | 45 min | Every day with code |
| 6 | Synchronous vs asynchronous | 45 min | Days 8, 9, 12 |
| Total | 4h 30m |
1 — HTTP basics (45 min)
Cover: request/response anatomy (method, path, headers, body); the status code families and the six codes that matter operationally (200, 400, 401/403, 404, 429, 5xx); the difference between 502 (bad upstream response) and 504 (no upstream response in time); connection reuse and keep-alive; what TLS proves and where it terminates.
The one mental model to carry forward:
sequenceDiagram
participant C as Client
participant R as DNS Resolver
participant S as Server
C->>R: resolve api.example.com
R-->>C: 203.0.113.10
C->>S: TCP connect :443
C->>S: TLS handshake (server proves identity)
C->>S: GET /health
S-->>C: 200 OKWhy it matters later: on Day 4 an ALB returns 502 when your container dies mid-response and 504 when your app is merely slow. Telling those apart is the debugging skill.
Self-check: Can you explain why a 504 from a load balancer is usually your application's fault and a 502 is usually your application's crash?
2 — REST & API design (30 min)
Cover: resources and URI design; when to use POST vs PUT vs PATCH; idempotency and the idempotency-key pattern; pagination (offset vs cursor); versioning; error response shape; content negotiation and JSON.
The one mental model:
A retry is not a new request. If your API cannot tell the difference, your clients cannot safely retry — and in a distributed system, clients will retry.
Why it matters later: Day 8's entire idempotency section, and the Day 14 system designs, assume you accept this.
Self-check: Design POST /payments so that a client which times out and retries three times results in exactly one charge. What do you store, and what do you key on?
3 — SQL, transactions, and indexes (60 min)
Cover: schema basics; primary and foreign keys; JOIN types; what a B-tree index is and what a composite index's column order means; EXPLAIN and reading a query plan; ACID; isolation levels (read committed vs repeatable read) and the anomalies each permits; optimistic vs pessimistic locking; what a transaction holds while it's open.
The one mental model:
flowchart LR
Q["WHERE customer_id = ?<br/>ORDER BY created_at DESC"] --> I["Composite index<br/>(customer_id, created_at)"]
I --> R["Seek to customer, read<br/>in order, stop at LIMIT"]Column order in a composite index determines which queries it can serve. (a, b) serves WHERE a, and WHERE a AND b; it does not serve WHERE b alone.
Why it matters later: DynamoDB on Day 7 is taught as a deliberate contrast to this model — partition key + sort key is the same "seek then scan in order" idea with the flexibility removed and the scalability guaranteed. If you don't have the relational model solid, the contrast teaches you nothing.
Self-check: Why does adding an index sometimes make a write-heavy table slower overall, even though reads got faster?
4 — Networking basics (45 min)
Cover: IP addresses and ports; public vs private (RFC 1918) address space; CIDR notation — read 10.0.0.0/16 and 10.0.1.0/24 and know how many addresses each holds and whether one contains the other; DNS record types (A, AAAA, CNAME, TXT) and TTL; TCP connection establishment; what a firewall rule is (source, destination, port, protocol, allow/deny).
CIDR is the single most important 20 minutes in this module. By the end you must be able to answer, without a calculator:
| Question | Answer |
|---|---|
How many addresses in a /24? | 256 (AWS reserves 5, leaving 251 usable) |
How many /24s fit in a /16? | 256 |
Is 10.0.5.7 inside 10.0.4.0/22? | Yes |
Do 10.0.0.0/16 and 10.1.0.0/16 overlap? | No — which is why they can be peered |
The one mental model:
flowchart LR
subgraph N["Your private network 10.0.0.0/16"]
A["10.0.1.5"]
B["10.0.2.9"]
end
A <--> B
A -.->|"needs a translator<br/>(NAT) or a public front door"| I((Internet))Private addresses are not routable on the Internet. Everything about VPCs on Day 2 follows from that one sentence.
Self-check: Why can two different companies both use 10.0.0.0/16 without conflict — and what breaks the moment they try to connect their networks?
5 — Java & Spring Boot refresher (45 min)
Only needed if Java or Spring Boot 3 is not your daily driver.
Cover: Java 17 features used throughout (records, sealed types, var, switch expressions, text blocks); CompletableFuture basics; try-with-resources; the Spring Boot 3 essentials — @RestController, @Service, constructor injection, application.yml and profiles, @ConfigurationProperties, RestClient/WebClient, Actuator health endpoints; Maven pom.xml structure, dependency management and BOMs.
Why the BOM matters: every AWS SDK v2 example in this course imports the SDK BOM and then declares artifacts without versions. If BOMs are unfamiliar, the build files will look like they're missing something.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>software.amazon.awssdk</groupId>
<artifactId>bom</artifactId>
<version>2.28.x</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>Self-check: Can you write a Spring Boot controller with constructor-injected dependencies, bind a config value from application.yml into a typed properties class, and expose a custom health indicator — without looking it up?
6 — Synchronous vs asynchronous communication (45 min)
Cover: blocking call vs message handoff; the coupling each creates; what a queue gives you (buffering, retry, load levelling, decoupling) and what it takes away (immediate result, simple error handling, ordering, easy tracing); delivery semantics — at-most-once, at-least-once, exactly-once and why the last is a distributed-systems claim to be suspicious of; idempotency; the outbox pattern at a conceptual level.
The one mental model:
flowchart TB
subgraph SYNC["Synchronous"]
A1[Service A] -->|blocks, shares B's fate| B1[Service B]
end
subgraph ASYNC["Asynchronous"]
A2[Service A] -->|write, return| Q[(Queue)]
Q -->|later, maybe twice| B2[Service B]
endAsynchrony does not remove failure. It moves failure in time — from "the caller sees an error now" to "something is wrong somewhere and you will find out from a metric."
Why it matters later: Days 8 and 9 are almost entirely about the consequences of that sentence.
Self-check: Name three things that become harder to answer once you put a queue between two services, and what AWS feature you would expect to restore each.
After this module
Retake the questions you originally missed in the assessment. If you now clear 13+, start Day 1.