CKA Practice Question: Cluster Architecture, Installation and Configuration
You have a ClusterRole named 'deployer' that allows creating Deployments and Services. You want to grant a ServiceAccount 'ci-cd' in namespace 'app' the permissions defined in this ClusterRole. Which TWO resources are needed? (Choose TWO.)
⚠ Common exam trap
Many candidates confuse RoleBinding and ClusterRoleBinding, thinking a ClusterRole must always be bound with a ClusterRoleBinding, but a RoleBinding can bind a ClusterRole to grant permissions only in a specific namespace.
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
✓
The existing ClusterRole 'deployer'
Option A is correct because the existing ClusterRole 'deployer' already contains the desired rules (create Deployments and Services), so it can be referenced directly without duplicating it. Option C is correct because a RoleBinding in namespace 'app' can reference a ClusterRole and bind it to the ServiceAccount 'ci-cd', thereby granting those ClusterRole permissions only within the 'app' namespace. Option B is unnecessary since the ClusterRole already exists and re-creating the same rules would be redundant. Option D is wrong because a ClusterRoleBinding would grant the permissions cluster-wide, not scoped to namespace 'app' as intended. Option E is incorrect because ServiceAccount tokens are handled automatically by Kubernetes and no manual Secret is required for this binding.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The existing ClusterRole 'deployer'
Why this is correct
The ClusterRole 'deployer' is the correct object to rely on because it already encapsulates the exact permissions needed to create resources. In RBAC, a ClusterRole is a cluster-scoped set of rules, but it does not grant anything until referenced by a binding. Reusing this existing ClusterRole avoids duplicating rules and keeps permission definitions centralized, which is the recommended practice.
- ✗
Create a new ClusterRole with the same rules
Why it's wrong here
Creating a new ClusterRole with identical rules is unnecessary and violates the principle of least privilege by introducing a second source of truth for the same permissions. If the new ClusterRole drifts even slightly from the original, you could accidentally grant broader access than intended. The existing 'deployer' ClusterRole already provides exactly the required 'create' verbs, so a duplicate adds management overhead and security risk without any benefit.
- ✓
RoleBinding in namespace 'app' referencing ClusterRole 'deployer' and ServiceAccount 'ci-cd'
Why this is correct
A RoleBinding in the 'app' namespace that references the ClusterRole 'deployer' and subjects the 'ci-cd' ServiceAccount is the precise, namespace-scoped way to grant those permissions. The RoleBinding's subjects field names the ServiceAccount, while the roleRef points to the ClusterRole; this binds the ClusterRole's rules only inside the 'app' namespace. This gives the ServiceAccount the ability to create resources in that namespace without affecting any other namespace.
- ✗
ClusterRoleBinding with subject ServiceAccount 'ci-cd' in namespace 'app'
Why it's wrong here
A ClusterRoleBinding with the subject ServiceAccount 'ci-cd' in 'app' would bind the 'deployer' ClusterRole at the cluster scope, meaning the ServiceAccount gains create permissions on all namespaces across the cluster. That is far broader than the requested 'app' namespace scope and violates least privilege because a compromised token could be used to create resources anywhere. If only 'app' needs access, a RoleBinding in 'app' is the correct scoping mechanism.
- ✗
A Secret for the ServiceAccount
Why it's wrong here
A Secret for the ServiceAccount only holds its bearer token and is used for authentication to the Kubernetes API server, not for RBAC authorization. Creating a Secret does not add any 'create' permissions to the ServiceAccount's effective access; it merely provides credentials to identify as that service account. To authorize actions, you must bind a Role or ClusterRole through a RoleBinding or ClusterRoleBinding; Secrets have no role in that decision.
Go deeper
Related to this question
Learn chapter
Installing Kubernetes with kubeadm
Key term
Deployments
A Kubernetes resource that manages a set of identical Pods, ensuring they run the correct number of replicas and can be updated or rolled back without downtime.
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 726-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.