CKA RBAC Hands-On Guide: Roles, Bindings, and ServiceAccounts (2026)

RBAC questions appear on nearly every CKA exam. The mechanics are simple — four resources, three commands, one verification step — but the surface area for small mistakes (wrong namespace, wrong subject, missing verb) is huge. This guide turns RBAC into a deterministic recipe: read the question, identify the four pieces, apply the template, and verify with kubectl auth can-i.

By the end, you’ll have a mental model for any RBAC scenario the exam throws at you, from “create a service account that can list pods” to “diagnose why this user can’t read secrets.”

The RBAC Four-Resource Model

Every Kubernetes RBAC permission is a combination of four pieces:

1. Subject: who? A User, Group, or ServiceAccount.
2. Role / ClusterRole: what permissions? A list of verbs on resources.
3. RoleBinding / ClusterRoleBinding: how is the role attached to the subject?
4. Scope: where? A namespace (Role / RoleBinding) or cluster-wide (ClusterRole / ClusterRoleBinding).

When you read an RBAC question, identify each of the four. Once you do, the kubectl commands write themselves.

	Namespace-scoped	Cluster-scoped
Permissions	Role	ClusterRole
Binding	RoleBinding	ClusterRoleBinding

A RoleBinding can also bind a ClusterRole — a useful pattern when you have a generic ClusterRole (like view) and want to apply it in a specific namespace.

Subjects: Users, Groups, and ServiceAccounts

Kubernetes doesn’t have a User object. Users are external identities authenticated by certificates, OIDC, or other external systems. The CKA tests two kinds of subjects:

ServiceAccounts (most common on the exam)

A namespaced Kubernetes resource. Pods authenticate as a ServiceAccount.

kubectl create sa app-sa -n dev
kubectl get sa -n dev

Users (created externally; the exam gives you the name)

You don’t create users — they’re authenticated externally. The exam will tell you “user jane should be able to…” and you reference jane in a binding.

# Verify what a user can do
kubectl auth can-i list pods --as=jane -n dev

Creating Roles: Imperative First, YAML Only When Needed

The imperative kubectl create role covers 90% of CKA RBAC questions. Memorize this exact form:

kubectl create role <name> \
  --verb=<verbs-comma-separated> \
  --resource=<resources-comma-separated> \
  -n <namespace>

Examples:

# Read-only access to pods
kubectl create role pod-reader --verb=get,list,watch --resource=pods -n dev

# Manage deployments
kubectl create role deploy-manager \
  --verb=get,list,watch,create,update,patch,delete \
  --resource=deployments -n dev

# Multiple resources
kubectl create role app-admin \
  --verb=get,list,create,update,delete \
  --resource=pods,services,configmaps -n dev

# Subresource (e.g., pod logs)
kubectl create role log-reader --verb=get --resource=pods/log -n dev

# Specific resource name (lock down to one resource)
kubectl create role secret-reader \
  --verb=get --resource=secrets --resource-name=app-secret -n dev

For ClusterRole, the syntax is identical except for clusterrole and no -n:

kubectl create clusterrole node-viewer --verb=get,list,watch --resource=nodes
kubectl create clusterrole pv-admin --verb=get,list,create,delete --resource=persistentvolumes

When You Need YAML (Aggregation, Non-Resource URLs)

The imperative form doesn’t support nonResourceURLs (used to grant access to API endpoints like /healthz) or aggregated ClusterRoles. For those, write YAML:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: health-checker
rules:
  - nonResourceURLs: ["/healthz", "/healthz/*"]
    verbs: ["get"]

The CKA rarely tests these, but they’re worth recognizing.

Creating Bindings

The imperative kubectl create rolebinding (or clusterrolebinding) covers every CKA scenario:

# Bind a role to a user
kubectl create rolebinding pod-reader-binding \
  --role=pod-reader --user=jane -n dev

# Bind a role to a service account
kubectl create rolebinding app-sa-binding \
  --role=pod-reader --serviceaccount=dev:app-sa -n dev

# Bind a role to a group
kubectl create rolebinding readers-binding \
  --role=pod-reader --group=developers -n dev

# Bind a ClusterRole inside a namespace (RoleBinding + ClusterRole)
kubectl create rolebinding view-in-dev \
  --clusterrole=view --user=jane -n dev

# Cluster-wide: ClusterRole + ClusterRoleBinding
kubectl create clusterrolebinding view-everywhere \
  --clusterrole=view --user=jane

