CKS Practice Question: Which TWO of the following are recommended…

Answer analysis

Option-by-option breakdown

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

• ✗

  --authorization-mode=AlwaysAllow

  Why it's wrong here

  Setting --authorization-mode=AlwaysAllow tells the API server to grant every authenticated request to any resource without evaluating RBAC policies. This means any user who can authenticate can create pods, escalate privileges, or read secrets, completely bypassing the principle of least privilege. It is the most insecure authorization mode and is only tolerable for trivial non-production test clusters. This flag should never be used in a production or security-conscious environment.

• ✓

  --anonymous-auth=false

  Why this is correct

  Configuring --anonymous-auth=false ensures that requests that do not present valid client certificates, bearer tokens, or other accepted credentials are rejected with an HTTP 401 response before they reach authorization. This eliminates the anonymous user and the system:unauthenticated group from the API server's identity model. Disabling anonymous authentication is a core hardening measure recommended by the CIS Kubernetes Benchmark because it prevents unauthenticated network attackers from even attempting to access the cluster. In combination with RBAC, it enforces that every request is attributable to a real identity.

• ✓

  --authorization-mode=RBAC

  Why this is correct

  Using --authorization-mode=RBAC activates Role-Based Access Control, which lets administrators define fine-grained permissions through Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. RBAC is the recommended and default authorization mode for production Kubernetes because it supports least-privilege access, separates duties, and allows clear auditing of permitted actions. Without RBAC, the API server cannot enforce custom policies, and default deny is impossible to achieve correctly. Enabling RBAC is a necessary foundation for secure cluster operations.

• ✗

  --anonymous-auth=true

  Why it's wrong here

  Leaving --anonymous-auth=true allows any user who can reach the API server to send requests without credentials, and those requests are treated as the 'system:anonymous' user, typically assigned to the system:unauthenticated group. While the default RBAC rules often deny this group many actions, administrators might inadvertently grant permissions to it, or misconfigured bindings could expose sensitive endpoints. Even when no permissions are granted, leaving anonymous access enabled increases attack surface, leaks server metadata, and can lead to information disclosure. For secure clusters, anonymous authentication should be explicitly disabled.

• ✗

  --enable-admission-plugins=AlwaysAdmit

  Why it's wrong here

  --enable-admission-plugins=AlwaysAdmit instructs the API server to accept every request without running any admission controllers, meaning no validation or mutation happens before resources are persisted. This bypasses critical security mechanisms such as PodSecurity (or PodSecurityPolicy), ResourceQuota, LimitRanger, and custom admission webhooks that enforce namespace policies and resource limits. As a result, users could create privileged containers, mount host filesystems, or exhaust cluster resources without any checks. AlwaysAdmit is fundamentally insecure and should be replaced with a tailored set of admission plugins that enforce the cluster's security posture.

Go deeper

Related to this question