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.

• ✗

  Use HTTP instead of HTTPS for Dashboard traffic

  Why it's wrong here

  HTTP transmits data in plaintext, allowing anyone on the network to intercept sensitive information like bearer tokens or authentication cookies used by the Kubernetes Dashboard. This exposes credentials to man-in-the-middle attacks, potentially granting an attacker the same privileges as the legitimate user. The Dashboard should always be served over TLS (HTTPS) to encrypt traffic in transit and ensure that tokens and API interactions remain confidential. Modern Kubernetes versions enable HTTPS by default, so forcing HTTP would explicitly weaken security.

• ✗

  Disable authentication for the Dashboard

  Why it's wrong here

  Disabling authentication means that anyone who can reach the Dashboard endpoint is automatically granted access, bypassing all identity verification. This effectively makes the Dashboard an unauthenticated API gateway to your cluster, allowing arbitrary users to view secrets, create workloads, or delete resources depending on the service account's permissions. Even if you plan to restrict network access, disabling authentication is a dangerous anti-pattern because it removes the identity layer that audit logging and RBAC depend on. The Dashboard must always require a valid token or kubeconfig to ensure accountability and least privilege.

• ✓

  Restrict Dashboard access using RBAC with minimal privileges

  Why this is correct

  Rather than giving the Dashboard blanket cluster-admin powers, you should create a dedicated service account or user with only the permissions needed to perform the intended monitoring or management tasks. Kubernetes RBAC allows you to bind roles to an identity with specific verbs (get, list, watch) and resources, so you can limit the blast radius if the Dashboard is compromised. For example, you can restrict a user to read-only access in a single namespace by binding a Role to a ServiceAccount and using that token for Dashboard login. This follows the principle of least privilege, ensuring that a leaked token cannot be used to modify cluster-wide state.

• ✗

  Use the default cluster-admin ServiceAccount for Dashboard access

  Why it's wrong here

  The cluster-admin ClusterRole grants superuser permissions over the entire cluster, including the ability to delete nodes, modify RBAC policies, and access secrets in all namespaces. Using the default cluster-admin ServiceAccount for Dashboard login means that any compromised Dashboard session or leaked token leads to immediate, unrestricted cluster takeover. This violates even basic security hygiene because it provides far more access than any human operator or tool typically needs. Instead, you should create a dedicated, minimal privilege identity specifically for Dashboard use.

• ✓

  Avoid exposing the Dashboard on a public IP address

  Why this is correct

  Exposing the Kubernetes Dashboard on a public IP address makes it reachable from the entire internet, dramatically increasing the attack surface for brute-force attempts, token theft, and zero-day vulnerabilities in the dashboard itself. Even with authentication enabled, a public-facing Dashboard invites credential stuffing and exploits that could lead to unauthorized cluster access. It is a best practice to reach the Dashboard through a secure, authenticated proxy like `kubectl proxy`, or to expose it only on a private network with strong network policy restrictions. Alternatively, you can use an SSO-integrated ingress with auth middleware, but direct public exposure is never recommended.

Go deeper

Related to this question