# Reflection: Structure Isn't Bureaucracy, It's Communication

## Reflection questions

1. Why might a real engineering team insist on a consistent directory structure across every
   project, instead of everyone organizing files however they like?
2. Which of `/etc`, `/var`, `/home`, `/tmp`, `/usr`, `/proc` do you feel most confident you could
   explain to someone else right now? Which one still feels fuzzy?

## Real Ops takeaway

**A predictable filesystem layout is what lets tools (and other engineers) reason about a
system without asking you first.** `/etc` always means configuration, `/var/log` always means
logs — this convention is exactly why a monitoring tool can be pointed at "check `/var/log`" on
any Linux machine and just work. Container images later inherit this same convention (an
nginx container still keeps its config at `/etc/nginx/nginx.conf`) — you're not learning a
one-off Linux fact, you're learning a convention that outlives this specific module.

This module is complete. Continue to the next module.

## Instructor Notes

**Discussion questions for a live classroom:** question 1 connects directly to why Kubernetes
namespaces and Git repository conventions matter later — a good moment to name that connection
without going deep yet.

**Approximate timing:** 5-8 minutes live discussion; 5 minutes self-paced writing.