Two NetworkPolicies select the same Pod: one allows ingress from frontend, another allows ingress from monitoring. How do they combine?
Select an answer to reveal the explanation.
Short Explanation
Think OR, not last-write-wins: each matching NetworkPolicy adds another door that may open. Frontend allow plus monitoring allow means either source can get in. They don't cancel or alphabetize.
Full Explanation
When two NetworkPolicies select the same Pod—one allowing ingress from frontend and another allowing ingress from monitoring—the allows combine additively with OR semantics. Traffic matching either policy’s ingress rules is permitted. Think OR, not last-write-wins: each matching NetworkPolicy adds another door that may open. Frontend allow plus monitoring allow means either municipal source can get in on the terms those policies define.
The newest policy does not replace the older one the way some firewall zone tools overwrite rules. The policies do not cancel each other into a total deny until one is deleted. Alphabetical policy names also do not determine sole enforcement. Understanding additive combination prevents surprise exposure when a second “helpful” monitoring policy is added beside a carefully scoped frontend policy.
Exam caveat: core NetworkPolicy has no explicit deny-entry primitive—isolation comes from being selected without a matching allow, and additional policies widen allows. Operational check: apply both allows selecting the same api Pod; verify frontend and monitoring clients both succeed; remove one policy and verify only the remaining source works. Document stacked policies in the municipal namespace runbook so auditors can compute the effective OR set without guesswork.