A court-records platform must forbid anonymous API access and require authenticated subjects for any authorized action. Which statement matches Kubernetes authorization posture?
Select an answer to reveal the explanation.
Short Explanation
The courthouse API starts locked: no badge, no filing. Authenticated identity alone is not a free pass—you still need an explicit binding for the verbs you use. Anonymous callers should not silently get view across the cluster.
Full Explanation
A court-records platform that must forbid anonymous API access and require authenticated, authorized subjects aligns with Kubernetes’ deny-by-default authorization posture. Authentication alone is not a free courthouse pass: subjects still need explicit RoleBindings or ClusterRoleBindings (or another authorized path) before verbs succeed. Unauthenticated or unbound callers should be rejected rather than silently inheriting broad read access across filing systems. Authenticated users do not automatically receive cluster-admin unless a deny Role exists; there is no such implicit admin grant, and RBAC is allow-list oriented. Anonymous requests do not always inherit the view ClusterRole in every namespace—that would violate secure defaults. NetworkPolicy default-deny governs Pod-to-Pod (and related) network traffic; it does not authenticate kubectl sessions to the API server or replace RBAC. Exam caveat: separate authentication (who are you?) from authorization (what may you do?)—both must succeed, and RBAC defaults to deny. Operational check: ensure anonymous auth is disabled or tightly limited per platform policy, confirm unbound test users get Forbidden, and grant only the minimal RoleBindings needed for court-records operators and ServiceAccounts.