CKA Practice Question: Cluster Architecture, Installation and Configuration
A ClusterRoleBinding grants cluster-admin access to a user. Which field in the ClusterRoleBinding specifies the user?
⚠ Common exam trap
CNCF often tests the distinction between `subjects` (who gets the permissions) and `roleRef` (what permissions they get), and candidates mistakenly choose `users` because it sounds intuitive, but Kubernetes uses the generic `subjects` field to accommodate multiple identity types.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
subjects
In Kubernetes RBAC, the `subjects` field in a ClusterRoleBinding (or RoleBinding) specifies the users, groups, or service accounts that the binding applies to. The `subjects` array contains objects with `kind`, `name`, and optionally `apiGroup` or `namespace`, allowing you to reference a specific user by name. Option B is correct because `subjects` is the only field that defines the identity of the principal receiving the permissions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
users
Why it's wrong here
The ClusterRoleBinding spec has no `users` field; the API field is `subjects`. If you tried to write `users:` under `subjects` or at the top level, the Kubernetes API would reject it as an unknown field during schema validation. To grant admin to a person, you must add an entry to `subjects` with `kind: User`, the username as `name`, and typically `apiGroup: rbac.authorization.k8s.io`. This is why `users` is syntactically invalid and cannot be used to specify the grantee.
- ✓
subjects
Why this is correct
`subjects` is the field in a ClusterRoleBinding that defines who the binding applies to. Each entry in the `subjects` list is an object with a `kind` of `User`, `Group`, or `ServiceAccount`. For a cluster admin grant, you would include a subject like `{"kind": "User", "name": "alice", "apiGroup": "rbac.authorization.k8s.io"}`. This field is the only place where the user identity is attached to the binding, so it is the correct answer.
- ✗
roleRef
Why it's wrong here
`roleRef` is a required, immutable field that points to the ClusterRole being bound, such as a `kind: ClusterRole` named `cluster-admin`. However, it does not contain or identify the user; it only names the role whose permissions are being granted. The API server reads `roleRef` to determine the permissions, and reads `subjects` to determine who receives those permissions. Therefore, `roleRef` is relevant to the authorization grant but is not the field that specifies the user.
- ✗
bindings
Why it's wrong here
There is no `bindings` field in a ClusterRoleBinding object. A ClusterRoleBinding is itself a binding object, and its `spec` consists of `subjects` and `roleRef`; no nested or sibling field named `bindings` exists. Supplying a `bindings` key would cause a validation error because it is not part of the RBAC v1 API schema. This option is wrong because it names a nonexistent field, unlike `subjects`, which is the actual field used to list users.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
About these practice questions
This CKA question is part of Courseiva's 302-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.