A city permits API service must call the Kubernetes API to get and list Endpoints using its Pod's ServiceAccount. How should the team grant only those permissions?
Select an answer to reveal the explanation.
Short Explanation
Think of the ServiceAccount as the app's badge at the API desk—badges need explicit permissions, not a master key. Grant get/list on endpoints with a namespace Role and RoleBinding to that SA. Cluster-admin or NetworkPolicies are the wrong tools for API authorization.
Full Explanation
Municipal API workloads that read Endpoints authenticate as their Pod ServiceAccount, but authentication alone never authorizes API verbs. Kubernetes RBAC still requires an explicit Role (or ClusterRole) that lists the needed verbs and resources, plus a RoleBinding (or ClusterRoleBinding) that names that ServiceAccount as a subject. For a city permits service that only needs to get and list Endpoints inside its own namespace, the least-privilege pattern is a namespaced Role with get and list on endpoints, bound to the app ServiceAccount with a RoleBinding in the same namespace. That grants exactly the desk privileges the microservice needs at the API desk without handing over citywide admin rights.
Binding the ServiceAccount into cluster-admin is the opposite of least privilege: the permits Pod would inherit nearly every verb on every resource cluster-wide, far beyond Endpoints reads. Turning automountServiceAccountToken off and hoping anonymous access will succeed is also wrong; anonymous callers are typically denied those verbs, and disabling the token removes the intended identity rather than authorizing it. NetworkPolicy allow rules control packet paths between Pods; they do not evaluate Kubernetes API RBAC verbs, so a NetworkPolicy cannot substitute for Role and RoleBinding objects.
Exam caveat: remember the split between Role/ClusterRole (permission sets) and RoleBinding/ClusterRoleBinding (who receives those permissions). Naming the ServiceAccount only in a Role rule without a binding does not authorize the Pod. Operational check: from a temporary Pod using the same ServiceAccount, run kubectl auth can-i get endpoints --as=system:serviceaccount:<ns>:<sa> (or call the API with the mounted token) and confirm get/list succeed while unrelated verbs remain denied. After applying the Role and RoleBinding, watch Events and API responses when the permits app lists Endpoints to verify authorization failures disappear without widening the Role to cluster-admin.