CKA Practice Question: Cluster Architecture, Installation and Configuration
Which TWO of the following are valid ways to create a Role in the 'default' namespace that grants get and list on pods?
⚠ Common exam trap
Watch out — candidates often confuse Role with ClusterRole, or assume that any verb like 'discover' is valid, or overlook that the question requires both 'get' and 'list' verbs specifically.
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
✓
kubectl create role pod-reader --verb=get,list --resource=pods -n default
Option A is correct because `kubectl create role` is the imperative command for creating a namespaced Role, and `--verb=get,list --resource=pods -n default` precisely specifies the get and list verbs on pods in the default namespace. Option D is correct because a declarative YAML manifest with `apiVersion: rbac.authorization.k8s.io/v1`, `kind: Role`, and a rule using the core API group (`apiGroups: [""]`), `resources: ["pods"]`, and `verbs: ["get", "list"]` defines exactly the required namespaced Role. Option B is wrong because `discover` is not a valid RBAC verb for granting pod access. Option C is wrong because `delete` grants deletion, not get/list. Option E is wrong because `kubectl create clusterrole` creates a ClusterRole (cluster-scoped), not a Role in the default namespace.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
kubectl create role pod-reader --verb=get,list --resource=pods -n default
Why this is correct
This command imperatively creates a Role named pod-reader in the default namespace, explicitly selected with -n default. The verbs get and list are valid RBAC verbs that map to reading an individual Pod and enumerating all Pods, respectively. Because it targets the pods resource in the core API group and uses the create role subcommand, the resulting object is namespaced and applies only within that namespace.
- ✗
kubectl create role pod-reader --verb=discover --resource=pods -n default
Why it's wrong here
The verb discover is not a recognized Kubernetes RBAC verb; valid verbs correspond to HTTP operations against the API server, such as get, list, watch, create, update, patch, delete, and deletecollection. kubectl create role validates the supplied verbs against this set, so this command would fail or produce an invalid Role definition. Therefore it cannot create a usable Role in any namespace.
- ✗
kubectl create role pod-reader --verb=delete --resource=pods -n default
Why it's wrong here
While delete is a legitimate RBAC verb, this command grants only delete permission on pods, which is the opposite of the read-only behavior implied by the name pod-reader. It omits the essential get and list verbs that would allow reading Pod objects. Although the command would create a Role if executed, it is not a valid answer to the question because it does not fulfill the stated requirement of read access to pods.
- ✓
Apply a YAML with apiVersion: rbac.authorization.k8s.io/v1, kind: Role, rules: [apiGroups: [""], resources: ["pods"], verbs: ["get", "list"]]
Why this is correct
This declarative YAML defines a Role using apiVersion rbac.authorization.k8s.io/v1, kind Role, and a rule targeting the core API group (apiGroups: [""]) with resources pods and verbs get and list. When applied via kubectl apply -f, it creates a namespaced Role in the namespace of the current context or a namespace explicitly set in metadata.namespace. This is a standard, valid alternative to the imperative command and is equally acceptable for creating the desired read-only Role.
- ✗
kubectl create clusterrole pod-reader --verb=get,list --resource=pods
Why it's wrong here
This command uses the clusterrole subcommand, which creates a ClusterRole—a cluster-scoped RBAC object that is not limited to a single namespace. The verb and resource choices are correct for reading pods, but the question asks specifically for a Role, and a ClusterRole cannot be substituted because it grants permissions across all namespaces or is intended for reuse through RoleBindings. Thus it does not satisfy the requirement to create a namespaced Role.
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 726 original CKA 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 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.