# Reflection: Reachability Should Be a Decision, Not a Default

You just configured real Ingress routing and real network isolation. Take a few minutes to
connect this to production thinking.

## Reflection questions

1. Before this module, would you have assumed a fresh Kubernetes cluster isolates Pods from
   each other by default? Has that changed?
2. If your team runs a multi-tenant cluster (several unrelated applications sharing it), what's
   the risk of NEVER applying any NetworkPolicy at all?
3. Ingress lets many different domains share one entry point. What's the operational benefit of
   that beyond just "fewer objects to manage"?

## Real Ops takeaway

**"No NetworkPolicy" is not neutral — it's full reachability.** Exactly like an unhardened
Pod's SecurityContext (ROOT 09 covers this in depth), the absence of a NetworkPolicy isn't a
safe default; it's the MOST permissive configuration available. On any cluster where more than
one team or application shares infrastructure, that's a real, often-overlooked exposure.

**Centralizing external entry points through Ingress reduces attack surface, not just object
count.** Every separate LoadBalancer Service is a separate externally-reachable endpoint to
secure, monitor, and patch. Routing through one (or a small number of) Ingress controllers means
security controls — TLS termination, rate limiting, WAF rules — are configured and audited in
one place instead of scattered across every application team's own Service definitions.

This module is complete. Continue to the next module.

## Instructor Notes

**Discussion questions for a live classroom:** question 2 is worth pushing on with a concrete
scenario — ask what a compromised low-value application (a demo app, a staging environment)
could reach on a cluster with zero NetworkPolicies, versus one with sensible defaults.

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

**Optional extension:** ask students to sketch (in words) what a reasonable DEFAULT-DENY policy
for an entire new namespace would look like, before any application-specific allow rules are
added — previews the security-control framing ROOT 09 builds on.