# Senior Istio playbook

Compressed reference for the senior-only Istio extension. Pair with [cheat-sheet.md](./cheat-sheet.md), [GLOSSARY.md](./GLOSSARY.md), and [repo-istio-map.md](./repo-istio-map.md).

## The senior shift
Intermediate understanding is: "I know the mesh model, sidecars, Gateway, VirtualService, DestinationRule, mTLS, telemetry, and the repo’s core Istio layout."

Senior understanding is: "I can explain what the mesh truly owns here, where the edge boundary really is, why the repo opts out of a full zero-trust posture, how routing and telemetry matter operationally, and when the proxy layer starts costing more than it buys."

## Six senior lenses
1. **Truthfulness beats brochures** — explain the live mesh posture, not just the full product feature list.
2. **The edge boundary matters** — know where ingress really happens and where TLS truly terminates.
3. **Routing realism matters** — distinguish CRD capability from what the repo actually uses at scale.
4. **Security posture is a trade-off** — explain both the conceptual model and the repo’s selective opt-out honestly.
5. **Telemetry is operational control** — mesh metrics matter because they already feed alerts and KEDA.
6. **Proxy power has a cost** — EnvoyFilter and extra mesh cleverness increase debugging and upgrade risk.

## Senior review checklist
- What does the mesh truly own here, and what is still owned by Helm, Kubernetes, ingress, or app code?
- Are we describing the edge boundary and TLS termination accurately?
- Are we claiming retries, subsets, mTLS, or authz features the repo does not actually rely on broadly?
- Does this change improve routing/telemetry enough to justify the added proxy complexity?
- Are EnvoyFilter or low-level patches worth their upgrade and debugging cost?
- Could a new engineer explain this mesh posture honestly after reading the config?

## Interview answer shapes
### What does the mesh really own here?
It owns sidecar-based traffic handling, routing CRDs, ingress-edge TLS, and telemetry — not the whole backend security/runtime stack.

### Why is the security story nuanced?
Because Istio can do SPIFFE/mTLS/authz conceptually, but this repo mostly opts out of that full backend posture and relies on edge TLS plus in-app auth.

### Why is telemetry such a strong local story?
Because sidecar metrics are already scraped, alerted on, and used for KEDA scaling — not just dashboards.

### What is the real job of a senior Istio reviewer?
To ask what the mesh truly guarantees, where local posture diverges from textbook Istio, and what debugging cost the extra proxy behavior adds.