CKA Practice Question: Cluster Architecture, Installation and Configuration
You are applying the following RBAC manifest:
--- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: development name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]
Which TWO statements are true about this Role? (Choose TWO.)
⚠ Common exam trap
It's easy for candidates to confuse a Role with a ClusterRole, mistakenly thinking a Role can grant permissions across all namespaces, or they assume that granting access to 'pods' implicitly grants access to related resources like secrets or logs.
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
✓
It allows reading pod details in the 'development' namespace
The Role explicitly defines rules for the 'pods' resource with verbs 'get', 'watch', and 'list' in the 'development' namespace. These verbs allow reading pod details such as their specifications, status, and metadata. The Role is scoped to the 'development' namespace, so it only grants these read permissions within that 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.
- ✗
It also grants access to secrets in the 'development' namespace
Why it's wrong here
The Role's rules in the manifest specify only the resource "pods" under its rule list. RBAC grants permissions to exactly the resource kinds enumerated in a rule, so permissions never extend to other resource types like "secrets." Without an explicit rule listing secrets and the appropriate verbs, this Role cannot read or access Secret objects in the development namespace—or anywhere else.
- ✓
It allows reading pod details in the 'development' namespace
Why this is correct
This Role grants the verbs "get," "watch," and "list" for the "pods" resource, which are all read-only operations in Kubernetes RBAC. "get" retrieves a single pod's details, "list" enumerates pods, and "watch" streams pod changes. Because the rule is scoped to the development namespace via a Role and the verbs are read-only, this correctly describes the permission to read pod details in that namespace.
- ✗
It grants permissions across all namespaces
Why it's wrong here
A Role in Kubernetes is inherently namespaced and cannot grant permissions across multiple namespaces. Only a ClusterRole, combined with a ClusterRoleBinding or RoleBinding, can authorize requests in all namespaces or for cluster-scoped resources. Since this manifest uses a regular Role, its effective scope is limited to the namespace in which it is created, so the claim of cluster-wide permissions is false.
- ✓
It grants permissions only within the 'development' namespace
Why this is correct
Unlike a ClusterRole, a Role is always bound to a single namespace, and the permissions contained in its rules apply only within that namespace. The manifest creates the Role in the development namespace, meaning every allowed verb—get, watch, and list—only affects pods in development. This is the correct description of the Role's namespace-scoped behavior.
- ✗
It allows creating pods in the 'development' namespace
Why it's wrong here
The manifest's verbs are exclusively read operations: "get," "watch," and "list." To create a pod, the RBAC rule must include the verb "create" for the pods resource. Because "create" is absent from the rule, any attempt to POST a new pod to the development namespace would be denied by the API server, so this option is incorrect.
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
Courseiva writes every CKA question from scratch — 302 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.