CKS Practice Question: Which two of the following are correct ways to…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Set automountServiceAccountToken: false in Pod spec for pods that do not need API access

  Why this is correct

  Setting automountServiceAccountToken: false in the Pod spec prevents the kubelet from mounting the service account token into the container filesystem. This is a critical least-privilege control because many workloads (e.g., batch jobs, worker processes) never interact with the Kubernetes API, and an unneeded token is an attack surface — if the container is compromised, the token can be exfiltrated and used to impersonate the service account. By disabling automount at the Pod level, you ensure that even if a service account has RBAC permissions, those permissions cannot be leveraged from that specific pod. This is the correct approach for pods that do not require API access.

• ✗

  Add multiple ClusterRoleBindings to a single service account to ensure it has access to all resources

  Why it's wrong here

  Adding multiple ClusterRoleBindings to a single service account expands its effective permissions beyond what is necessary, directly violating least privilege. Each ClusterRoleBinding grants a distinct set of RBAC rules cluster-wide, so stringing together several bindings to ‘ensure access to all resources’ creates a superuser-like service account that can read or modify any object. This not only broadens the attack surface but also makes auditing confusing because the effective permissions are the union of all bound roles. Least privilege means granting only the minimum permissions needed for the workload, not aggregating broad access for convenience.

• ✗

  Use the default service account for all workloads

  Why it's wrong here

  Using the default service account for all workloads is dangerous because the default service account in a namespace is automatically mounted with a token and, depending on the cluster configuration, may have additional permissions (e.g., the ability to list secrets or access the Kubernetes API). Default accounts are shared, so any workload that uses them inherits whatever permissions are bound to that account, which are often broader than needed. This practice also removes the ability to audit which workload accessed which resource, as all pods appear as the same identity. For least privilege, you should create a dedicated service account per workload or logical group, with only the RBAC rules that workload requires.

• ✓

  Create a dedicated service account with only the required RBAC permissions

  Why this is correct

  Creating a dedicated service account with only the required RBAC permissions is the embodiment of least privilege in Kubernetes. By defining a ServiceAccount and binding it to a minimal ClusterRole or Role that allows only the specific API operations (e.g., get, list, watch on pods) needed for the workload, you limit the blast radius of a compromised container. A dedicated account also provides clearer audit trails — events and logs show which specific workload acted, rather than a generic default identity. This approach ensures that even if an attacker gains access to a pod’s token, they cannot escalate to other resources outside the scope of that minimal role.

• ✗

  Grant cluster-admin ClusterRole to the service account for simplicity

  Why it's wrong here

  Granting the cluster-admin ClusterRole to a service account gives it unrestricted, cluster-wide superuser permissions, which is the exact opposite of least privilege. The cluster-admin role can perform any action on any resource, including deleting nodes, reading secrets from all namespaces, and modifying RBAC policies. If such a service account is compromised, the attacker effectively owns the entire cluster, allowing lateral movement and data exfiltration across all workloads. Instead, you should bind narrowly scoped roles and use RoleBindings within namespaces where possible; cluster-admin should be reserved only for human cluster administrators, never for application service accounts.

Go deeper

Related to this question