mediumMultiple ChoiceObjective-mapped
CKS Practice Question: A security audit reveals that a service account…
A security audit reveals that a service account in the 'default' namespace has been granted cluster-admin privileges via a ClusterRoleBinding. What is the best mitigation?
⚠ Common exam trap
It's easy for candidates to think disabling the token automount or deleting the service account removes the RBAC permissions, but in reality, the ClusterRoleBinding itself must be updated or deleted to actually revoke the granted privileges.
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
✓
Modify the ClusterRoleBinding to use a less privileged role
The best practice is to apply the principle of least privilege: instead of deleting the service account or disabling its token, you should modify the ClusterRoleBinding to bind the service account to a ClusterRole with only the permissions it actually needs. This retains the service account's functionality while removing excessive cluster-admin privileges, which grant unrestricted access to all cluster resources.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Disable the service account token automount
Why it's wrong here
Automounting controls whether the service account token is automatically projected into pods. Disabling automount only prevents new pods from receiving the token automatically, but the ClusterRoleBinding still grants the service account cluster-admin privileges. Pods that explicitly mount the token or already hold it retain full administrative access, so this measure does not reduce the service account's actual permissions.
- ✗
Delete the service account
Why it's wrong here
Deleting the service account removes the Kubernetes identity itself, but the ClusterRoleBinding remains as a binding referencing a non-existent subject. Existing pods with the service account token continue to operate with cluster-admin until restarted, and deleting the account can break workloads that depend on the service account for API authentication or other identity-based functionality. The correct remediation is to remove or reduce the excessive permissions via the binding, not to delete the account.
- ✓
Modify the ClusterRoleBinding to use a less privileged role
Why this is correct
This is the correct mitigation because it directly removes the excessive permissions by changing the subject of the ClusterRoleBinding to a least-privilege ClusterRole or by using namespace-scoped RoleBindings. RBAC decisions are evaluated at request time, so the change takes effect immediately, preserving the service account for legitimate workloads while eliminating its global cluster-admin capabilities.
- ✗
Set --authorization-mode=AlwaysDeny
Why it's wrong here
Setting --authorization-mode=AlwaysDeny would cause the API server to deny every request, breaking the cluster for all users, service accounts, kubelets, and controller managers. This is a global and indiscriminate setting that cannot target a specific service account, and it is not a supported or secure method for limiting privileges. Proper RBAC adjustments are the intended way to restrict a subject's permissions.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 114-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.