EO Engineering Learning OS
CORE FOUNDATION · F02
Back to map ↑
NON-NEGOTIABLE FOUNDATION · TARGET L3 · 7–10 days
F02

Networking

Trace traffic across names, addresses, routes, filters, proxies and application boundaries using evidence.

01 / CONCEPT MAP

Know what the parts mean.

Learn each concept deeply enough to recognize it, place it in the system and reason about normal and failed behavior.

01

IP, public/private addressing and CIDR

Define it · locate it · observe it · explain its failure mode.

02

Subnets, gateways, route tables and NAT

Define it · locate it · observe it · explain its failure mode.

03

DNS resolution and caching

Define it · locate it · observe it · explain its failure mode.

04

TCP, UDP, ports and sockets

Define it · locate it · observe it · explain its failure mode.

05

HTTP request/response

Define it · locate it · observe it · explain its failure mode.

06

TLS identity and encryption

Define it · locate it · observe it · explain its failure mode.

07

Firewalls, security groups, proxies and load balancers

Define it · locate it · observe it · explain its failure mode.

02 / SYSTEM FLOW

Trace it end to end.

Domain→DNS answer→Public endpoint→TLS→Reverse proxy / load balancer→Private application→Database

For every transition: identify input, output, identity, protocol, state, trust boundary, evidence and owner.

03 / GUIDED BUILD

Build, observe and explain.

Documentation and AI are allowed. The engineer must review every output and demonstrate the result from direct evidence.

  1. 01Resolve a domain and record each DNS step
  2. 02Trace connection to TCP and TLS
  3. 03Map Nginx 443 to Uvicorn 8000
  4. 04Restrict inbound and database paths
  5. 05Prove private egress through the intended route
  6. 06Capture one successful and one blocked request
  7. 07Draw the complete request and return path
04 / INCIDENT

Users receive 502 while the host is healthy. Inject a wrong upstream port, blocked security rule and stale DNS record.

Required investigation

State impact → collect evidence → form competing hypotheses → test the cheapest discriminator → isolate root cause → contain → correct → verify.

Evidence pack

Timeline, relevant logs/metrics, failed assumptions, root cause, correction, verification and one prevention action.

AI ownership

AI may suggest causes and commands. The engineer must explain why each check is safe, what result is expected and how the result changes the hypothesis.

05 / DESIGN CHALLENGE

Defend the decision.

Design public entry to a private application and database. Explain every route, trust boundary and allowed flow.

06 / VERIFY, SUBMIT & REVIEW

Submission evidence

Architecture review

  • Explain networking without relying on memorized commands.
  • Draw the flow and name what crosses every arrow.
  • Identify the most likely, highest-impact and hardest-to-detect failure.
  • Show the evidence that proves the solution works.
  • Defend one security, reliability and cost trade-off.

Definition of Done

  • Acceptance criteria pass
  • Flow is drawn and explained
  • Security implications considered
  • Logs/metrics checked
  • Failure is tested
  • AI output is understood
  • Runbook is reusable
  • Mentor review passes
07 / MENTOR GUIDE

Do not score memory. Score the engineer’s ability to form a model, collect evidence, make a safe change and defend the trade-off.

1 Cannot explain2 Understands with gaps3 Implements and troubleshoots4 Designs and reviews