# Guided Exercise: Planning a Namespace Layout

This is a paper-and-thinking exercise — work through it before the Lab, not during it.

## The scenario

You're setting up a small Kubernetes cluster for a class project with three teams (`frontend`,
`backend`, `data`), each running their own set of Pods, and you also need a shared area for
tools everyone uses (a shared logging dashboard, for example).

## Your task

Sketch out, on paper or in a scratch file:

1. What Namespaces would you create, and why? (Hint: think about who needs to see what, and
   whether any team's mistake — e.g. deleting the wrong Pod by accident — should be able to
   affect another team.)
2. If `frontend` team members should be able to manage their own Pods but NOT touch `backend`'s
   or `data`'s, what does that suggest about how Namespaces relate to access control? (You'll
   learn the actual mechanism, RBAC, in ROOT 09 — for now just reason about why Namespace
   boundaries make that kind of restriction possible at all.)
3. Would you put the shared logging dashboard in one of the three team Namespaces, or somewhere
   else? Justify your answer.
4. If two teams both need to run something they each call `web`, what would happen if they were
   in the SAME Namespace? What changes if they're in separate Namespaces?

## A reasonable answer to check yourself against

1. Three Namespaces (`frontend`, `backend`, `data`) — one per team, so each team's objects are
   isolated from the others and a mistake in one Namespace (deleting the wrong Pod, applying a
   bad manifest) can't accidentally affect a different team's workloads.
2. Namespace boundaries are what RBAC rules can be scoped TO — "this person can manage Pods in
   the `frontend` Namespace" is a real, common permission model. Without separate Namespaces,
   you'd have to distinguish access by resource name pattern instead of by boundary, which is
   far more error-prone.
3. A separate Namespace (e.g. `shared-tools` or `platform`) — it isn't owned by any one team,
   and mixing it into a team's Namespace would make it unclear who's responsible for it or
   accidentally couple its lifecycle to that team's.
4. In the SAME Namespace, object names must be unique — a second `web` Deployment would either
   fail to create or overwrite the first, depending on how it's applied. In SEPARATE
   Namespaces, both `frontend/web` and `backend/web` can coexist without conflict — the
   Namespace is part of what makes a name unique, not just the name itself.

If your answer differed meaningfully from this, re-read the lesson's Namespace section before
continuing to the Lab.

## Instructor Notes

**Facilitation:** Good as a 2-3 person small-group discussion in a live classroom before
revealing the reasonable answer — question 4 in particular often produces a genuine "oh" moment
once students realize name uniqueness is Namespace-scoped, not cluster-wide.

**Approximate timing:** 10 minutes live with discussion; 10 minutes self-paced.

**Optional extension:** ask what would need to be true for the `data` team to be ALLOWED to read
(but not modify) something in `shared-tools` — a good bridge to RBAC's read vs. write verbs,
covered properly in ROOT 09.