mediumMultiple Choice
CKS Practice Question: The purpose of the --authorization-mode=RBAC flag…
What is the purpose of the --authorization-mode=RBAC flag on the API server?
⚠ Common exam trap
CNCF often tests the distinction between authorization modes and other API server flags (like admission plugins or audit logging), so candidates may confuse `--authorization-mode=RBAC` with enabling audit logging or admission controllers, when in fact each flag controls a completely separate subsystem.
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
✓
It enables role-based access control for the API server
The `--authorization-mode=RBAC` flag configures the Kubernetes API server to use Role-Based Access Control (RBAC) as its authorization mode. This means that when a request reaches the API server, after authentication, the authorization module checks the request against RBAC roles and role bindings to determine if the user or service account has permission to perform the requested action. Without this flag, the API server would default to other modes (e.g., AlwaysAllow) or require explicit configuration of a different authorizer.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
It enables role-based access control for the API server
Why this is correct
The --authorization-mode=RBAC flag configures the Kubernetes API server to evaluate every request against RBAC objects such as Role, RoleBinding, ClusterRole, and ClusterRoleBinding. This mode determines whether a principal (user, group, or ServiceAccount) is permitted to perform a specific verb (e.g., get, create, delete) on an API resource or non-resource endpoint. RBAC is the standard, recommended authorization mechanism for production clusters because it provides fine-grained, deny-by-default access control. Without this flag set to RBAC, the API server may fall back to permissive modes like AlwaysAllow.
- ✗
It disables anonymous authentication
Why it's wrong here
Anonymous authentication is governed by the API server's --anonymous-auth command-line flag, not by authorization mode. Setting --authorization-mode=RBAC does not turn off anonymous access; rather, anonymous requests (i.e., requests authenticated as user 'system:anonymous') still enter the authorization stage. In fact, RBAC can explicitly grant or deny permissions to the 'system:anonymous' user or the 'system:unauthenticated' group, enabling clusters to allow or block unauthenticated API calls. Disabling anonymous auth requires setting --anonymous-auth=false, which is an authentication‑layer decision independent of RBAC.
- ✗
It enables the NodeRestriction admission plugin
Why it's wrong here
NodeRestriction is an admission controller plugin, not an authorization mode. Authorization modes are specified via --authorization-mode and include values such as AlwaysAllow, AlwaysDeny, ABAC, RBAC, Node, and Webhook; each one controls whether a request is permitted after authentication. NodeRestriction, on the other hand, is an admission controller that limits what modifications a kubelet can make to Node and Pod objects, and it must be added to --enable-admission-plugins alongside RBAC. Confusing the two conflates the admission control pipeline with the authorization phase, which are distinct stages in the API request lifecycle.
- ✗
It enables audit logging for RBAC events
Why it's wrong here
Audit logging is controlled by separate flags such as --audit-log-path, --audit-policy-file, and --audit-log-maxbackup, which configure a dedicated audit backend. The --authorization-mode=RBAC flag only selects the mechanism that decides whether to allow or deny a request; it does not itself generate or record audit events. However, when RBAC is in use, audit logs can capture whether a request was allowed or denied based on RBAC decisions, but that logging behavior is an independent configuration. Enabling RBAC does not implicitly turn on audit logging for RBAC events or any other events.
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
Learn chapter
TLS Certificates and API Server Security
Key term
API Server Security
API Server Security refers to the practices, configurations, and controls that protect the Kubernetes API server from unauthorized access, data breaches, and malicious attacks.
Key term
RBAC Configuration
RBAC Configuration is the process of defining who can do what with which resources in a system by assigning roles that carry specific permissions.
About these practice questions
This CKS question is part of Courseiva's 845-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 CKS 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 CKS exam.