A water-utility engineer runs kubectl logs and receives a permission denied / forbidden response for their personal user. What is the most likely authorization gap?
Select an answer to reveal the explanation.
Short Explanation
kubectl logs is just another API call—if RBAC forgot the pods/log key for that user, the door stays locked even when the Pod is healthy. Fix the RoleBinding, not the water meter.
Full Explanation
kubectl logs is an API request to get pods/log (or the equivalent subresource). When a water-utility engineer receives permission denied or forbidden for their personal user, the most likely authorization gap is that the Role or ClusterRole bound to that user lacks permission to get pods/log in the target namespace. Fix the RoleBinding, not the water meter. A wrong API server hostname in kubeconfig typically yields connection or TLS name errors, not specifically a forbidden response for logs on an otherwise reachable API. Absence of a CoreDNS Deployment does not block authorized log API calls with a forbidden error; DNS issues present differently. An expired Pod image pull secret can prevent new pulls; it does not always block log reads for every identity on an already running pod. Exam caveat: Distinguish 403 Forbidden (RBAC) from 401 Unauthorized (authn). On CKA, know verbs and subresources: get on pods/log. Operational check: kubectl auth can-i get pods/log in the namespace as that user, update the Role/RoleBinding, retest logs, and grant least privilege for utility operators. In municipal production practice, record the finding in the incident ticket with command output snippets, confirm the fix under change control, and re-validate the user-facing civic service before closing the change window.