Emergency-management wants group oncall to use the built-in view ClusterRole, but only inside the incident namespace. Which binding achieves that?
Select an answer to reveal the explanation.
Short Explanation
You can hang a citywide rulebook on one floor’s door. A RoleBinding in incident can point at the view ClusterRole and still confine those verbs to that namespace for oncall. A ClusterRoleBinding would open every floor.
Full Explanation
Emergency-management wants group oncall to use the built-in view ClusterRole only inside incident. The binding that achieves that is a RoleBinding in incident that references the view ClusterRole and lists group oncall as a subject. RoleBindings may point at ClusterRoles; the permissions still apply only in the RoleBinding’s namespace—hanging a citywide rulebook on one floor’s door without opening every floor for after-hours responders. A ClusterRoleBinding to view for oncall grants view across all namespaces because ClusterRoleBindings are cluster-scoped. Annotating the view ClusterRole with namespace: incident does nothing meaningful to confine it; annotations are not how RBAC scopes ClusterRoles. Copying an empty Role named view into every namespace grants nothing useful and abandons the built-in ClusterRole’s actual rules. Exam caveat: RoleBinding + ClusterRole = namespaced grant of those cluster-defined rules; ClusterRoleBinding + ClusterRole = cluster-wide grant. Operational check: create the RoleBinding in incident, then as an oncall member verify list/get works in incident and fails in another municipal namespace; ensure no ClusterRoleBinding also attaches view to that group.