Topic Dependencies
The rule that produced the day ordering: no concept is used before it is introduced. This file is the proof, and the checklist for authoring each day.
1. The dependency graph
flowchart TD
CLOUD[Cloud model / Regions / AZs<br/>D1] --> ACCT[Account / Root / Billing<br/>D1]
ACCT --> IAM[IAM: principal, policy, role<br/>D1]
IAM --> APICALL[Signed API call + credential chain<br/>D1]
APICALL --> CLI[Console / CLI / SDK v2<br/>D1]
CLI --> S3B[S3 basics<br/>D3]
IAM --> NET[CIDR / Subnets / Routing<br/>D2]
NET --> SGNACL[Security Groups / NACLs<br/>D2]
SGNACL --> ENDPOINTS[VPC Endpoints / PrivateLink<br/>D2]
NET --> DNS[Route 53 basics<br/>D2]
SGNACL --> EC2[EC2 / AMI / EBS<br/>D3]
IAM --> INSTROLE[Instance profile via IMDS<br/>D3]
EC2 --> INSTROLE
EC2 --> CW[CloudWatch logs/metrics/alarms<br/>D3]
S3B --> CW
EC2 --> ASG[Auto Scaling Groups<br/>D4]
ASG --> ALB[ALB / target groups / health checks<br/>D4]
ALB --> ECS[ECS / Fargate / task roles<br/>D4]
INSTROLE --> ECS
ECS --> LAMBDA[Lambda internals / concurrency<br/>D5]
ALB --> APIGW[API Gateway<br/>D5]
LAMBDA --> APIGW
SGNACL --> RDS[RDS / Aurora / failover<br/>D6]
IAM --> SECRETS[Secrets Manager / SSM<br/>D6]
RDS --> SECRETS
RDS --> DDB[DynamoDB<br/>D7]
RDS --> CACHE[ElastiCache Redis<br/>D7]
LAMBDA --> SQS[SQS / visibility / DLQ / FIFO<br/>D8]
DDB --> IDEM[Idempotency<br/>D8]
SQS --> IDEM
RDS --> IDEM
SQS --> SNS[SNS fan-out<br/>D8]
SNS --> EB[EventBridge<br/>D9]
SQS --> EB
DDB --> STREAMS[Kinesis / DDB Streams / MSK<br/>D9]
EB --> SFN[Step Functions<br/>D9]
S3B --> S3ADV[S3 advanced / presigned / multipart<br/>D10]
S3ADV --> CF[CloudFront<br/>D10]
DNS --> CF
APIGW --> CF
IAM --> IAMDEEP[Policy evaluation / STS / boundaries<br/>D11]
IAMDEEP --> KMS[KMS / envelope encryption<br/>D11]
SECRETS --> KMS
APIGW --> COGNITO[Cognito / JWT<br/>D11]
CF --> WAF[WAF / Shield<br/>D11]
ASG --> SCALE[Scaling patterns<br/>D12]
CACHE --> SCALE
DDB --> SCALE
IDEM --> RELY[Retry / backoff / circuit breaker / DR<br/>D12]
ALB --> RELY
SCALE --> COST[Cost engineering<br/>D12]
ENDPOINTS --> COST
CF --> COST
CW --> OBS[Structured logs / EMF / X-Ray<br/>D13]
EB --> OBS
OBS --> DEBUG[10 troubleshooting scenarios<br/>D13]
RELY --> DEBUG
DEBUG --> MIG[Migration playbooks<br/>D13]
MIG --> SD[7 system designs<br/>D14]
COST --> SD
KMS --> SD
STREAMS --> SD
SFN --> SD2. Why each ordering decision was made
| Decision | Reason |
|---|---|
| IAM on Day 1, before any service | Every AWS interaction is an authorized API call. Teaching S3 before IAM means teaching "click this and it works", which produces learners who cannot debug AccessDenied. |
| Networking (Day 2) before compute (Day 3) | You cannot explain "my EC2 instance can't reach the Internet" or "the ALB can't reach my container" without subnets, route tables and security groups already in hand. Every compute day afterwards is placed inside a VPC the learner drew themselves. |
| CloudWatch on Day 3, not Day 13 | The learner must be able to see what their code did from the first deployment. Day 13 then deepens it into an investigative discipline rather than introducing it. |
| The compute decision matrix on Day 4, before Lambda is taught | It creates the question ("so when would I use Lambda?") that Day 5 answers. Comparison tables land far better when the reader has an unresolved question. |
| Relational (Day 6) before DynamoDB (Day 7) | DynamoDB is taught as a deliberate contrast with the relational model. The partition-key/sort-key model is easiest to internalize as "a composite index you cannot avoid using." |
| Secrets Manager on Day 6, not Day 11 | It appears at the first moment the learner has a credential they would otherwise be tempted to hardcode. Teaching it earlier is abstract; later is too late — they'd have already written the bad version. |
| Idempotency on Day 8, after DynamoDB and RDS | Both concrete implementations (conditional write / unique constraint) require a data store the learner already knows. |
| SQS (Day 8) before EventBridge and streams (Day 9) | The queue is the simplest durable async primitive. Topics, buses and logs are then taught as "what a queue is not." |
| S3 split across Day 3 and Day 10 | Basics are needed as the first hands-on service; presigned URLs, multipart and CloudFront require API Gateway and Lambda knowledge that only exists after Day 5. |
| Deep IAM on Day 11, not Day 1 | Policy evaluation order, permission boundaries and cross-account trust are meaningless before the learner has ~10 services whose permissions actually interact. |
| Cost as a Day 12 block, plus a per-day Cost section | Cost is a design input, so it appears on every day. Day 12 consolidates it into arithmetic the learner can do in an interview. |
| Migration on Day 13, after troubleshooting | A migration plan is largely a failure plan. It requires the debugging and reliability vocabulary to be already in place. |
| Capstone assembled from Mini Assignments | Building it only on Day 14 would exceed the time budget; accumulating it from Day 4 onward means Day 14 is assembly and review. |
3. Deferred-concept register
Concepts that get named on one day and taught on another. Each mention must carry an explicit forward reference ("you'll see why on Day N") so the reader knows it is not an unexplained term.
| Concept | Named on | Taught on |
|---|---|---|
| Multi-account / Organizations / SCPs | D1 | D11 (policy evaluation), Optional Deep Dive |
| VPC endpoints | D2 | D2 basic → D12 (cost angle) |
| Storage classes & lifecycle | D3 | D10 |
| Blue/green deploys | D4 | D10 (Route 53 weighted), D13 (migration) |
| Step Functions | D5 | D9 |
| Aurora Global Database | D6 | D12 (DR) |
| DynamoDB Streams | D7 | D9 (CDC) |
| Transactional outbox | D8 | D8 concept → D13 (sync→async migration) |
| KMS encryption of queues/buckets | D8, D10 | D11 |
| Envelope encryption | D6 (secrets) | D11 |
| Correlation IDs | D8 (async hops) | D13 |
| Shuffle sharding / cell architecture | D12 | Optional Deep Dive |
| EKS | D4 (matrix row) | Optional Deep Dive only |
4. Authoring checklist (run before publishing any day)
- Term audit — list every AWS term used in the draft; confirm each was defined on this day or an earlier one, or carries a forward reference.
- Diagram audit — every box in every diagram is a component the reader can name.
- Code audit — every SDK client, annotation and config key appears in the day's Code section or an earlier one.
- Permission audit — every hands-on step states which IAM permissions it needs and which principal holds them.
- Cost audit — every billable resource created has a cleanup step.
- Failure audit — the seven failure questions are answered for anything the day tells the reader to build.
- Depth audit — all five rungs of the depth ladder (beginner → 8–10 YOE) are present for the day's headline service.