Kubernetes Networking & Network Policies Interview Questions

An empty podSelector in a NetworkPolicy is treated as a wildcard. It matches every pod in the namespace the policy is created in, and it does not reach into other namespaces. This is the standard idiom for a namespace-wide default-deny policy.

Kubernetes NetworkPolicies are opt-in restrictions. With no policy selecting a pod, its traffic flows freely in both directions, so both ingress and egress are allowed. Only when a policy's podSelector matches a pod does it begin enforcing rules on that pod's traffic.

The NetworkPolicyPeer type in the Kubernetes API supports podSelector (match pods by label), namespaceSelector (match namespaces by label), and ipBlock (match by CIDR range). nodeSelector is a scheduling field that appears in Pod specs to choose nodes; it is not a field of NetworkPolicyPeer and cannot be used to filter traffic.

The empty podSelector selects every pod in the frontend namespace. Because policyTypes lists only Ingress, the policy governs incoming traffic for those pods, and because the ingress list is empty there are no allow rules, so all incoming traffic is denied. Egress is not listed in policyTypes, so this policy places no restriction on outbound traffic from those pods.

The statement is true. Kubernetes pods are non-isolated by default, meaning they allow all ingress and egress traffic. A pod only becomes isolated in a given direction once a NetworkPolicy selects it and lists that direction in its policyTypes. If no NetworkPolicy selects the pod, nothing isolates it, so all traffic is permitted.

This statement is false. The kube-apiserver only stores NetworkPolicy resources and does not implement them. Enforcement, meaning actually allowing or dropping packets, is done by the CNI plugin or network provider (such as Calico, Cilium, or Weave Net) running on each node. If the cluster's CNI does not support NetworkPolicies, the objects have no effect.

A NetworkPolicy only takes effect for pods it selects via podSelector. Until a policy selects a pod, that pod is non-isolated and no restrictions apply, so all ingress and egress traffic is allowed. Isolation for a pod's ingress or egress direction begins only when a policy selects the pod and declares that direction in its policyTypes.

An empty selector matches all objects in its scope. For spec.podSelector, the scope is the NetworkPolicy's own namespace, so the policy applies to every pod in that namespace. Pods in other namespaces are not selected unless a policy in their own namespace selects them.

Kubernetes uses a default-deny model for isolated pods. Once a NetworkPolicy with Ingress in its policyTypes selects a pod, the pod becomes isolated for ingress. Only traffic matching at least one ingress rule across all applicable policies is permitted; everything else is implicitly denied. NetworkPolicy rules function as allow-lists, not deny-lists, so unmatched traffic is dropped automatically.

In Kubernetes NetworkPolicies, an empty label selector {} acts as a match-everything wildcard. An empty namespaceSelector within a peer selects all namespaces in the cluster, while an empty podSelector (at the policy spec level or within a peer) selects all pods within the NetworkPolicy's own namespace. Within a single peer, the podSelector and namespaceSelector are ANDed, so both being empty allows all pods in all namespaces. A namespace-wide default-deny is instead built from an empty spec-level podSelector with no ingress rules.

A NetworkPolicy only isolates the traffic direction(s) listed in policyTypes for the pods its podSelector matches. Here policyTypes is [Ingress], so inbound traffic to the selected pods is denied except what the ingress rule allows from the named namespace. Egress is absent from policyTypes and no egress rules exist, so the selected pods' outbound traffic is not restricted by this policy. Pods outside the selector are not affected.

The podSelector field in a NetworkPolicy's spec determines which pods in the namespace the policy governs. An empty podSelector ({}) has no label requirements, so it matches every pod in the namespace, and the policy effectively applies to all pods in that namespace.

When a NetworkPolicy lists Ingress in its policyTypes, the pods it selects become isolated for ingress, so only traffic matched by an ingress rule is allowed. If no ingress rules are provided, the set of permitted ingress sources is empty, so every inbound connection to the selected pods is blocked. This is the default-deny semantics for ingress; only traffic explicitly matched by at least one ingress rule would be permitted.

Within a single from entry, a namespaceSelector and a podSelector are combined with a logical AND. The namespaceSelector first picks the namespaces, and the podSelector then restricts the allowed sources to pods with matching labels inside those namespaces. This is what enables precise cross-namespace control, such as allowing only pods labeled app=frontend in the staging namespace. The statement is therefore true. (Separate from entries, by contrast, are combined with OR, which is a different behavior.)

An empty podSelector ({}) selects every pod in the policy's namespace. Listing Ingress in policyTypes makes the policy govern ingress traffic for those pods. When no ingress rules are defined (the field is absent or an empty list), there are no allow rules, so the default for selected pods is to deny all incoming connections. This is the standard default-deny-all-ingress pattern used to isolate a namespace.

