Operators apply a NetworkPolicy that selects all Pods in a namespace and allows no ingress peers. What is the effective result until allow rules are added?
Select an answer to reveal the explanation.
Short Explanation
An empty "guest list" NetworkPolicy is a velvet rope—selected Pods get no inbound visitors until you add allow rules. It isn't cluster-wide, and it isn't waiting on an Ingress object.
Full Explanation
When a NetworkPolicy selects Pods in a namespace and applies ingress isolation without allow peers (empty or absent allow rules under an ingress-oriented policy), selected Pods become isolated for ingress: inbound traffic is denied by default until explicit allow rules are added. An empty guest list is a velvet rope—municipal Pods covered by that policy receive no inbound visitors until you name permitted peers and ports. That is the core default-deny-for-selected-Pods behavior candidates must know.
The policy does not wait for an Ingress HTTP resource to exist; NetworkPolicy filters Pod packets, while Ingress configures HTTP routing through a controller. It also does not make every Pod in every namespace cluster-wide unreachable; only Pods selected by that policy object in its namespace are affected by it. Interpreting empty ingress rules as “only egress is denied while ingress stays fully open” reverses the model for selected Pods under ingress isolation.
Exam caveat: Pods not selected by any NetworkPolicy remain unrestricted by that object. Enforcement also requires a CNI that implements NetworkPolicy. Operational check: apply a selecting ingress-deny policy to city app Pods, curl from another Pod and observe denial, add a precise allow, and retest success only for the allowed peer. kubectl describe networkpolicy should show podSelector and ingress rules for auditors reviewing the permits namespace.