RBAC grants verbs on resources within a defined scope. Service accounts should receive only operations required by their workload.
Before you start
You should understand Pods, Deployments and Services. Read desired configuration separately from observed cluster state. Use a development cluster when trying changes, and inspect events and status rather than assuming that an accepted manifest means the workload is ready to serve traffic.
The practical goal is to reason through this situation: A reader of selected resources does not need cluster-admin. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.
Step-by-step walkthrough
Step 1: Inventory actual operations
List needed resource kinds, verbs and scope.
Step 2: Grant narrow bindings
Avoid cluster-wide wildcards when namespace access is sufficient.
Step 3: Test forbidden operations
Successful reads alone do not prove excessive permissions are absent.
Worked scenario
A reader of selected resources does not need cluster-admin.
A controller reading selected ConfigMaps does not need rights to read Secrets or create workloads in every namespace. Trace its actual API calls and grant the smallest viable role. New operations should trigger explicit policy review rather than inheriting broad cluster-admin permissions from initial setup.
Common mistake
Wildcard resources and verbs expand access beyond the current need.
Verify the behavior
Check allowed and prohibited actions with the actual service account.
Interview exercise
Review a controller’s permissions.
Answer and reasoning
Trace its actual operations, scope bindings deliberately and test forbidden actions as well as successful ones.
Continue learning
Compare the scenario with the Kubernetes interview questions and test your understanding with the Kubernetes MCQs. For terminology and implementation details, consult the reference material.