# Multiple subjects in one binding
kubectl create rolebinding multi-binding \
  --role=pod-reader \
  --user=jane --user=bob \
  --serviceaccount=dev:app-sa \
  -n dev

ServiceAccount + Role + Binding: The Pod Permissions Pattern

The most common CKA scenario: “Create a service account, give it permissions, and use it from a pod.”

# 1. Create the ServiceAccount
kubectl create sa monitoring-sa -n dev

# 2. Create the Role
kubectl create role pod-watcher \
  --verb=get,list,watch --resource=pods -n dev

# 3. Bind them
kubectl create rolebinding monitoring-sa-binding \
  --role=pod-watcher \
  --serviceaccount=dev:monitoring-sa \
  -n dev

# 4. Create a pod that uses the ServiceAccount
kubectl run watcher --image=busybox \
  --serviceaccount=monitoring-sa \
  -n dev --command -- sleep 3600

# 5. Verify from inside the pod
kubectl exec -it watcher -n dev -- sh
# Inside the pod:
# wget --header="Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
#   --no-check-certificate \
#   https://kubernetes.default.svc/api/v1/namespaces/dev/pods

In modern Kubernetes (1.24+), pods don’t get a long-lived token by default — they get a projected, time-limited token. For most exam questions, the default mounted token is sufficient.

Verifying Permissions with kubectl auth can-i

This is the single most important RBAC command. Use it to verify your work before declaring a question complete.

# As a user
kubectl auth can-i list pods --as=jane -n dev
kubectl auth can-i delete deployments --as=jane -n dev

# As a service account (note the system: prefix)
kubectl auth can-i list pods --as=system:serviceaccount:dev:app-sa -n dev

# Check yourself
kubectl auth can-i list pods

# Check everything you can do (long output)
kubectl auth can-i --list --as=jane -n dev

If can-i returns no when you expect yes, work backwards:

1. Does the binding exist? kubectl get rolebinding -n <ns>
2. Does it reference the right subject? kubectl describe rolebinding <name> -n <ns>
3. Does the Role exist? kubectl describe role <name> -n <ns>
4. Does the Role include the verb and resource you need?
5. Is the namespace correct?

Common RBAC Question Variants

Variant 1: Create a SA with Specific Permissions

Create a ServiceAccount deploy-sa in namespace apps that can manage deployments in that namespace.

kubectl create sa deploy-sa -n apps
kubectl create role deploy-manager \
  --verb=get,list,watch,create,update,patch,delete \
  --resource=deployments -n apps
kubectl create rolebinding deploy-sa-binding \
  --role=deploy-manager --serviceaccount=apps:deploy-sa -n apps

# Verify
kubectl auth can-i create deployments \
  --as=system:serviceaccount:apps:deploy-sa -n apps

Variant 2: User With Cluster-Wide Read Access

User auditor should be able to view (read-only) all resources in all namespaces.

kubectl create clusterrolebinding auditor-view \
  --clusterrole=view --user=auditor

# Verify
kubectl auth can-i list pods --as=auditor -n kube-system
kubectl auth can-i delete pods --as=auditor -n dev   # should be no

The built-in view ClusterRole already covers cluster-wide read of most resources. Don’t reinvent it.

Variant 3: Lock Down to One Specific Resource

User app-deployer should be able to update the deployment web in namespace prod — and no other deployments.

kubectl create role web-updater \
  --verb=get,update,patch \
  --resource=deployments \
  --resource-name=web \
  -n prod
kubectl create rolebinding app-deployer-binding \
  --role=web-updater --user=app-deployer -n prod

# Verify
kubectl auth can-i update deployment/web --as=app-deployer -n prod   # yes
kubectl auth can-i update deployment/api --as=app-deployer -n prod   # no

The --resource-name flag is the key. It restricts the role to a specific named object.

Variant 4: Service Account Can Read Secrets in One Namespace Only

kubectl create sa secret-reader -n prod
kubectl create role read-secrets --verb=get,list --resource=secrets -n prod
kubectl create rolebinding bind-secret-reader \
  --role=read-secrets --serviceaccount=prod:secret-reader -n prod

kubectl auth can-i list secrets \
  --as=system:serviceaccount:prod:secret-reader -n prod   # yes
kubectl auth can-i list secrets \
  --as=system:serviceaccount:prod:secret-reader -n dev    # no

Variant 5: Diagnose Why a User Can’t Do Something

User jane is getting “forbidden” when running kubectl get pods -n dev. Diagnose and fix.

# 1. Confirm the failure
kubectl auth can-i list pods --as=jane -n dev

