A RoleBinding must list the subject (bob) in the subjects array with exactly

kind: User, name: bob, apiGroup: rbac.authorization.k8s.io, and must point to the existing Role by setting roleRef.kind: Role, roleRef.name: pod-reader, roleRef.apiGroup: rbac.authorization.k8s.io.

Option B is the only snippet that contains all these mandatory, case-sensitive fields and values, thereby correctly binding user bob to the Role pod-reader in the namespace.

Option A – subjects.kind is ServiceAccount, not User; therefore does not bind the user bob.

Option C – roleRef.kind is ClusterRole; binds to a ClusterRole, not the namespace-scoped Role requested.

Option D – apiGroup is omitted in subjects/roleRef; absent apiGroup defaults are not allowed, rendering the binding invalid.

1. Kubernetes Documentation

“RBAC › RoleBinding and ClusterRoleBinding

” examples 1–3

lines showing “kind: User … roleRef: kind: Role”

https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding

2. Kubernetes API Reference v1.29

rbac.authorization.k8s.io/v1 RoleBinding schema

fields subjects[] and roleRef

Section “Required Fields”

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.29/#rolebinding-v1-rbac-authorization-k8s-io

3. The Linux Foundation (LFD459) “Kubernetes Security Fundamentals

” Chapter 3

Slide 27

“Binding a User to a Role” (shows identical YAML).