CKAD Practice Question: Application Environment, Configuration and Security
You create a Role named 'pod-reader' in the 'default' namespace with rules to get, list, and watch pods. A ServiceAccount 'app-sa' in the same namespace needs to be bound to this role. Which YAML snippet correctly creates the RoleBinding?
⚠ Common exam trap
CNCF often tests the distinction between Role and ClusterRole in the roleRef of a RoleBinding, where candidates mistakenly use 'kind: ClusterRole' when the actual resource is a namespaced Role, or use 'kind: ClusterRoleBinding' for a namespaced binding.
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
✓
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa apiGroup: '' roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io
It creates a RoleBinding in the 'default' namespace that binds the ServiceAccount 'app-sa' to the Role 'pod-reader' using the correct 'kind: Role' in the roleRef. The RoleBinding must reference a Role (not a ClusterRole) when the Role exists in the same namespace, and the apiGroup for the roleRef must be 'rbac.authorization.k8s.io'.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io
Why it's wrong here
A RoleBinding can legitimately reference a ClusterRole, but the resource you created named 'pod-reader' is a namespaced Role in the default namespace. With roleRef.kind set to ClusterRole, Kubernetes looks up a cluster-scoped ClusterRole of that name, which is not the Role you want. Consequently the ServiceAccount app-sa would not receive the permissions defined in your Role, so this manifest is incorrect.
- ✓
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa apiGroup: '' roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io
Why this is correct
This manifest is correct because it binds the ServiceAccount 'app-sa' to the namespaced Role 'pod-reader' in the default namespace. The roleRef uses kind: Role with the matching apiGroup rbac.authorization.k8s.io, and the subject explicitly sets apiGroup: '' to indicate a core ServiceAccount. This grants the ServiceAccount the permissions of the Role only within its namespace, exactly as intended.
- ✗
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io
Why it's wrong here
Even though the name 'pod-reader' appears in roleRef, specifying kind: ClusterRole forces the API to resolve a cluster-scoped object, not the Role in the default namespace. A RoleBinding does not fall back to a Role based on the name; the kind and name must precisely identify the RBAC object. This binding therefore targets the wrong RBAC kind and will not apply the permissions of your Role.
- ✗
kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa namespace: default roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io
Why it's wrong here
A ClusterRoleBinding is cluster-scoped and its roleRef must reference a ClusterRole, never a namespaced Role. Here kind: Role is used for pod-reader, but a Role is confined to a single namespace and cannot grant permissions across the entire cluster. The API will reject this manifest because the roleRef kind is invalid for a ClusterRoleBinding, so it cannot grant the intended access.
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
About these practice questions
One of 826 original CKAD practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD 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 CKAD exam.