In a new namespace with healthy Pods and no NetworkPolicy objects, what is the default Pod-to-Pod connectivity posture?
Select an answer to reveal the explanation.
Short Explanation
Out of the box, Kubernetes is a friendly open office—Pods can chat until someone hangs NetworkPolicy doors. No policies means no extra isolation. Default-deny is something you add on purpose.
Full Explanation
In a new namespace with healthy Pods and no NetworkPolicy objects, the default Pod-to-Pod connectivity posture is permissive: all Pod-to-Pod traffic is allowed until NetworkPolicies restrict it. Out of the box, Kubernetes behaves like a friendly open office—Pods can chat until someone hangs NetworkPolicy doors. Default-deny is an explicit posture you add for municipal namespaces, not the implicit starting state of the Kubernetes network model.
Ingress is not denied by default with only kubelet probes working when no policies exist. Egress is not denied until a default-allow NetworkPolicy is applied—without policies, egress is also open from a NetworkPolicy perspective. Only traffic through a LoadBalancer Service is not required for Pod-to-Pod communication; east-west traffic uses the Pod network directly without needing a LoadBalancer or NodePort.
Exam caveat: “no NetworkPolicy” means no extra isolation from that API—not an implicit deny. Candidates who assume cloud security-group semantics inside every namespace often miss this. Operational check: curl between two Pods in a fresh namespace and observe success; apply a default-deny ingress policy and observe failure; explain this default during onboarding so city developers understand why platform teams mandate default-deny NetworkPolicies in permits and similar namespaces after the open baseline.