CKA Practice Question: Cluster Architecture, Installation and Configuration
You need to create a ServiceAccount named 'deployer' and grant it permission to create Deployments in namespace 'app'. Which YAML snippet correctly creates the necessary RBAC resources?
⚠ Common exam trap
A common pitfall is the misconception that a RoleBinding can only bind a Role, but in fact a RoleBinding can bind a ClusterRole, granting the ClusterRole's permissions only within the RoleBinding's namespace. Therefore, option C is technically valid and would also satisfy the requirement. However, the exam's expected answer is option A because it uses a namespaced Role, adhering to the principle of least privilege. Option B is incorrect because it uses a ClusterRoleBinding, which grants permissions cluster-wide. Option D is incorrect because the Role is created in the 'default' namespace instead of 'app'.
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
✓
apiVersion: v1 kind: ServiceAccount metadata: name: deployer namespace: app --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: Role name: deployer apiGroup: rbac.authorization.k8s.io
It creates a ServiceAccount named 'deployer' in the 'app' namespace, a Role in the same namespace with rules allowing 'create' on 'deployments' (which belong to the 'apps' API group), and a RoleBinding that binds the ServiceAccount to that Role. This grants the ServiceAccount permission to create Deployments only within the 'app' namespace, which is the required scope.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
apiVersion: v1 kind: ServiceAccount metadata: name: deployer namespace: app --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: Role name: deployer apiGroup: rbac.authorization.k8s.io
Why this is correct
This is the correct solution as it precisely meets the requirements. It creates a `ServiceAccount` named `deployer` in the `app` namespace. A `Role` is then defined in the `app` namespace, granting the specific permission to create `deployments`. Finally, a `RoleBinding` in the `app` namespace associates this namespaced `Role` with the `deployer` `ServiceAccount`, ensuring permissions are confined strictly to the 'app' namespace.
- ✗
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: ClusterRole name: deployer apiGroup: rbac.authorization.k8s.io
Why it's wrong here
This configuration is incorrect because it uses a `ClusterRole` and `ClusterRoleBinding`. A `ClusterRoleBinding` grants the permissions defined in the `ClusterRole` across all namespaces in the cluster, not just within the 'app' namespace. The requirement is to grant permissions *only* in the 'app' namespace, making this a violation of the principle of least privilege by providing overly broad access.
- ✗
apiVersion: v1 kind: ServiceAccount metadata: name: deployer namespace: app --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: ClusterRole name: deployer apiGroup: rbac.authorization.k8s.io
Why it's wrong here
While technically functional, this option is considered incorrect in a best-practice scenario. A `RoleBinding` can indeed bind a `ClusterRole`, effectively limiting its permissions to the `RoleBinding`'s namespace. However, defining a `ClusterRole` for a permission that is strictly namespaced violates the principle of least privilege in terms of resource definition, making the intent less clear and potentially leading to broader access if the `ClusterRole` were inadvertently bound by a `ClusterRoleBinding`.
- ✗
apiVersion: v1 kind: ServiceAccount metadata: name: deployer namespace: app --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: default rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: Role name: deployer apiGroup: rbac.authorization.k8s.io
Why it's wrong here
This option is incorrect because the `Role` named `deployer` is defined in the `default` namespace, while the `ServiceAccount` and `RoleBinding` are in the `app` namespace. A `Role` is a namespaced resource, meaning its permissions are strictly confined to the namespace where it is created. Therefore, a `Role` in `default` cannot grant permissions to resources within the `app` namespace, rendering the `RoleBinding` ineffective for its intended purpose.
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.