A NetworkPolicy only affects pods matched by its spec.podSelector, here pods labeled app=db in app-prod. Because policyTypes lists only Ingress, those pods become isolated for ingress only; egress is not governed by this policy and stays allowed. The single ingress rule permits traffic from pods labeled app=web in the same namespace (the from entry has only a podSelector, so it implicitly matches the policy's own namespace) on TCP port 5432. Any other ingress to app=db pods is denied. Pods without the app=db label are not selected, so their connectivity is unchanged. The CNI plugin is what enforces these rules; the API server only stores the manifest.

Once a pod is selected by any NetworkPolicy's podSelector, it becomes isolated for the policy types listed in policyTypes (Ingress here, since the policy has ingress rules). Only traffic explicitly allowed by a matching policy is permitted, and all other ingress in that direction is denied. The policy allows only app=frontend, so ingress from app=worker to app=api is denied. No separate default-deny policy is needed, because selection by any NetworkPolicy already triggers isolation.

The policyTypes field in a Kubernetes NetworkPolicy accepts exactly two values: Ingress and Egress, spelled with a capital first letter. Ingress enables isolation for incoming traffic, and Egress enables isolation for outgoing traffic. The values are case-sensitive, so lowercase forms such as ingress are not valid policyTypes entries. When the field is omitted, Kubernetes infers the policy types from the rules present: if an ingress section exists, Ingress is implied, and if an egress section exists, Egress is implied.

The policy's podSelector: {} selects every pod in app, so it governs ingress to all of them. The two from entries are OR'd, so a source pod needs to match only one. Within the first entry, the namespaceSelector (env=prod) and the podSelector (role=worker) are AND'd, so the source must live in a prod-labeled namespace and carry role=worker; only the worker1 pod meets both conditions. The monitor pod is in prod but has role=helper, so it fails the first entry. The second entry has no namespaceSelector, so its podSelector (role=helper) matches only pods in the policy's own namespace app; no pod there has role=helper, so that entry matches nothing. worker2 is in staging (env=staging, not prod), helper is in dev (no env=prod label and the second entry is same-namespace only), and web is in app with role=worker, which matches neither entry.

The policy selects every pod in payments and lists Egress in policyTypes without any egress entries, so no outbound connection is allowed. DNS lookups are outbound UDP (and TCP for large responses) to port 53 on the CoreDNS pods, so they are blocked along with everything else. The fix is a narrowly scoped egress rule: a to entry with a namespaceSelector on kubernetes.io/metadata.name: kube-system and a podSelector on k8s-app: kube-dns, with ports for 53/UDP and 53/TCP. Egress policies are evaluated against the destination pod after service translation, so the pod selector is the correct target. Other egress stays denied, and an egress: [{}] rule that allows everything would be too broad.

NetworkPolicy is evaluated per pod on both sides: the source pod's egress rules and the destination pod's ingress rules must each allow the flow when that pod is selected by a policy of that type. app=web is selected by no policy, so it is unrestricted in both directions. app=api is selected by Policy 2, which restricts its ingress to app=web (any port) and its egress to app=db on TCP 5432. app=db is selected by Policy 1, which restricts only its ingress to app=api on TCP 5432; its egress is unrestricted because Policy 1 does not declare Egress. Tracing each option: web to api on TCP 8080 has an unrestricted source and an api ingress that admits web on any port, so it is allowed. api to db on TCP 5432 is allowed by api egress to db:5432 and by db ingress from api:5432. db to api on TCP 5432 has an unrestricted source, but api ingress admits only web, so it is denied. web to db on TCP 5432 has an unrestricted source, but db ingress admits only api, so it is denied. api to api on TCP 8080 is denied because api egress permits only db on TCP 5432.

A NetworkPolicy ingress rule's from is a list of NetworkPolicyPeer objects. Selectors placed inside the same list element are combined with AND, so a podSelector alongside a namespaceSelector in one element only matches pods within the namespaces that the namespaceSelector selects. Separate list elements are independent peers combined with OR, so each one adds its own permitted sources. A podSelector used without any namespaceSelector is restricted to the namespace where the NetworkPolicy is defined, which is why the second separate entry matches frontend pods only in the policy's own namespace rather than in every namespace. The YAML for the two forms differs mainly by whether the two selectors share one list bullet, so the bullet placement determines the semantics.

Within a single from entry, a namespaceSelector and a podSelector are ANDed: a source pod is allowed only if its labels match the podSelector and its namespace labels match the namespaceSelector. Adding a namespaceSelector also widens where the podSelector is evaluated, so it applies across every namespace labeled team=backend rather than only prod. The policy has one from entry holding both selectors, so the allowed sources are exactly the app=api pods in team=backend namespaces. The option claiming OR semantics is wrong because OR applies only between separate from entries. The option ignoring the pod selector is wrong because the pod label still must match. The option restricting the pod selector to prod is wrong because a namespaceSelector changes that scope.