mediumMultiple Choice
CKS Practice Question: A security audit reveals that a service account…
A security audit reveals that a service account 'monitor' is bound to the cluster-admin ClusterRole, which violates least-privilege. What is the best remediation?
⚠ Common exam trap
Many candidates think setting automountServiceAccountToken to false (Option C) is sufficient to revoke permissions, but it only prevents token mounting in pods, not the underlying RBAC permissions that remain active for the service account.
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
✓
Create a new ClusterRoleBinding that binds 'monitor' to a less privileged role (e.g., view) and delete the cluster-admin binding
It directly addresses the violation of least-privilege by replacing the overly permissive cluster-admin ClusterRoleBinding with a binding to a more restrictive role like 'view'. This ensures the 'monitor' service account retains only the necessary read permissions, adhering to the principle of least privilege without disrupting its functionality.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Delete the service account and recreate it without any role binding
Why it's wrong here
Deleting the service account removes the identity that Pods reference via serviceAccountName, so any workload using 'monitor' will fail to authenticate to the Kubernetes API and may crash-loop on startup. Recreating it without role bindings still solves the over-permission problem, but the disruptive deletion is unnecessary when the correct fix is simply to replace the over-privileged ClusterRoleBinding. This approach also ignores the operational cost of updating every Pod manifest that references the old service account.
- ✗
Keep the binding but add a Deny policy for write actions
Why it's wrong here
RBAC in Kubernetes is purely additive and allow-only; there is no native 'Deny' policy object or rule that can subtract permissions from an existing binding. Adding a ClusterRoleBinding for a deny-like role would not revoke the permissions already granted by the cluster-admin binding, because the authorization layer unions all allow rules that match the user. Even a custom webhook or policy engine would be an after-the-fact workaround, whereas the root cause is the excessive binding itself.
- ✗
Set automountServiceAccountToken: false in the pod spec
Why it's wrong here
Setting automountServiceAccountToken: false only prevents the Kubernetes API token from being automatically mounted into the Pod's filesystem; it does not modify the permissions held by the service account 'monitor' in any way. If another workload or a different Pod spec mounts the token explicitly, or if the service account is used by a controller or automation tool outside that Pod, the cluster-admin privileges remain fully available. The secure fix must address the ClusterRoleBinding, not just the token mounting behavior.
- ✓
Create a new ClusterRoleBinding that binds 'monitor' to a less privileged role (e.g., view) and delete the cluster-admin binding
Why this is correct
This is the correct least-privilege remediation because it revokes the unnecessary cluster-admin permissions while preserving the monitoring workload's functional read-only access. Binding 'monitor' to the built-in 'view' ClusterRole gives the service account the ability to inspect most resources, which is the typical need for monitoring, and deleting the old cluster-admin binding ensures the elevated privileges are actually removed. Verifying that no other RoleBinding or ClusterRoleBinding grants cluster-admin to this service account is a prudent follow-up step to confirm the attack surface is eliminated.
Go deeper
Related to this question
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 →
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.