CKAD Practice Question: Application Environment, Configuration and Security
You need to grant a ServiceAccount 'my-sa' read-only access to pods in the 'test' namespace. Which RBAC YAML should you create?
⚠ Common exam trap
CNCF often tests the distinction between Role and ClusterRole, and between RoleBinding and ClusterRoleBinding, to see if candidates understand that namespace-scoped access requires a Role and RoleBinding, not a ClusterRole and ClusterRoleBinding, even when the permissions are identical.
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: Role\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n namespace: test\n name: pod-reader\nrules:\n- apiGroups: [""]\n resources: ["pods"]\n verbs: ["get", "list", "watch"]\n---\nkind: RoleBinding\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n namespace: test\n name: read-pods\nsubjects:\n- kind: ServiceAccount\n name: my-sa\n namespace: test\nroleRef:\n kind: Role\n name: pod-reader\n apiGroup: rbac.authorization.k8s.io
It creates a Role in the 'test' namespace with read-only verbs ('get', 'list', 'watch') on pods, and binds that Role to the ServiceAccount 'my-sa' in the same namespace via a RoleBinding. This grants the ServiceAccount scoped, namespace-level read-only access to pods, which matches the requirement precisely.
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: ClusterRole\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n name: pod-reader\nrules:\n- apiGroups: [""]\n resources: ["pods"]\n verbs: ["get", "list", "watch"]\n---\nkind: ClusterRoleBinding\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n name: read-pods\nsubjects:\n- kind: ServiceAccount\n name: my-sa\n namespace: test\nroleRef:\n kind: ClusterRole\n name: pod-reader\n apiGroup: rbac.authorization.k8s.io
Why it's wrong here
This uses a ClusterRole and a ClusterRoleBinding, which apply the permission cluster-wide across every namespace. Although the rules are read-only and the subject is correctly specified, a ClusterRoleBinding grants those permissions in all namespaces, so the service account would be able to read pods outside the test namespace. That violates the principle of least privilege and is more access than intended.
- ✓
kind: Role\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n namespace: test\n name: pod-reader\nrules:\n- apiGroups: [""]\n resources: ["pods"]\n verbs: ["get", "list", "watch"]\n---\nkind: RoleBinding\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n namespace: test\n name: read-pods\nsubjects:\n- kind: ServiceAccount\n name: my-sa\n namespace: test\nroleRef:\n kind: Role\n name: pod-reader\n apiGroup: rbac.authorization.k8s.io
Why this is correct
This correctly defines a namespaced Role in the test namespace with read-only pod verbs (get, list, watch) and binds it to the specified service account using a RoleBinding in the same test namespace. Because both the Role and RoleBinding are namespaced, the access is scoped precisely to the test namespace. The verb set is limited to read operations, satisfying the read-only requirement exactly.
- ✗
kind: Role\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n namespace: test\n name: pod-reader\nrules:\n- apiGroups: [""]\n resources: ["pods"]\n verbs: ["create", "delete"]
Why it's wrong here
The apiGroup, resource, and namespaced Role are appropriate, but the verbs are create and delete, which are write operations rather than read-only. This would allow the service account to create and delete pods, directly contradicting the requirement for read-only access. Additionally, the Role is not bound to any service account via a RoleBinding, so it would not take effect. The correct verbs should be get, list, and watch.
- ✗
kind: Role\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n name: pod-reader\n namespace: default\nrules: ...\n---\nkind: RoleBinding ...
Why it's wrong here
This places the Role in the default namespace instead of the test namespace where the service account resides. A RoleBinding in test cannot reference a Role from another namespace, so even if a binding were created, it would be invalid or would need to use a ClusterRole instead. As written, the Role would apply only to pods in default, not the intended test namespace, so the service account would not have the requested permissions in the correct scope.
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
This CKAD question is part of Courseiva's 826-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 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.