Troubleshooting an RBAC forbidden error

WHAT THIS TESTS This is hands-on RBAC debugging. The interviewer wants a methodical, least-privilege approach using the right kubectl tools, not a shortcut to cluster-admin.

A GOOD ANSWER COVERS Start by reproducing the check with impersonation: kubectl auth can-i list pods --namespace target --as the-user, or --as-group for groups. This tells you yes or no without needing their credentials. To enumerate everything the subject can do, use kubectl auth can-i --list --as the-user -n target. Next, find the bindings: kubectl get rolebindings,clusterrolebindings -n target -o wide, then kubectl describe the binding to see which role it references and whether the subject name matches exactly. Inspect the referenced role with kubectl describe role NAME -n target or describe clusterrole to confirm whether the pods resource and the list verb are present. Common root causes are a typo in the subject name, the binding being in the wrong namespace, the role missing the list verb, or a ServiceAccount token not actually bound.

COMMON WRONG ANSWERS Immediately granting cluster-admin or a broad ClusterRoleBinding fixes the symptom but violates least privilege and is a red flag. Forgetting that auth can-i with --as lets you test without the user present. Not checking the namespace on the binding.

LIKELY FOLLOW-UPS Difference between authentication and authorization failures. How to find which ServiceAccount a pod uses. Reading apiserver audit logs for the denial.

ONE CONCRETE EXAMPLE kubectl auth can-i list pods -n payments --as jane returns no. describe of the RoleBinding shows it grants a Role with only get and watch on pods, not list. Adding list to that Role resolves it with minimal blast radius.