Match each Kubernetes API server flag to its security function.
Drag a concept onto its matching description — or click a concept then click the description.
Enables RBAC authorization
Comma-separated list of admission controllers to enable
Disables anonymous requests to the API server
Path to a CA file for verifying kubelet certificates
File containing PEM-encoded x509 RSA or ECDSA private or public keys for service account token signing
Answer choices
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
--authorization-mode=RBAC: Enables RBAC authorization
Correct matches: --authorization-mode=RBAC enables RBAC; --anonymous-auth=false disables anonymous auth; --profiling=false disables profiling. Common confusions involve mixing authorization and authentication flags.
Answer analysis
For each option: why learners choose it and why it is or isn't the right answer here.
--authorization-mode=RBAC: Enables RBAC authorization
Why this is correct
The `--authorization-mode=RBAC` flag configures the API server to use RBAC as the authorization mechanism. RBAC enforces access control by evaluating requests against Role, ClusterRole, RoleBinding, and ClusterRoleBinding objects, which specify which verbs (e.g., get, create, delete) a user or service account may execute on which API resources. Authentication must already be completed for a request to reach this stage, so this flag does not influence authentication or anonymous access.
--anonymous-auth=false: Disables anonymous authentication
Why this is correct
Setting `--anonymous-auth=false` explicitly disables the API server's default behavior of treating requests without any provided credentials as originating from the `system:anonymous` user. By denying these unauthenticated requests, the flag prevents unknown actors from reaching the authorization layer, thereby reducing the attack surface. It is a common hardening step but does not affect authenticated identities like valid service account tokens or client certificates.
--profiling=false: Disables profiling to prevent information disclosure
Why this is correct
`--profiling=false` turns off the API server's profiler endpoints under `/debug/pprof`, which expose sensitive runtime information such as goroutine stack traces, heap memory usage, and ongoing CPU profiles. An attacker who reaches these endpoints can gather system internals to craft a more effective exploit. Disabling profiling aligns with security baselines like CIS Kubernetes Benchmark, and it is recommended even though the flag defaults to true.
--authorization-mode=RBAC: Enables anonymous authentication
Why it's wrong here
This is incorrect because `--authorization-mode=RBAC` governs what an already-identified user is allowed to do, not whether unauthenticated users may access the API. Anonymous authentication is a separate authentication-layer control, toggled by the `--anonymous-auth` flag, which defaults to allowed. RBAC alone does not grant or deny anonymous identity; it merely enforces rules on the user or service account that is presented after authentication.
--anonymous-auth=false: Enables RBAC
Why it's wrong here
This is incorrect because `--anonymous-auth=false` only prevents unauthenticated requests from being mapped to the `system:anonymous` user; it does not enable any authorization mechanism. RBAC is a distinct authorization mode that must be explicitly turned on with `--authorization-mode=RBAC`. Even if anonymous access is disabled, the API server will still fall back to its configured authorization mode, which could be `AlwaysAllow` or another mode unless RBAC is separately enabled.
--profiling=false: Enables audit logging
Why it's wrong here
This is incorrect because audit logging is controlled by independent flags such as `--audit-log-path`, `--audit-log-maxage`, and `--audit-policy-file`, which record API requests for security review. The `--profiling` flag exclusively toggles the pprof debugging endpoints and has no effect on audit log creation or configuration. Setting `--profiling=false` only disables information disclosure via profiling; it does not turn on any kind of logging or auditing.
Quick reference
| 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
About these practice questions
Courseiva writes every CKS question from scratch — 845 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 →
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.