A municipal Wi-Fi backend needs Pods to reach the public Internet for vendor API calls. At CKA administrator depth, how do Pods typically obtain outbound Internet access?
Select an answer to reveal the explanation.
Short Explanation
Pods usually leave the building through the node's front door with NAT — they don't each need a public LoadBalancer badge just to call an external API.
Full Explanation
A municipal Wi-Fi backend that needs Pods to reach the public Internet for vendor API calls typically obtains outbound Internet access by egressing through node networking with NAT or equivalent node/route configuration that masquerades Pod CIDR traffic toward external destinations. At CKA administrator depth, Pods rarely each receive public addresses; nodes SNAT or otherwise route Pod egress so vendor HTTPS calls succeed from inside the cluster.
Each Pod must not receive a public LoadBalancer IP before any outbound TCP session can leave the cluster. CoreDNS does not proxy all outbound HTTPS through kube-apiserver so Pods never use node networking. NetworkPolicy ingress rules alone do not open SNAT paths from Pods to the Internet.
Exam caveat: NetworkPolicy egress can still block Internet access even when NAT exists—check policy after routing. Operational check: test egress from a Wi-Fi backend Pod to an external endpoint, verify node masquerade/routing, and review egress NetworkPolicies if connects fail. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.