hardMultiple Select
CKS Practice Question: Which THREE of the following are recommended…
Which THREE of the following are recommended actions to secure the Kubernetes Dashboard? (Choose three.)
⚠ Common exam trap
CNCF often tests the distinction between actions that are recommended (like using RBAC with minimal permissions) versus actions that are explicitly discouraged (like binding to cluster-admin or exposing via public endpoints), and candidates may mistakenly think enabling HTTPS is a 'recommended action' in this context, but it is not listed among the three correct options here because the question focuses on access control and exposure, not encryption.
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
✓
Use RBAC to create a dedicated service account with minimal permissions
The Kubernetes Dashboard should be accessed using a dedicated service account with minimal permissions via RBAC. This follows the principle of least privilege, ensuring the dashboard only has the permissions necessary for its function, reducing the attack surface. By default, the dashboard's service account has minimal permissions, but binding it to a role with excessive privileges (like cluster-admin) would be a security risk.
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 RBAC to create a dedicated service account with minimal permissions
Why this is correct
Creating a dedicated service account for the Dashboard, rather than relying on the default account, lets you bind only the specific RBAC permissions the Dashboard actually needs, such as read-only access to certain namespaces. This implements least privilege, so even if the Dashboard or its token is compromised, the attacker cannot escalate to broader cluster resources. It also avoids the risk of the default service account carrying excessive or unintended permissions.
- ✗
Expose the Dashboard via an Ingress with a public domain
Why it's wrong here
Exposing the Dashboard through an Ingress with a public domain makes the Kubernetes management interface reachable from the internet, dramatically increasing the attack surface. Attackers can scan for and attempt to exploit any misconfiguration, unpatched vulnerability, or weak authentication in the Dashboard itself. A better approach is to keep the Dashboard cluster-internal and access it via kubectl proxy or an SSH tunnel, which never exposes the service to the network at large.
- ✗
Enable HTTPS for Dashboard communications
Why it's wrong here
Enabling HTTPS for Dashboard communications is standard for any web service and does not represent a specific security hardening measure for the Kubernetes Dashboard; it is simply a baseline assumption for secure traffic. Merely enabling HTTPS does not address the Dashboard's actual security risks, such as unauthorized access, excessive privileges, or exposure to the internet. The official hardening guidance focuses on restricting access and permissions rather than just encrypting the connection.
- ✓
Do not bind the Dashboard's service account to the cluster-admin role
Why this is correct
Binding the Dashboard's service account to the cluster-admin role grants it full control over the entire cluster, including the ability to create, delete, or modify any resource, and to read all secrets. If the Dashboard is compromised, an attacker immediately gains cluster-admin privileges, which can lead to total cluster takeover, data theft, or ransomware. Instead, create a custom role or use a restrictive ClusterRole that only allows the specific actions the Dashboard requires, following the principle of least privilege.
- ✓
Avoid exposing the Dashboard via a public LoadBalancer
Why this is correct
Avoiding a public LoadBalancer for the Dashboard is critical because it exposes the management interface on a public IP address, making it directly accessible from the internet without any additional protection beyond the Dashboard's own authentication. This is especially dangerous because LoadBalancer services typically bypass any network-policy or cluster-level protections that would otherwise restrict traffic. Access should be restricted to internal cluster IPs or via temporary port-forwarding, ensuring the Dashboard is never directly exposed to untrusted networks.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-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 →
Same concept, more angles
1 more way this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which TWO actions would help secure the Kubernetes Dashboard?
medium- ✓ A.Restrict access to the Dashboard using NetworkPolicies or authentication
- ✓ B.Use minimal RBAC permissions for Dashboard service account
- C.Deploy Dashboard in the kube-system namespace
- D.Bind Dashboard service account to cluster-admin
- E.Expose Dashboard via NodePort for easy access
Why A: Kubernetes NetworkPolicies can restrict ingress traffic to the Dashboard pod, ensuring only authorized sources can reach it. Additionally, enabling authentication (e.g., using the built-in token-based login or OIDC) prevents unauthenticated access, which is critical since the Dashboard has powerful cluster management capabilities.
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.