5 exercises — Master the vocabulary of Kubernetes RBAC — roles, bindings, verbs, and least privilege in professional English.
0 / 12 completed
1 / 12
Your team is deploying a monitoring agent that only needs to read pod metrics in the monitoring namespace. Which RBAC resource type is most appropriate and why?
A Role is the correct choice when permissions should be confined to a single namespace — it cannot grant access to other namespaces or cluster-scoped resources.
ClusterRole grants permissions either cluster-wide or can be bound at namespace scope via a RoleBinding — but its default purpose is broader access. For a monitoring agent in one namespace, creating a Role in that namespace and binding it with a RoleBinding scopes the blast radius: if the service account were compromised, an attacker could only interact with resources in the monitoring namespace, not the entire cluster. Always start with the narrowest permission scope.
Key vocabulary:
• Role — namespace-scoped permission set; only grants access within one namespace
• ClusterRole — cluster-scoped permission set; can grant access across all namespaces or to non-namespaced resources
• principle of least privilege — grant only the minimum permissions required for the task
2 / 12
You're writing a Role for a CI pipeline that needs to deploy applications but must not be able to delete resources. Which explanation of Kubernetes RBAC verbs is correct?
Kubernetes RBAC verbs fall into two natural groups: read-only (get, list, watch) and write/mutate (create, update, patch, delete) — and they must be listed individually for precise control.
"apply" is not a Kubernetes API verb — it's a kubectl client-side operation. "exec" grants container execution access, not resource manipulation. For a CI pipeline that deploys but never removes, the correct verb set is: ["get", "list", "watch", "create", "update", "patch"]. Omitting "delete" ensures a misconfigured pipeline or a compromised token cannot remove production resources. Never use wildcard verbs (["*"]) in service account roles.
Key vocabulary:
• get / list / watch — read-only verbs; watch is needed for controllers that react to changes
• create / update / patch — write verbs; patch modifies specific fields; update replaces the full resource
• delete — destructive verb; should be granted only when explicitly required and justified
3 / 12
A colleague asks you to explain in plain English how a pod gets its Kubernetes API permissions — the full binding chain. Which description is correct?
The RBAC permission chain is: ServiceAccount → RoleBinding → Role. The pod declares which ServiceAccount it runs as; the RoleBinding connects that ServiceAccount to a Role; the Role defines what the pod is allowed to do.
By default, pods use the "default" ServiceAccount in their namespace, which has no permissions beyond basic self-discovery. For any pod that calls the Kubernetes API, you create a dedicated ServiceAccount, define a Role with the necessary verbs and resources, then create a RoleBinding that links the two. ClusterRoleBindings work the same way but grant cluster-scoped access. This chain is what you explain when someone asks "why is my operator getting 403 Forbidden?"
Key vocabulary:
• ServiceAccount — a namespaced identity assigned to pods; used for API authentication
• RoleBinding — attaches a Role's permissions to a Subject (User, Group, or ServiceAccount) within a namespace
• ClusterRoleBinding — same as RoleBinding but grants permissions cluster-wide
4 / 12
A developer requests a ClusterRole with verbs: ["*"] and resources: ["*"] for their application's ServiceAccount, arguing it will be simpler to manage. How do you respond professionally?
Wildcard permissions (verbs: ["*"], resources: ["*"]) are equivalent to cluster-admin and represent a serious security risk — any bug or compromise in that application gains full cluster control.
Even in development, broad permissions establish a bad precedent: developers inherit the config across environments, wildcard roles get forgotten in code review, and they make security audits meaningless. The professional response acknowledges the developer's intent (simplicity) while redirecting to the correct practice. Offer to help enumerate permissions — tools like kubectl auth can-i --list and audit logs make this straightforward. NetworkPolicy controls network traffic, not API permissions — it's not a substitute.
Key vocabulary:
• wildcard verb ["*"] — grants all verbs on the specified resources; effectively no restriction
• cluster-admin — Kubernetes built-in ClusterRole with unrestricted access to everything
• kubectl auth can-i --list — shows what a given Subject is currently permitted to do
5 / 12
An audit log entry reads: "User 'system:serviceaccount:default:my-app' attempted 'create' on resource 'pods' in namespace 'kube-system' — DENIED." Which explanation correctly interprets this entry?
Reading an RBAC denial in an audit log requires parsing the subject identity, the attempted verb, the target resource, and the namespace — all four elements are present in this entry.
The subject "system:serviceaccount:default:my-app" tells you the namespace (default) and name (my-app) of the ServiceAccount. The verb is "create", the resource is "pods", and the target namespace is "kube-system". The DENIED verdict means the API server found no RoleBinding or ClusterRoleBinding granting this ServiceAccount the create verb on pods in kube-system. The fix: either add the permission intentionally (if the application legitimately creates pods there) or investigate why the application is attempting to create pods it shouldn't be.
Key vocabulary:
• audit log — immutable record of all API server requests including subject, verb, resource, and decision
• DENIED — no matching allow rule found; default deny in RBAC
• system:serviceaccount:namespace:name — canonical format for ServiceAccount identity in audit logs
6 / 12
Code Review Comment: Sarah flagged this PR with the comment: 'Hey team, I'm seeing a `create` verb on this RoleBinding for the my-app ServiceAccount. Could you clarify why it needs to create pods? It seems excessive – are we sure this isn't a security risk?' What is the most appropriate response to Sarah, explaining the RBAC configuration?
This question tests understanding of justifying RBAC verb usage. Option 2 accurately explains a legitimate need for `create` verbs (dynamic provisioning) while acknowledging potential security implications. Options 1 and 3 are overly permissive and don't address the core concern raised by Sarah. Option 4 is an inadequate response, lacking explanation.
7 / 12
Slack Message: David (a junior dev) sends this message to the team channel: 'I'm trying to grant my ServiceAccount access to read metrics from a monitoring namespace, but I keep getting permission errors. I added get and list verbs to a ClusterRole.' What is the most helpful piece of advice David should receive?
This question assesses the understanding of RBAC's granularity. Option 2 correctly identifies that `get` and `list` aren't sufficient for metrics access, highlighting the need for resource selectors (labels) to limit the scope. Options 1 is incorrect – `watch` isn't typically needed for reading metrics. Option 3 offers misguided advice about ClusterRoles. Option 4 is a completely irrelevant distraction.
8 / 12
PR Description: You're updating the PR description for a change to an RBAC Role. The original description stated: 'This role allows users to manage all Kubernetes resources.' Which of the following descriptions is most appropriate and secure?
The key here is emphasizing *least privilege*. Option 3 correctly highlights the importance of restricting permissions to only what's necessary. Options 1 and 2 are overly permissive and create significant security vulnerabilities. Option 4 is too vague and doesn't convey the core principle.
9 / 12
Stand-up Update: During your daily stand-up, you're asked about a recent issue. You explain: 'We've been having problems with our application not being able to update deployments. We gave the ServiceAccount a ClusterRole with update and patch verbs on all resources.' What is the most constructive piece of feedback you should offer?
This tests the ability to advocate for secure practices. Option 2 correctly identifies the problem – granting `update` and `patch` on *all* resources is too broad. It suggests using labels for granular control. Options 1 and 3 are accepting of a potentially insecure configuration. Option 4 is overly simplistic.
10 / 12
During a code review, Alice points out that the `Role` you created for the 'analytics' service has the verb `get` on resources like `secrets`. She asks if this is standard practice. Which of the following best explains why this might be problematic from an RBAC security perspective?
The core principle of RBAC is least privilege. Granting a service account blanket access to secrets (via the `get` verb) significantly increases its potential impact if it's compromised. A breach could allow unauthorized data extraction or modification. The correct answer emphasizes that restricting access based on the analytics service's specific needs is crucial for security.
11 / 12
You're investigating a Slack channel conversation where Ben is struggling to deploy a new version of his application. He states: 'I've given my ServiceAccount a ClusterRole that allows it to create deployments and pods in the 'dev' namespace.' Which statement accurately describes the potential issue based on RBAC best practices?
While creating deployments and pods *is* a standard operation, granting `create` verb on both deployments and pods within a namespace inherently increases the risk of unintended modifications or security vulnerabilities. RBAC best practice dictates least privilege – limiting the ServiceAccount's permissions to only what's absolutely necessary for its intended function minimizes potential damage.
12 / 12
Maria, a senior engineer, is reviewing a PR that creates a new RoleBinding. The PR grants the `default` ServiceAccount permission to create deployments in the `production` namespace. She notices the binding uses a ClusterRole named 'production-deployer'. Which of the following best describes the primary purpose of this RoleBinding configuration?
This RoleBinding grants broad deployment creation privileges. While fine-grained control is possible with more complex RBAC configurations, this setup prioritizes simplicity and direct access for the 'default' service account. The incorrect options either imply overly restrictive or permissive behavior, failing to reflect the core purpose of a basic deployment role.
What will I practise in "RBAC Configuration Language — Kubernetes Operations | CoderLingo"?
5 advanced exercises practising Kubernetes RBAC vocabulary — Role vs ClusterRole, verbs, ServiceAccount bindings, least privilege, and audit log interpretation.
How many exercises are in this module?
This module has 12 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Kubernetes Operations exercises?
Browse the full Kubernetes Operations hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.