# 2. List bindings touching jane
kubectl get rolebindings -n dev -o wide | grep jane
kubectl get clusterrolebindings -o wide | grep jane

# 3. Inspect the binding (if any) and the role it references
kubectl describe rolebinding <binding> -n dev
kubectl describe role <role> -n dev

The fix is one of:

• Binding doesn’t exist → create it.
• Binding exists but points at the wrong role → recreate.
• Role exists but is missing the right verb or resource → edit the role.
• All of the above are correct but the namespace is wrong → check the binding’s namespace field.

Built-In ClusterRoles to Know

Kubernetes ships with several ClusterRoles that you can reuse instead of writing your own:

ClusterRole	What it grants
view	Read-only access to most resources (no secrets)
edit	Read/write to most resources in a namespace
admin	Full namespace admin (no namespace creation)
cluster-admin	Superuser everywhere

Examples:

# Give jane read-only access in all namespaces
kubectl create clusterrolebinding jane-view --clusterrole=view --user=jane

# Give the dev-team group full edit in the dev namespace
kubectl create rolebinding dev-team-edit \
  --clusterrole=edit --group=dev-team -n dev

When the question says “view-only access” or “full access in this namespace,” reach for the built-in ClusterRoles before writing a custom Role.

Common RBAC Mistakes (and How to Avoid Them)

1. Wrong subject prefix for ServiceAccounts. Use system:serviceaccount:<ns>:<name> with --as, but --serviceaccount=<ns>:<name> when creating the binding. The two formats are not interchangeable.
2. Forgetting the namespace on Role/RoleBinding. Roles and RoleBindings are namespaced. ClusterRoles and ClusterRoleBindings aren’t. Mixing them up = silent permission failure.
3. Granting cluster-admin “just to make it work.” The grader checks specifics. cluster-admin will pass can-i for everything but fail the question when the grader expects only pod-reader.
4. Skipping kubectl auth can-i. This is the cheapest verification step in the entire exam. Always run it before moving to the next question.
5. Wrong API group for resources. deployments is in apps, roles is in rbac.authorization.k8s.io. kubectl create role infers the right group automatically — only an issue if you write YAML by hand.

How to Practice RBAC

Build a kubeadm cluster (see our Kubernetes lab setup for CKA guide) and create a “users” sandbox:

1. Generate three test users with openssl + a kubeadm-signed cert (or use ServiceAccounts as a stand-in).
2. Build the five variants above on each one.
3. Tear down the bindings and recreate from memory under a 5-minute timer.
4. Practice “diagnose forbidden” scenarios by deliberately breaking one piece (wrong namespace, missing verb, wrong subject) and fixing it.

If you can do all five variants in under 10 minutes total, RBAC won’t be the domain that fails you.

Validate Your RBAC Speed Under Exam Conditions

Drilling on your own cluster builds the muscle memory. The CKA tests whether that muscle memory holds up under exam pressure with unfamiliar phrasing. Take a full-length scored simulator with our CKA Mock Exam Bundle — every simulator includes RBAC questions in the exact CNCF format, so you’ll know exactly how fast you are before exam day.

Frequently Asked Questions

Q: How many RBAC questions appear on the CKA? A: Typically 1-3 questions. Combined with troubleshooting and security, RBAC concepts touch ~10-15% of the score.

Q: Do I need to know how to create a User? A: No. Users are externally authenticated. The exam gives you the username; you create the binding.

Q: What’s the difference between --user and --serviceaccount in kubectl create rolebinding? A: --user=jane creates a User subject. --serviceaccount=dev:app-sa creates a ServiceAccount subject. The binding YAML differs in the subjects block.

Q: Can one RoleBinding bind multiple subjects? A: Yes. Pass multiple --user, --group, or --serviceaccount flags to kubectl create rolebinding.

Q: When should I use ClusterRole + RoleBinding instead of Role + RoleBinding? A: When the permissions are generic (like “view”) and you want to apply them in a specific namespace, reuse a ClusterRole. It avoids duplicating Role definitions across namespaces.

Q: Does kubectl auth can-i count toward exam time? A: It runs in milliseconds. Always use it. The 5 seconds you spend verifying is the cheapest insurance on the exam.

Q: Can I see all bindings touching a user or service account? A: There’s no built-in command, but kubectl get rolebindings,clusterrolebindings -A -o wide | grep <name> is close enough. For ServiceAccounts use system:serviceaccount:<ns>:<name>.

Ready to make RBAC questions automatic points on your CKA? Run a scored full-length simulator with our CKA Mock Exam Bundle and find out how fast you really are.