For a 3-tier app in one namespace, db Pods should accept TCP 5432 only from Pods labeled tier=api, not from tier=web. Which NetworkPolicy approach fits?
Select an answer to reveal the explanation.
Short Explanation
Picture the database as a vault that only the API desk can open—not the public web lobby. Put the NetworkPolicy on the db Pods and allow ingress from tier=api on 5432. Leave web out of that allow list and they stay outside.
Full Explanation
For a 3-tier app in one namespace, db Pods should accept TCP 5432 only from Pods labeled tier=api, not from tier=web. Select the db Pods and allow ingress from podSelector tier=api on the required port; do not allow tier=web. Picture the database as a vault that only the API desk can open—not the public web lobby. That ingress allowlist on the protected db Pods is the primary NetworkPolicy approach for municipal multi-tier apps.
Selecting db Pods and allowing ingress from the entire namespace with an empty namespaceSelector only is too broad and would include web clients. Selecting web Pods and setting egress deny to db so db ingress rules become unnecessary misunderstands the preferred control point: protect the database with precise ingress allows. Using a Service of type ExternalName so NetworkPolicy peer selectors are bypassed for SQL is incorrect; ExternalName does not disable NetworkPolicy evaluation for Pod traffic in that way.
Exam caveat: place ingress policies on the Pods being protected (database), with precise from peers and ports. Egress denies on clients can complement but do not replace server-side ingress allowlists when the question asks how db should accept only api. Operational check: verify connectivity from an api Pod to db:5432 succeeds and from a web Pod fails; show Pod labels and NetworkPolicy YAML during the city’s tiering review. Prefer stable tier labels across Deployments so policies remain readable as the app evolves.