A school-district admin proposes using a NetworkPolicy to stop developers from listing Secrets via kubectl. What misconception should the CKA candidate correct?
Select an answer to reveal the explanation.
Short Explanation
NetworkPolicy is a traffic cop between Pods, not the badge checker at the API desk — kubectl Secret access is an RBAC problem.
Full Explanation
A school-district admin proposing to use a NetworkPolicy to stop developers from listing Secrets via kubectl must be corrected: NetworkPolicy filters Pod network traffic; it does not authorize or deny Kubernetes API requests—that is RBAC. kubectl list of Secrets is an apiserver authorization question answered by Roles, ClusterRoles, and bindings, not by CNI packet filters between Pods.
NetworkPolicy does not replace RoleBindings for read verbs on namespaced objects including Secrets. NetworkPolicy does not automatically map ingress rules into SubjectAccessReview decisions at the apiserver. NetworkPolicy is not the only supported way to revoke ServiceAccount tokens cluster-wide.
Exam caveat: keep RBAC, admission, and NetworkPolicy in separate mental buckets on the exam. Operational check: restrict Secret list/get with Role and RoleBinding for district developers, and use NetworkPolicy only for Pod-to-Pod or Pod-to-world traffic control. 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.