# Knowledge Check: Ingress & NetworkPolicy Foundations

---

**1. You create an Ingress object with correct routing rules, but no traffic is ever routed
according to them. What's the most likely reason?**

*Answer:* No Ingress controller is installed/running in the cluster. Ingress objects are just
routing rules; a separate controller has to actually read and act on them, or nothing happens.

---

**2. True or false: by default, a Pod in Namespace A cannot reach a Pod in Namespace B unless a
NetworkPolicy explicitly allows it.**

*Answer:* False — the opposite is true by default. With NO NetworkPolicy in place at all,
every Pod can reach every other Pod regardless of Namespace. NetworkPolicy is what RESTRICTS
this default-open behavior, not what's required to enable connectivity in the first place.

---

**3. A NetworkPolicy selects Pods labeled `app: backend` and declares one ingress rule allowing
traffic from Pods labeled `app: frontend`. What happens to traffic from a Pod labeled
`app: admin-tool` trying to reach `backend`?**

*Answer:* It's blocked. Once a NetworkPolicy selects a Pod, only traffic matching one of its
explicit rules is allowed — everything else to that Pod is denied, including traffic that would
have worked fine before the policy existed.

---

**4. Why is Ingress the right tool for exposing an HTTP application by hostname, rather than
creating a separate LoadBalancer Service per hostname?**

*Answer:* A LoadBalancer Service typically provisions its own external IP/load balancer per
Service — one per hostname would mean paying for and managing N separate external endpoints.
Ingress lets one entry point route to many backend Services by hostname/path, which is both
cheaper and centralizes concerns like TLS termination.

## Instructor Notes

**Facilitation:** Question 2 catches a very common and consequential misconception — worth
confirming out loud that everyone actually updated their mental model, not just guessed
correctly.

**Approximate timing:** 5 minutes.