Question 24
Domain 6: Security, RBAC & ConfigurationWhich Kubernetes RBAC Role definition allows users to get, watch, and list Pods and access container logs?
Correct answer: A
Explanation
Kubernetes RBAC grants permissions by matching apiGroups, resources, and verbs in a Role. A Role with apiGroups: [""] for the core API and resources: ["pods", "pods/log"] with verbs: ["get", "watch", "list"] allows reading Pod objects and accessing container logs, since "pods/log" is the subresource used for log retrieval.
Why each option is right or wrong
A. A Role with apiGroups: [""] and resources: ["pods", "pods/log"] granting verbs: ["get", "watch", "list"]
Kubernetes RBAC authorizes access by exact match on the core API group and resource/subresource names: Pods are in the empty API group (""), and container logs are exposed through the Pod subresource `pods/log`. Under the RBAC rules in the Kubernetes API, `get`, `list`, and `watch` are the read-only verbs that permit retrieving Pod objects and observing them, while `pods/log` must be named explicitly to allow log access; omitting that subresource would not grant log retrieval.
B. A Role with apiGroups: ["apps"] and resources: ["deployments", "pods"] granting verbs: ["get", "watch", "list"]
C. A ClusterRole with apiGroups: [""] and resources: ["pods", "logs"] granting verbs: ["read", "view"]
D. A Role with apiGroups: [""] and resources: ["pods", "services"] granting verbs: ["get", "watch", "list", "logs"]