Question 17
Domain 6: Security, RBAC & ConfigurationWhich Kubernetes RBAC resources should be created to allow user `dev-user` to list Pods and Deployments only in the `staging` namespace?
Correct answer: A
Explanation
Kubernetes RBAC uses a namespaced "Role" to define permissions within one namespace, and a "RoleBinding" to grant those permissions to a user. Because the access is limited to the "staging" namespace and only to "list" on "pods" and "deployments," the Role must be created in staging and bound there to dev-user.
Why each option is right or wrong
A. A Role in `staging` allowing `list` on `pods` and `deployments`, and a RoleBinding in `staging` that binds that Role to `dev-user`
Under Kubernetes RBAC, a namespaced `Role` grants permissions only within the namespace where it is created, and a `RoleBinding` in that same namespace attaches those permissions to a subject. Because the question limits access to the `staging` namespace and only to the `list` verb on the `pods` and `deployments` resources, the correct objects are a `Role` in `staging` with those two rules and a `RoleBinding` in `staging` pointing to `dev-user`; a `ClusterRole`/`ClusterRoleBinding` would be broader than required. The relevant API objects are defined in `rbac.authorization.k8s.io/v1`, with namespace scoping enforced by the `Role` and `RoleBinding` placement.
B. A ClusterRole allowing `get` on `pods` and `deployments`, and a ClusterRoleBinding that binds it to `dev-user`
C. A Role in `default` allowing `list` on `pods` and `deployments`, and a RoleBinding in `default` that binds it to `dev-user`
D. A ServiceAccount in `staging` and a RoleBinding that binds the ServiceAccount to `dev-user`