hardMultiple Select
CKS Practice Question: Which THREE of the following are best practices…
Which THREE of the following are best practices for RBAC hardening in Kubernetes? (Select THREE)
⚠ Common exam trap
CNCF often tests the misconception that 'simplicity' (Option B) or 'using the default namespace' (Option D) are acceptable shortcuts, when in fact the CKS exam strictly enforces least privilege and namespace isolation as core hardening principles.
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
✓
Avoid using the cluster-admin ClusterRole for service accounts
The cluster-admin ClusterRole grants unrestricted access to all Kubernetes resources across all namespaces, which violates the principle of least privilege. Service accounts should be assigned only the specific permissions required for their function, not full administrative access. Using cluster-admin for service accounts increases the blast radius of a potential compromise and is a common misconfiguration that the CKS exam penalizes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Avoid using the cluster-admin ClusterRole for service accounts
Why this is correct
Avoid binding service accounts to cluster-admin: that ClusterRole grants wildcard permissions on every resource and subresource across all API groups, including RBAC itself. A service account holding it lets a compromised workload install mutating webhooks, exfiltrate secrets, or delete nodes without any additional authorization. Always bind service accounts to the most narrowly scoped Role or ClusterRole that only permits their required verbs and resources.
- ✗
Grant cluster-admin to all service accounts for simplicity
Why it's wrong here
Granting cluster-admin to all service accounts 'for simplicity' is a critical security failure: it turns every pod into a root-equivalent identity that can alter the cluster API, modify policies, and access all namespaces. This violates the least-privilege principle and makes any single workload compromise a cluster-wide incident. Simplicity in RBAC must never come at the cost of creating a massive, unbounded attack surface.
- ✓
Apply the principle of least privilege when creating Roles and ClusterRoles
Why this is correct
Applying the principle of least privilege when creating Roles and ClusterRoles is mandatory: a Role/RoleBinding is scoped to a single namespace, while a ClusterRole/ClusterRoleBinding applies cluster-wide, so you must pick the narrowest scope for the task. Define only the specific apiGroups, resources, and verbs your workload needs, and avoid wildcards like '*' in verbs or resources. This reduces the blast radius of a credential compromise and ensures that legitimate actions are still possible without overgranting.
- ✗
Use the default namespace for all service accounts
Why it's wrong here
Using the default namespace for all service accounts is not a best practice because it conflates unrelated workloads and violates namespace-based isolation. Service accounts should be created in the same namespace as the pods that use them, so that RoleBindings apply only to that namespace, and audit logs clearly identify which team or application an identity belongs to. The default namespace is often shared by system components and unprivileged workloads, so placing service accounts there makes permission management ambiguous and risky.
- ✓
Regularly audit ClusterRoleBindings for excessive permissions
Why this is correct
Regularly auditing ClusterRoleBindings for excessive permissions is essential because any binding there grants privileges across every namespace, and leaked or stale bindings often go unnoticed. Use commands like `kubectl get clusterrolebindings -o yaml` and review which subjects (users, groups, or service accounts) hold cluster-admin or other powerful roles, then revoke any that no longer need access. This proactive review catches privilege creep, abandoned service accounts, and accidental over-permissions before they are exploited.
Quick reference
AAA Protocol Comparison
| Protocol | Port(s) | Encryption | Transport | Primary Use |
|---|---|---|---|---|
| RADIUS | 1812 / 1813 | Password only | UDP | Network access control |
| TACACS+ | 49 | Full packet | TCP | Device administration |
| Diameter | 3868 | Full session | TCP / SCTP | Carrier / mobile networks |
| 802.1X | — | EAP-based | Layer 2 | Port-based access control |
TACACS+ encrypts the entire packet; RADIUS only encrypts the password field — a key exam distinction.
Go deeper
Related to this question
Learn chapter
RBAC, Service Accounts, and IAM
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.
Key term
Image Scanning
Image scanning is the automated process of inspecting container images for known vulnerabilities, misconfigurations, and malware before they are deployed into production environments.
About these practice questions
One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You are reviewing RBAC permissions and notice a ClusterRoleBinding that binds the cluster-admin role to a service account in the 'monitoring' namespace. What is the best practice recommendation?
medium- A.Keep the binding as it is required for monitoring
- B.Delete the service account
- ✓ C.Replace cluster-admin with a custom Role granting only necessary permissions
- D.Change the binding to a RoleBinding in the monitoring namespace
Why C: The principle of least privilege dictates that a service account should only have the permissions necessary for its function. The cluster-admin role grants superuser access across the entire cluster, which is excessive for a monitoring service account. Replacing it with a custom Role that includes only the required API operations (e.g., get, list, watch on pods and nodes) reduces the attack surface and aligns with Kubernetes security best practices.
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.