# Exercise 2 — OSI vs Devices and Protocols

## Scenario

Your team is choosing infrastructure for a new service and the conversation keeps using terms like "L4 load balancer," "L7 routing," and "layer 3 switch" without everyone agreeing on what those mean. You've been asked to write a short internal reference clarifying exactly what each layer of infrastructure can and cannot see, so the team stops picking the wrong tool for the wrong problem.

## Deliverables

1. **Device capability table.** Fill in a table with columns: Device | Highest OSI layer it reads | What field(s) it bases decisions on | One thing it is BLIND to (cannot see or use) because it doesn't operate at a higher layer. Cover at least these five devices: hub, switch, router, L4 load balancer, L7 load balancer/reverse proxy.

2. **Real routing decision.** Explain, with a concrete example URL (e.g. `https://api.example.com/v1/users` vs `https://api.example.com/v1/orders`), why only an L7 load balancer — not an L4 load balancer — could route those two requests to two different backend server pools based on the URL path, even though both requests might arrive on the exact same TCP connection to the exact same IP and port. Be specific about what information is or isn't visible to each device.

3. **The TLS blind spot.** If traffic is HTTPS and terminates TLS only at the backend server (not at the load balancer), explain what an L7 load balancer sitting in front of that traffic *cannot* do, and why — tie your answer back to which OSI layer encrypts what.

4. **Failure scenario.** A junior engineer says "our L4 load balancer is broken, it's not routing `/admin` requests to the admin server pool." Explain, using what you now know about OSI layers, why this is very likely not a load balancer bug at all, but a misunderstanding of what an L4 device is even capable of doing — and what the actual fix should be.

## Notes

- Use the theory file's device table (Section 5) as a starting reference, but write the justifications yourself.
- This exercise is deliberately about *capability boundaries*, not just definitions — every answer should explain WHY a device can or can't do something, tied to what data is visible at that layer.