An open-data team wants one NetworkPolicy object to restrict both inbound connections to selected Pods and outbound connections from those Pods. What must they configure?
Select an answer to reveal the explanation.
Short Explanation
One policy can guard both doors — list Ingress and Egress in policyTypes and fill in both rule sections.
Full Explanation
An open-data team that wants one NetworkPolicy object to restrict both inbound connections to selected Pods and outbound connections from those Pods must set policyTypes to include both Ingress and Egress and define the corresponding ingress and egress rule sections as needed. policyTypes declares which directions the policy governs; omitting Egress while intending outbound restriction is a common misconfiguration that leaves egress unrestricted.
Creating two Deployments—one for ingress filtering and one for egress filtering—linked by an ExternalName Service does not implement NetworkPolicy. Annotating the Pod with dual-stack=true does not make policyTypes ignored when IPv6 is enabled as described. Using only ingress rules does not imply egress deny-all whenever ingress is present.
Exam caveat: an empty egress list with policyTypes including Egress is deny-all egress for selected Pods—pair with DNS allows when needed. Operational check: set policyTypes to Ingress and Egress, define both rule sections for the open-data Pods, and test inbound and outbound paths separately. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.