CCNA Cluster Setup and Hardening Questions

75 of 239 questions · Page 3/4 · Cluster Setup and Hardening · Answers revealed

151
MCQmedium

You want to ensure that the Kubernetes Dashboard is accessed only by authenticated users with specific permissions. What is the BEST approach?

A.Expose Dashboard via NodePort and rely on network firewalls
B.Create a ClusterRoleBinding granting cluster-admin to all service accounts
C.Set Dashboard to use HTTP instead of HTTPS
D.Use an ingress with authentication, and create RBAC roles for Dashboard users
AnswerD

This ensures secure access with authentication and least privilege.

Why this answer

Option D is correct because the Kubernetes Dashboard should be secured using an Ingress controller with authentication (e.g., OIDC, basic auth, or client certificate) combined with fine-grained RBAC roles to restrict what each authenticated user can do. This ensures that only authorized users with specific permissions can access the Dashboard, following the principle of least privilege and cluster hardening best practices.

Exam trap

The trap here is that candidates often think network-level controls (NodePort + firewall) are sufficient for securing the Dashboard, but the CKS exam emphasizes that Kubernetes security requires authentication and authorization at the API level, not just network segmentation.

How to eliminate wrong answers

Option A is wrong because exposing the Dashboard via NodePort bypasses authentication and authorization, relying solely on network firewalls which do not provide user-level access control or audit logging. Option B is wrong because granting cluster-admin to all service accounts would give every service account full administrative privileges, violating the principle of least privilege and creating a massive security risk. Option C is wrong because setting the Dashboard to use HTTP instead of HTTPS exposes all traffic in plaintext, allowing man-in-the-middle attacks and credential theft, and does not address authentication or authorization.

152
MCQmedium

A security engineer is configuring a Kubernetes cluster to meet CIS benchmark recommendations. The cluster uses kubeadm for bootstrapping. Which action should be taken to ensure the kube-apiserver is hardened against unauthorized access?

A.Set --insecure-port=8080 on the kube-apiserver
B.Disable the NodeRestriction admission plugin
C.Enable encryption at rest for secrets in etcd
D.Set --anonymous-auth=false on the kube-apiserver
AnswerD

Disables anonymous requests, requiring authentication for all API access.

Why this answer

Option D is correct because setting `--anonymous-auth=false` on the kube-apiserver disables anonymous requests, ensuring that all API requests must be authenticated. This directly addresses CIS benchmark recommendations for hardening the API server against unauthorized access by preventing unauthenticated users from reaching the API.

Exam trap

CNCF often tests the distinction between authentication hardening (anonymous-auth) and authorization or encryption controls, leading candidates to confuse enabling encryption at rest (Option C) with preventing unauthorized API access.

How to eliminate wrong answers

Option A is wrong because setting `--insecure-port=8080` enables an unencrypted, non-authenticated HTTP port, which is a severe security risk and explicitly deprecated in Kubernetes; the CIS benchmark recommends disabling the insecure port entirely. Option B is wrong because disabling the NodeRestriction admission plugin would allow compromised nodes to modify their own Node and Pod objects, reducing security; the CIS benchmark recommends enabling it to enforce node authorization. Option C is wrong because enabling encryption at rest for secrets in etcd protects data confidentiality at the storage layer but does not prevent unauthorized access to the kube-apiserver itself; it addresses a different control (data protection) rather than authentication hardening.

153
Multi-Selecthard

Which THREE of the following are valid methods to secure etcd?

Select 3 answers
A.Use HTTP instead of HTTPS to reduce overhead
B.Encrypt secrets at rest using EncryptionConfiguration
C.Enable RBAC authorization on etcd
D.Open etcd port 2379 to all network interfaces
E.Enable TLS client certificates for authentication
AnswersB, C, E

This encrypts data stored in etcd.

Why this answer

Option B is correct because Kubernetes supports encrypting secrets at rest in etcd via an EncryptionConfiguration object. This configuration specifies which resources (e.g., secrets) should be encrypted and which encryption provider (e.g., AES-CBC, secretbox) to use, ensuring that data stored on disk is protected against unauthorized access to the etcd data directory.

Exam trap

The trap here is that candidates may think HTTP reduces overhead and is acceptable for internal cluster traffic, but the CKS exam strictly requires TLS encryption for all etcd communication, and exposing ports to all interfaces is a clear security violation.

154
MCQeasy

Which of the following is a recommended CIS Benchmark control for etcd?

A.Use HTTP for client communication
B.Enable TLS for etcd peer and client communication
C.Disable audit logging
D.Enable anonymous authentication
AnswerB

TLS encryption for etcd communication is a key recommendation.

Why this answer

The CIS Kubernetes Benchmark recommends enabling TLS for etcd communication to ensure data in transit is encrypted.

155
MCQmedium

An administrator runs 'kubectl get clusterrolebindings' and notices a ClusterRoleBinding named 'admin-binding' that binds the 'cluster-admin' ClusterRole to a service account in the 'default' namespace. What security concern does this raise?

A.The service account can now perform any action across all namespaces, which violates least-privilege.
B.The service account can only access resources in the 'default' namespace.
C.No concern; service accounts are allowed to have cluster-admin.
D.The ClusterRoleBinding should be replaced with a RoleBinding.
AnswerA

cluster-admin grants full cluster-level permissions, which is excessive for most service accounts.

Why this answer

A ClusterRoleBinding grants cluster-wide permissions, and the 'cluster-admin' ClusterRole provides superuser access to perform any action on any resource across all namespaces. Binding this to a service account violates the principle of least privilege because the service account gains unrestricted access to the entire cluster, including sensitive system resources, rather than being limited to only the permissions necessary for its function.

Exam trap

The trap here is that candidates may think a service account bound to a ClusterRole is limited to its namespace, or that 'cluster-admin' is acceptable for any service account, when the CKS exam specifically tests the principle of least privilege and the distinction between RoleBindings (namespace-scoped) and ClusterRoleBindings (cluster-scoped).

How to eliminate wrong answers

Option B is wrong because a ClusterRoleBinding applies cluster-wide, not just to the 'default' namespace; the service account can access resources in all namespaces. Option C is wrong because while service accounts can be bound to cluster-admin, doing so without justification is a significant security concern that violates least-privilege and should be avoided unless absolutely necessary. Option D is wrong because replacing the ClusterRoleBinding with a RoleBinding would limit the binding to a single namespace, but the core issue is the excessive privilege of the 'cluster-admin' ClusterRole, not the binding type; a RoleBinding with 'cluster-admin' is not possible (RoleBindings can only reference ClusterRoles for resources in the same namespace, but 'cluster-admin' still grants cluster-wide scope via a RoleBinding).

156
MCQeasy

What is the purpose of the --audit-policy-file flag on the kube-apiserver?

A.To specify the location of the audit log file
B.To enable audit logging
C.To specify the audit policy configuration
D.To configure the retention of audit logs
AnswerC

The audit policy file defines which API requests are audited and at what level.

Why this answer

The `--audit-policy-file` flag on the kube-apiserver specifies the path to a YAML or JSON file that defines the audit policy configuration. This policy determines which events (e.g., requests to the API server) should be logged and at what level (e.g., Metadata, Request, RequestResponse). It does not directly enable audit logging or set the log file location; it only provides the rules for filtering and structuring audit events.

Exam trap

The trap here is that candidates confuse the `--audit-policy-file` flag with enabling audit logging or setting the log output path, when in fact audit logging is always on and the policy file only filters which events are recorded.

How to eliminate wrong answers

Option A is wrong because the location of the audit log file is specified by the `--audit-log-path` flag, not `--audit-policy-file`. Option B is wrong because audit logging is enabled by default when the kube-apiserver starts; the `--audit-policy-file` flag controls what gets logged, not whether logging is active. Option D is wrong because retention of audit logs (e.g., rotation and max age) is configured via flags like `--audit-log-maxage`, `--audit-log-maxbackup`, and `--audit-log-maxsize`, not the policy file.

157
Multi-Selectmedium

Which TWO resources can be used to implement RBAC in Kubernetes?

Select 2 answers
A.ClusterRole
B.NetworkPolicy
C.PodSecurityPolicy
D.ServiceAccount
E.Role
AnswersA, E

ClusterRole defines cluster-scoped permissions or can be used in namespaces.

Why this answer

A is correct because ClusterRole is a Kubernetes RBAC resource that defines a set of permissions (rules) that are not namespaced, allowing cluster-wide access. RBAC in Kubernetes uses Role and ClusterRole objects to specify allowed verbs (e.g., get, list, create) on resources (e.g., pods, secrets), and they are bound to subjects via RoleBinding or ClusterRoleBinding.

Exam trap

CNCF often tests the distinction between RBAC authorization resources (Role/ClusterRole) and other Kubernetes objects that deal with security but serve different purposes, such as NetworkPolicy (network segmentation) or PodSecurityPolicy (pod security constraints), leading candidates to confuse authorization with other security controls.

158
Multi-Selectmedium

Which TWO of the following are recommended practices for etcd security?

Select 2 answers
A.Use anonymous authentication for etcd
B.Disable TLS for performance
C.Restrict etcd access to only the API server and kubelets using firewall rules
D.Expose etcd on a public IP for monitoring
E.Enable TLS client certificate authentication
AnswersC, E

Network restrictions limit which hosts can connect to etcd.

Why this answer

Option C is correct because etcd stores sensitive cluster data (secrets, config maps, state). Restricting network access to only the API server and kubelets via firewall rules (e.g., iptables or cloud security groups) minimizes the attack surface and prevents unauthorized nodes or external actors from reaching the etcd data store. This aligns with the principle of least privilege for control plane components.

Exam trap

CNCF often tests the misconception that disabling TLS or exposing etcd is acceptable for monitoring or performance, when in reality etcd must always be isolated and encrypted to protect the cluster's root of trust.

159
Multi-Selectmedium

During a security audit, you discover that a container running as root inside a pod has been compromised. The pod uses the default service account. Which two measures should you implement to harden the cluster? (Select TWO)

Select 2 answers
A.Apply a PodSecurityPolicy that restricts containers from running as root.
B.Create a new service account with no roles bound and assign it to the pod.
C.Edit the default service account to set automountServiceAccountToken: false.
D.Set automountServiceAccountToken: false in the pod spec.
E.Add securityContext: runAsNonRoot: true to the pod spec.
AnswersC, E

Prevents automatic mounting of the default SA token in pods that do not specify a service account.

Why this answer

Option C is correct because setting `automountServiceAccountToken: false` on the default service account prevents any pod that uses it from automatically mounting the service account token. This reduces the attack surface: if a container is compromised, the attacker cannot use the token to authenticate to the Kubernetes API server. This is a fundamental hardening measure for service accounts that do not require API access.

Exam trap

CNCF often tests the distinction between disabling token mounting at the service account level versus the pod spec level, and candidates may incorrectly think that creating a new service account with no roles is sufficient, overlooking that the token itself is still mounted and could be used for reconnaissance or privilege escalation even without bound roles.

160
Multi-Selectmedium

Which TWO of the following are recommended CIS Kubernetes Benchmark controls for securing the kube-apiserver?

Select 2 answers
A.Enable insecure port 8080
B.Disable anonymous authentication
C.Set --authorization-mode to AlwaysAllow
D.Enable audit logging
E.Disable TLS
AnswersB, D

Correct. CIS recommends --anonymous-auth=false.

Why this answer

Option B is correct because the CIS Kubernetes Benchmark recommends disabling anonymous authentication to ensure that all requests to the kube-apiserver are authenticated. This prevents unauthenticated users from accessing the API server, which is a critical security control. Option D is correct because enabling audit logging is a recommended control to record all API requests, providing an audit trail for security monitoring and incident response.

Exam trap

CNCF often tests the misconception that disabling anonymous authentication is optional or that audit logging is only for compliance, but both are mandatory for a hardened control plane per the CIS Benchmark.

161
MCQeasy

Which kubectl flag disables anonymous authentication on the API server?

A.--anonymous-enabled=false
B.--no-anonymous
C.--anonymous-auth=false
D.--disable-anonymous
AnswerC

Correct flag to disable anonymous authentication.

Why this answer

Option C is correct because the kube-apiserver uses the `--anonymous-auth` flag to control whether anonymous requests are allowed. Setting `--anonymous-auth=false` disables anonymous authentication, meaning the API server will reject requests that do not present valid credentials. This is a critical hardening step to ensure only authenticated users can access the cluster.

Exam trap

The trap here is that candidates may confuse the `--anonymous-auth` flag with other authentication-related flags or invent plausible-sounding flag names like `--disable-anonymous`, while the actual flag uses the `--<setting>-auth` naming convention with a boolean value.

How to eliminate wrong answers

Option A is wrong because `--anonymous-enabled=false` is not a valid kube-apiserver flag; the correct flag is `--anonymous-auth`. Option B is wrong because `--no-anonymous` is not a recognized flag; the kube-apiserver uses boolean flags like `--anonymous-auth` rather than negated prefixes. Option D is wrong because `--disable-anonymous` is not a valid flag; the API server uses `--anonymous-auth` with a boolean value to control anonymous access.

162
MCQhard

You deploy the Kubernetes Dashboard using the official YAML manifests. Which of the following is the MOST secure approach to expose the Dashboard?

A.Use 'kubectl proxy' to access it locally
B.Create a NodePort Service to expose it on a port
C.Expose it with a LoadBalancer Service
D.Use an Ingress with a public DNS
AnswerA

This method uses your existing kubectl authentication and does not expose the Dashboard to the network.

Why this answer

The most secure approach is to use 'kubectl proxy' because it creates a local HTTP proxy between your workstation and the Kubernetes API server, authenticating your requests using your kubeconfig credentials. This ensures the Dashboard is never exposed to the network, eliminating any attack surface from external or internal cluster access. All traffic is tunneled through the API server, which enforces RBAC and audit logging.

Exam trap

CNCF often tests the misconception that exposing the Dashboard via a Service (NodePort, LoadBalancer, or Ingress) is acceptable if TLS is enabled, but the trap is that any network exposure increases the attack surface and violates the principle of least privilege, whereas 'kubectl proxy' provides no network exposure at all.

How to eliminate wrong answers

Option B is wrong because a NodePort Service exposes the Dashboard on a static port on every node's IP address, making it accessible from within the cluster network and potentially from outside if network policies are misconfigured, violating the principle of least exposure. Option C is wrong because a LoadBalancer Service provisions a public-facing cloud load balancer, directly exposing the Dashboard to the internet or broader network, which is unnecessary and increases the attack surface significantly. Option D is wrong because using an Ingress with a public DNS exposes the Dashboard via a hostname, often terminating TLS at the ingress controller, but still making the service reachable from outside the cluster and requiring additional security controls like authentication and network policies that are easy to misconfigure.

163
Drag & Dropmedium

Order the steps to perform a Kubernetes cluster upgrade from version 1.24 to 1.25.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

Upgrade involves upgrading kubeadm, draining, applying upgrade, upgrading worker nodes, and verifying.

164
MCQmedium

You are configuring etcd encryption at rest. After placing the EncryptionConfiguration YAML file, you must modify which file to point the API server to it?

A./etc/kubernetes/manifests/kube-apiserver.yaml
B./etc/kubernetes/admin.conf
C./etc/kubernetes/pki/etcd/ca.crt
D./etc/kubernetes/kubelet.conf
AnswerA

Correct file to modify for API server flags.

Why this answer

Option A is correct because the API server is deployed as a static pod in a typical Kubernetes cluster, with its manifest located at /etc/kubernetes/manifests/kube-apiserver.yaml. To enable encryption at rest, you must add the `--encryption-provider-config` flag to this manifest, pointing to the EncryptionConfiguration YAML file. The kubelet automatically detects the change and restarts the API server pod to apply the new encryption configuration.

Exam trap

CNCF often tests the distinction between static pod manifests and kubeconfig files; the trap here is that candidates may confuse /etc/kubernetes/admin.conf or /etc/kubernetes/kubelet.conf with the API server's configuration, thinking they need to modify a kubeconfig file instead of the static pod manifest.

How to eliminate wrong answers

Option B is wrong because /etc/kubernetes/admin.conf is the kubeconfig file used by kubectl and administrators for cluster authentication and authorization, not a configuration file for the API server itself. Option C is wrong because /etc/kubernetes/pki/etcd/ca.crt is the CA certificate for etcd, used for TLS communication between etcd members and clients; it has no role in configuring API server encryption at rest. Option D is wrong because /etc/kubernetes/kubelet.conf is the kubeconfig file for the kubelet to authenticate to the API server, not a file that controls API server encryption settings.

165
MCQmedium

Which admission plugin should be enabled on the kube-apiserver to restrict kubelet permissions and prevent nodes from modifying their own Node objects?

A.ServiceAccount
B.AlwaysPullImages
C.NodeRestriction
D.PodSecurityPolicy
AnswerC

The NodeRestriction admission plugin limits the kubelet to only modify its own Node object and pods bound to it.

Why this answer

The NodeRestriction admission plugin limits the kubelet's permissions to only modify labels, annotations, and status on its own Node object, preventing a compromised or misconfigured node from altering other Node objects or escalating privileges. This is a critical hardening measure for cluster setup, as it enforces the principle of least privilege on kubelet API access.

Exam trap

The trap here is that candidates often confuse admission plugins that restrict pod behavior (like PodSecurityPolicy or AlwaysPullImages) with those that restrict node/kubelet behavior, leading them to pick a security-focused but irrelevant option for this specific kubelet permission control question.

How to eliminate wrong answers

Option A (ServiceAccount) is wrong because it automates the creation of service account tokens and mounts them into pods, but it does not restrict kubelet permissions or prevent node object modifications. Option B (AlwaysPullImages) is wrong because it forces every pod to pull images from the registry on each start, which addresses image freshness and security but has no effect on kubelet authorization or node object mutations. Option D (PodSecurityPolicy) is wrong because it enforces security constraints on pod specifications (e.g., privileged containers, host namespaces) but does not control kubelet-level access to the Node API; it was also deprecated in Kubernetes v1.21 and removed in v1.25.

166
MCQeasy

Which flag on the kubelet helps ensure it runs securely by enforcing kernel defaults?

A.--read-only-port=0
B.--security-context
C.--protect-kernel-defaults
D.--kernel-security
AnswerC

The --protect-kernel-defaults flag ensures the kubelet enforces kernel security settings.

Why this answer

The `--protect-kernel-defaults` flag on the kubelet ensures that the node's kernel parameters are set to secure defaults, preventing container escapes or privilege escalations that could exploit weak kernel settings. This flag enforces the kubelet's built-in kernel validator, which checks that critical sysctls (e.g., `net.ipv4.ip_forward`, `kernel.panic`) are set to safe values, and fails to start if they are not. It is a key hardening measure for cluster nodes, directly addressing kernel-level security.

Exam trap

CNCF often tests the distinction between kubelet flags that control network ports (like `--read-only-port`) and those that enforce kernel-level security, leading candidates to confuse `--protect-kernel-defaults` with non-existent or unrelated flags such as `--kernel-security` or `--security-context`.

How to eliminate wrong answers

Option A is wrong because `--read-only-port=0` disables the read-only port (10255) on the kubelet, which prevents unauthenticated access to node metrics, but it does not enforce kernel defaults. Option B is wrong because `--security-context` is not a valid kubelet flag; security contexts are configured at the Pod or container level via the Kubernetes API, not on the kubelet itself. Option D is wrong because `--kernel-security` is not a recognized kubelet flag; the correct flag for enforcing kernel defaults is `--protect-kernel-defaults`.

167
MCQeasy

Which RBAC resource should be used to grant cluster-wide permissions to a user?

A.Role
B.RoleBinding
C.ClusterRole
D.ClusterRoleBinding
AnswerD

ClusterRoleBinding grants ClusterRole permissions cluster-wide.

Why this answer

ClusterRoleBinding is the correct resource because it binds a ClusterRole (which defines cluster-wide permissions) to a user, granting permissions across all namespaces. A ClusterRole itself only defines the rules; the binding is what actually grants those permissions to a specific subject. Therefore, to grant cluster-wide permissions to a user, you need a ClusterRoleBinding referencing a ClusterRole.

Exam trap

The trap here is that candidates often confuse a ClusterRole (which only defines rules) with a ClusterRoleBinding (which actually grants those rules to a subject), leading them to select Option C instead of D.

How to eliminate wrong answers

Option A is wrong because a Role is namespaced and can only grant permissions within a single namespace, not cluster-wide. Option B is wrong because a RoleBinding binds a Role (or ClusterRole) to a user but only within a specific namespace, so it cannot grant cluster-wide permissions. Option C is wrong because a ClusterRole only defines the set of permissions (rules) but does not grant them to any user; a binding is required to actually assign those permissions.

168
MCQhard

A cluster administrator wants to ensure that a specific service account (my-sa) cannot have its token mounted automatically in pods. Which annotation should be set on the service account?

A.automountServiceAccountToken: "false"
B.automountServiceAccountToken: false
C.mount-token: "false"
D.kubernetes.io/enforce-mountable-secrets: "true"
AnswerD

This annotation on a service account prevents automatic mounting of its token in pods.

Why this answer

Option D is correct because the annotation `kubernetes.io/enforce-mountable-secrets: "true"` on a service account prevents pods that use that service account from automatically mounting its token. This annotation enforces that the token is only mounted if explicitly requested via `automountServiceAccountToken: true` in the pod spec or service account. It is a Kubernetes-specific annotation that directly controls token mounting behavior at the service account level.

Exam trap

CNCF often tests the distinction between annotations and spec fields, so the trap here is that candidates confuse the `automountServiceAccountToken` field (which can be set in the service account spec) with an annotation, leading them to pick option A or B instead of the correct annotation-based solution.

How to eliminate wrong answers

Option A is wrong because `automountServiceAccountToken: "false"` is not a valid annotation; it is a field in the pod spec or service account spec, not an annotation. Option B is wrong because `automountServiceAccountToken: false` is a field (not an annotation) that can be set in the service account spec to disable automatic token mounting, but the question explicitly asks for an annotation. Option C is wrong because `mount-token: "false"` is not a recognized Kubernetes annotation or field; it is a fabricated key that does not exist in the Kubernetes API.

169
MCQhard

A ClusterRoleBinding named 'admin-binding' binds the cluster-admin ClusterRole to a service account 'sa-admin' in namespace 'ns1'. What is the security concern?

A.The service account 'sa-admin' can access resources in all namespaces
B.ClusterRoleBinding should be replaced by RoleBinding for cluster-scoped resources
C.The service account token is automatically mounted
D.ClusterRoleBinding should not be used for service accounts
AnswerA

cluster-admin grants unrestricted access across the entire cluster.

Why this answer

A ClusterRoleBinding grants permissions cluster-wide, meaning the service account 'sa-admin' in namespace 'ns1' can access resources in all namespaces, not just its own. This violates the principle of least privilege by providing excessive access beyond the intended scope.

Exam trap

The trap here is that candidates may overlook that a ClusterRoleBinding grants permissions across all namespaces, focusing instead on the service account's namespace or token mounting, rather than the scope of the binding.

How to eliminate wrong answers

Option B is wrong because ClusterRoleBinding is specifically designed for cluster-scoped resources, not RoleBinding; RoleBinding is for namespace-scoped resources. Option C is wrong because automatic token mounting is a separate concern about pod security, not a direct security issue of the binding itself. Option D is wrong because ClusterRoleBinding can and should be used for service accounts when cluster-wide access is required, but the concern here is the unnecessary scope of access.

170
Multi-Selectmedium

Which TWO kubelet flags are recommended by the CIS Kubernetes Benchmark to enhance security? (Select TWO)

Select 2 answers
A.--anonymous-auth=false
B.--authentication-token-webhook=false
C.--read-only-port=10255
D.--protect-kernel-defaults=true
E.--authorization-mode=AlwaysAllow
AnswersA, D

Disables anonymous access to the kubelet.

Why this answer

Option A is correct because setting --anonymous-auth=false disables anonymous requests to the kubelet API, which is a CIS Benchmark recommendation to prevent unauthenticated access. Option D is correct because --protect-kernel-defaults=true ensures the kubelet checks and enforces kernel hardening parameters (e.g., sysctl settings) at startup, reducing the attack surface.

Exam trap

CNCF often tests the distinction between authentication and authorization flags, tricking candidates into thinking that disabling webhook authentication (--authentication-token-webhook=false) is secure, when in fact it removes a key validation layer.

171
MCQhard

An administrator wants to enable encryption at rest for secrets in a Kubernetes cluster. They create the following EncryptionConfiguration and place it at /etc/kubernetes/enc/enc.yaml. Which flag must be added to the kube-apiserver to use this configuration?

A.--feature-gates=EncryptionAtRest=true
B.--enable-encryption
C.--encryption-config=/etc/kubernetes/enc/enc.yaml
D.--encryption-provider-config=/etc/kubernetes/enc/enc.yaml
AnswerD

This is the correct flag to enable encryption at rest.

Why this answer

Option D is correct because the kube-apiserver requires the `--encryption-provider-config` flag to specify the path to the EncryptionConfiguration YAML file. This flag tells the API server which encryption providers (e.g., `aescbc`, `secretbox`) to use for encrypting secrets at rest in etcd. Without this flag, the EncryptionConfiguration file is ignored and secrets remain unencrypted.

Exam trap

The trap here is that candidates may confuse the flag name `--encryption-provider-config` with the similar-sounding but incorrect `--encryption-config`, or assume a feature gate or generic enable flag is sufficient without providing the configuration file path.

How to eliminate wrong answers

Option A is wrong because `--feature-gates=EncryptionAtRest=true` is not a valid flag; encryption at rest is enabled via the `--encryption-provider-config` flag, not a feature gate. Option B is wrong because `--enable-encryption` does not exist as a kube-apiserver flag; the correct flag requires specifying the configuration file path. Option C is wrong because `--encryption-config` is not a recognized flag; the correct flag name is `--encryption-provider-config`.

172
Multi-Selectmedium

Which TWO actions would help secure the Kubernetes Dashboard?

Select 2 answers
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
AnswersA, B

Network policies and strong authentication help secure the Dashboard.

Why this answer

Option A is correct because 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.

Exam trap

CNCF often tests the misconception that placing a component in the kube-system namespace or using NodePort is acceptable for 'convenience,' but the CKS exam emphasizes that security controls like NetworkPolicies and minimal RBAC are mandatory, not optional.

173
Multi-Selecthard

Which THREE of the following are valid encryption providers that can be used in EncryptionConfiguration for encryption at rest?

Select 3 answers
A.aescbc
B.kms
C.aesgcm
D.rsa
E.secretbox
AnswersA, B, E

AES-CBC is a valid encryption provider.

Why this answer

Option A (aescbc) is correct because AES-CBC is a symmetric encryption algorithm that Kubernetes supports natively in EncryptionConfiguration for encrypting Secrets at rest. It uses a 32-byte key for AES-256 encryption and is the most commonly used provider for this purpose.

Exam trap

CNCF often tests that candidates confuse AES-GCM (which is not supported) with AES-CBC (which is supported), or assume RSA (asymmetric) can be used for at-rest encryption when Kubernetes only supports symmetric or KMS-based providers.

174
MCQeasy

Which admission plugin should be enabled to prevent kubelets from modifying nodes or pods they do not own?

A.AlwaysPullImages
B.PodSecurity
C.NodeRestriction
D.ServiceAccount
AnswerC

This plugin restricts kubelet permissions to only objects on its node.

Why this answer

The NodeRestriction admission plugin ensures that kubelets can only modify the Node and Pod objects they are assigned to. It enforces that a kubelet with a specific node identity can only label, taint, or update its own Node object and can only create/modify Pods that are bound to that node. This prevents a compromised or misconfigured kubelet from tampering with other nodes or pods in the cluster.

Exam trap

CNCF often tests the NodeRestriction plugin by pairing it with other admission controllers like AlwaysPullImages or PodSecurity, leading candidates to confuse security-focused plugins with node-level access control.

How to eliminate wrong answers

Option A is wrong because AlwaysPullImages forces every Pod to pull its image from the registry each time it starts, which addresses image freshness and prevents use of cached images, but does not restrict kubelet modifications to nodes or pods. Option B is wrong because PodSecurity (formerly PodSecurityPolicy) enforces security contexts and pod-level controls, but does not limit kubelet actions on node or pod objects. Option D is wrong because ServiceAccount controls how pods authenticate to the API server, but does not restrict a kubelet's ability to modify nodes or pods it does not own.

175
MCQmedium

An administrator runs `kube-bench` on a Kubernetes node and receives a warning that the kubelet is configured with `--anonymous-auth=true`. Which kubectl command should be used to fix this on the kubelet?

A.kubectl annotate node --all kubelet.kubernetes.io/anonymous-auth=false
B.kubectl edit node <node-name> and set spec.anonymousAuth to false
C.kubectl set env daemonset/kubelet -n kube-system ANONYMOUS_AUTH=false
D.kubectl edit configmap kubelet-config -n kube-system and set authentication.anonymous.enabled to false
AnswerD

The kubelet configuration is often stored in a ConfigMap. Editing it allows changing the anonymous auth setting.

Why this answer

Option D is correct because the kubelet's anonymous authentication is configured via a KubeletConfiguration object, which is typically stored as a ConfigMap in the kube-system namespace. Editing the `kubelet-config` ConfigMap and setting `authentication.anonymous.enabled` to false is the proper kubectl-based method to disable anonymous authentication for the kubelet, as the kubelet reads its configuration from this ConfigMap when the `--config` flag is used.

Exam trap

The trap here is that candidates confuse the kubelet's configuration mechanism with other Kubernetes resources, assuming it can be patched via Node objects or DaemonSets, when in reality it requires modifying the KubeletConfiguration object (often a ConfigMap) and restarting the kubelet.

How to eliminate wrong answers

Option A is wrong because `kubectl annotate` does not affect kubelet authentication settings; annotations are metadata and have no effect on kubelet configuration. Option B is wrong because Node objects do not have a `spec.anonymousAuth` field; kubelet authentication is not configured through the Node API resource. Option C is wrong because the kubelet is not deployed as a DaemonSet; it runs as a static pod or systemd service, and `kubectl set env` cannot modify its configuration.

176
MCQmedium

Which admission plugin should be enabled to ensure that kubelet only serves pods bound to its node and prevents unauthorized node access?

A.NodeRestriction
B.AlwaysPullImages
C.NodeAffinity
D.PodSecurityPolicy
AnswerA

This plugin restricts kubelet permissions to pods on its own node.

Why this answer

The NodeRestriction admission plugin ensures that the kubelet only serves pods bound to its node by limiting the kubelet's ability to modify labels and taints on its own Node object, and by preventing the kubelet from modifying pods not scheduled to its node. This plugin is a key security control to prevent unauthorized node access and enforce the principle of least privilege for kubelet operations.

Exam trap

CNCF often tests the distinction between admission plugins that control pod-level security (like PodSecurityPolicy) versus those that control node-level authorization (like NodeRestriction), leading candidates to confuse PodSecurityPolicy as the answer for node access control.

How to eliminate wrong answers

Option B (AlwaysPullImages) is wrong because it forces image pull policy to Always for every pod, which prevents use of locally cached images but does not restrict kubelet node access or pod binding. Option C (NodeAffinity) is wrong because it is a scheduling constraint (expressed via nodeSelector or affinity rules) that influences pod placement, not an admission plugin that restricts kubelet behavior after scheduling. Option D (PodSecurityPolicy) is wrong because it enforces security context constraints on pods (e.g., privileged containers, host namespaces) and does not control kubelet node-level access or pod binding.

177
MCQeasy

Which of the following is a CIS benchmark recommendation for securing the Kubernetes API server?

A.Disable audit logging to reduce overhead
B.Enable anonymous authentication
C.Use RBAC for authorization
D.Allow all service accounts to use cluster-admin
AnswerC

The CIS benchmark recommends using RBAC as the authorization mode to enforce least-privilege access.

Why this answer

C is correct because the CIS Benchmark for Kubernetes recommends using Role-Based Access Control (RBAC) to authorize API requests, ensuring that users and service accounts have only the minimum necessary permissions. RBAC is a core security control that restricts access based on roles, and its use is explicitly required to meet CIS compliance for the API server.

Exam trap

The trap here is that candidates may think disabling audit logging reduces performance overhead and is a valid optimization, but the CIS benchmark explicitly requires audit logging to be enabled for security compliance.

How to eliminate wrong answers

Option A is wrong because disabling audit logging violates the CIS benchmark recommendation to enable audit logging for security monitoring and forensics; audit logs are critical for detecting and investigating suspicious activity. Option B is wrong because enabling anonymous authentication is explicitly discouraged by the CIS benchmark, as it allows unauthenticated requests to the API server, bypassing identity verification. Option D is wrong because allowing all service accounts to use cluster-admin grants unrestricted cluster-wide privileges, which directly contradicts the principle of least privilege and the CIS recommendation to restrict cluster-admin access.

178
MCQhard

A cluster's API server is configured with --authorization-mode=RBAC,Node. A kubelet attempts to create a ConfigMap. Which authorizer will evaluate the request?

A.Only the RBAC authorizer
B.Neither; the request is denied because Node authorizer does not allow ConfigMap creation
C.Both Node and RBAC authorizers, with Node first
D.Only the Node authorizer
AnswerC

The chain runs Node first; if Node permits, RBAC may not be needed. If Node denies, RBAC grants if permitted by RoleBindings.

Why this answer

When the API server is started with `--authorization-mode=RBAC,Node`, the request is evaluated by each authorizer in the order they are listed. The Node authorizer is designed to authorize kubelet requests, but it only permits specific node-related operations (e.g., reading secrets, creating pods, reporting node status). Creating a ConfigMap is not within the Node authorizer's allowed actions, so it will deny the request.

The request then passes to the RBAC authorizer, which will evaluate it based on the kubelet's RBAC bindings. Therefore, both authorizers are consulted, with Node first.

Exam trap

The trap here is that candidates assume the Node authorizer will automatically allow all kubelet requests, but in reality it only permits a restricted set of node-specific operations, and any request not matching those patterns is passed to the next authorizer in the chain.

How to eliminate wrong answers

Option A is wrong because the Node authorizer is listed before RBAC and will evaluate the request first; it does not skip the Node authorizer. Option B is wrong because the request is not denied outright; if the Node authorizer denies it, the RBAC authorizer still has a chance to allow it. Option D is wrong because the RBAC authorizer is also in the chain and will evaluate the request after the Node authorizer denies it.

179
MCQmedium

Which of the following YAML snippets correctly configures a ServiceAccount with automountServiceAccountToken set to false?

A.apiVersion: v1 kind: ServiceAccount metadata: name: my-sa token: automount: false
B.apiVersion: v1 kind: ServiceAccount metadata: name: my-sa automountServiceAccountToken: false
C.apiVersion: v1 kind: Pod metadata: name: my-pod spec: serviceAccountName: my-sa automountServiceAccountToken: false
D.apiVersion: v1 kind: ServiceAccount metadata: name: my-sa automountServiceAccountToken: false
AnswerB

This is the correct syntax to disable automounting of the service account token for pods using this service account.

Why this answer

Option B is correct because it uses the correct field name `automountServiceAccountToken` at the top level of the ServiceAccount spec, which is the proper way to disable automatic mounting of the service account token in pods that use this ServiceAccount. This setting prevents the Kubernetes API token from being automatically injected into pods, enhancing security by reducing the attack surface for token theft.

Exam trap

CNCF often tests the distinction between setting `automountServiceAccountToken` on a ServiceAccount versus on a Pod, and the trap here is that candidates may confuse the correct placement (top-level spec vs. metadata) or think that setting it on a Pod is equivalent to configuring the ServiceAccount itself.

How to eliminate wrong answers

Option A is wrong because it uses a non-existent field `token` with a subfield `automount`, which is not a valid Kubernetes API structure for a ServiceAccount. Option C is wrong because it configures `automountServiceAccountToken` on a Pod spec, which is valid for disabling token mounting for that specific pod, but the question asks for a ServiceAccount configuration, not a Pod configuration. Option D is wrong because `automountServiceAccountToken` is placed under `metadata`, which is incorrect; it must be at the top level of the ServiceAccount spec, not nested under metadata.

180
MCQmedium

Which flag must be set on the kubelet to prevent it from using the default namespace for pods and to enforce that pods only use namespaces that match the node's assigned namespace?

A.--protect-kernel-defaults=true
B.--namespace-default=restricted
C.--authentication-token-webhook=true
D.--anonymous-auth=false
AnswerD

This flag disables anonymous access, but the question asks about namespace enforcement. Actually, the correct answer for namespace enforcement is not listed; the stem may be misleading. However, in the context of kubelet security, --anonymous-auth=false is a key CIS recommendation. For namespace enforcement, the NodeRestriction admission plugin is used. Given the options, B is the most relevant kubelet flag.

Why this answer

Option D is correct because setting `--anonymous-auth=false` on the kubelet prevents unauthenticated (anonymous) requests from being accepted. This forces all requests to the kubelet to be authenticated, and when combined with the `--authentication-token-webhook=true` flag (which is not the answer here), the kubelet can verify that the pod's service account token belongs to a namespace that matches the node's assigned namespace. Without this flag, anonymous users could bypass namespace enforcement and access pods in the default namespace.

Exam trap

CNCF often tests the misconception that `--authentication-token-webhook=true` alone enforces namespace restrictions, but the trap is that without disabling anonymous auth, unauthenticated requests can still bypass token validation entirely.

How to eliminate wrong answers

Option A is wrong because `--protect-kernel-defaults=true` is a security flag that ensures the kubelet does not modify kernel parameters (like sysctl settings) that could affect the host, but it has nothing to do with namespace enforcement or preventing the use of the default namespace. Option B is wrong because `--namespace-default=restricted` is not a valid kubelet flag; the kubelet does not have a flag to set a default namespace for pods, and namespace enforcement is handled via authentication and authorization, not a default namespace setting. Option C is wrong because `--authentication-token-webhook=true` enables the kubelet to use the Kubernetes API server's TokenReview API to validate bearer tokens (e.g., service account tokens), but by itself it does not prevent anonymous access or enforce namespace matching; it must be combined with `--anonymous-auth=false` to block unauthenticated requests.

181
MCQmedium

You need to enable encryption at rest for secrets in an existing cluster. Which resource should you create?

A.ConfigMap
B.EncryptionConfiguration
C.Secret
D.CustomResourceDefinition
AnswerB

EncryptionConfiguration is the custom resource used to configure encryption at rest for Kubernetes secrets and other resources.

Why this answer

To enable encryption at rest for Kubernetes secrets, you must create an EncryptionConfiguration resource. This object defines which encryption providers (e.g., AES-CBC, KMS, or secretbox) should be used to encrypt secrets stored in etcd. Once defined, you must pass the EncryptionConfiguration file to the kube-apiserver via the `--encryption-provider-config` flag and restart the API server for the encryption to take effect.

Exam trap

CNCF often tests the misconception that creating a Secret resource itself enables encryption at rest, when in fact you must explicitly configure the EncryptionConfiguration and restart the API server to protect secrets stored in etcd.

How to eliminate wrong answers

Option A is wrong because a ConfigMap is used to store non-confidential configuration data as key-value pairs and does not provide encryption capabilities for secrets at rest. Option C is wrong because a Secret is the resource that stores sensitive data, but it is not the resource that configures encryption at rest; you need an EncryptionConfiguration to define how secrets are encrypted in etcd. Option D is wrong because a CustomResourceDefinition (CRD) extends the Kubernetes API with custom resources and has no role in enabling encryption at rest for existing built-in resources like secrets.

182
MCQmedium

A service account 'monitor' needs to list pods in all namespaces. Which minimal RBAC configuration should you use?

A.ClusterRole with get pods, then ClusterRoleBinding
B.Role with get pods in kube-system, then RoleBinding
C.ClusterRole with get pods, then RoleBinding in default namespace
D.Role in each namespace with get pods, then RoleBinding
AnswerA

This grants the permission across all namespaces.

Why this answer

Option A is correct because a ClusterRole with 'get pods' permission grants access to pods across all namespaces, and a ClusterRoleBinding binds that ClusterRole to the 'monitor' service account cluster-wide. This is the minimal RBAC configuration for listing pods in all namespaces, as a Role and RoleBinding are namespace-scoped and cannot grant cross-namespace access.

Exam trap

The trap here is that candidates often confuse RoleBinding with ClusterRoleBinding, thinking a ClusterRole can be bound to a namespace via a RoleBinding to grant cluster-wide access, but RoleBinding only applies the permissions within that specific namespace.

How to eliminate wrong answers

Option B is wrong because a Role in kube-system with a RoleBinding only grants access to pods in the kube-system namespace, not all namespaces. Option C is wrong because a RoleBinding in the default namespace binds the ClusterRole only to that namespace, not cluster-wide, so the service account cannot list pods in other namespaces. Option D is wrong because creating a Role in each namespace with a RoleBinding is not minimal—it requires manual duplication and maintenance across all namespaces, whereas a single ClusterRoleBinding achieves the same goal more efficiently.

183
MCQmedium

A security audit reveals that etcd does not encrypt data at rest. Which resource must be created to enable encryption?

A.Secret with encryption key
B.Deployment for etcd with encryption flag
C.ConfigMap with encryption key
D.EncryptionConfiguration YAML file and pass it to the API server via --encryption-provider-config
AnswerD

The EncryptionConfiguration resource defines the encryption configuration.

Why this answer

Option D is correct because Kubernetes enables etcd data-at-rest encryption through an EncryptionConfiguration YAML file, which defines how to encrypt resources at the API server level. This file is passed to the kube-apiserver via the `--encryption-provider-config` flag, allowing providers like `aescbc` or `secretbox` to encrypt etcd data transparently.

Exam trap

The trap here is that candidates often confuse etcd encryption with TLS or secret management, assuming a Secret or ConfigMap alone enables encryption, when in fact the EncryptionConfiguration YAML is the mandatory resource that the API server reads to apply encryption at rest.

How to eliminate wrong answers

Option A is wrong because a Secret with an encryption key is not a resource that Kubernetes directly consumes for etcd encryption; the key must be referenced within an EncryptionConfiguration. Option B is wrong because etcd does not have a deployment or encryption flag in Kubernetes; encryption is configured on the API server, not etcd itself. Option C is wrong because a ConfigMap is not used for encryption keys; the EncryptionConfiguration is a dedicated YAML resource, and keys are typically stored in Secrets or files, not ConfigMaps.

184
MCQmedium

You need to enable audit logging for the Kubernetes API server. Which three flags must be set?

A.--audit-log-path, --audit-policy-file, --audit-log-maxage
B.--audit-log-path, --audit-log-format, --audit-log-maxsize
C.--audit-log-path, --audit-log-maxage, --audit-log-maxsize
D.--audit-policy-file, --audit-log-maxage, --audit-log-maxbackup
AnswerA

These three flags enable audit logging, define the policy, and set log retention.

Why this answer

To enable audit logging in the Kubernetes API server, you must specify the path for the audit log file (`--audit-log-path`), the path to the audit policy file that defines which events to log (`--audit-policy-file`), and the maximum number of days to retain old audit log files (`--audit-log-maxage`). These three flags are the minimum required to activate and control basic audit logging, as the API server will not generate audit logs without a policy file and a log destination.

Exam trap

The trap here is that candidates assume `--audit-log-maxsize` or `--audit-log-maxbackup` are mandatory for rotation, but the CKS exam tests that `--audit-log-maxage` is the only rotation flag required alongside the path and policy file to enable basic audit logging.

How to eliminate wrong answers

Option B is wrong because `--audit-log-format` is optional (defaults to JSON) and not required to enable audit logging; the core requirement is the policy file and log path. Option C is wrong because it omits the mandatory `--audit-policy-file`, without which the API server will not apply any audit rules and will not log events. Option D is wrong because it lacks `--audit-log-path`, which is essential to specify where the log file is written; without it, no audit log file is created.

185
Multi-Selecteasy

Which TWO of the following are recommended settings for the Kubernetes API server according to the CIS Kubernetes Benchmark? (Select TWO)

Select 2 answers
A.--authorization-mode=AlwaysAllow
B.--anonymous-auth=false
C.--authorization-mode=RBAC
D.--anonymous-auth=true
E.--enable-admission-plugins=AlwaysAdmit
AnswersB, C

Disables anonymous requests to the API server.

Why this answer

Option B is correct because the CIS Kubernetes Benchmark recommends disabling anonymous authentication by setting `--anonymous-auth=false` on the API server. This ensures that all requests must be authenticated, preventing unauthenticated access to the cluster's control plane.

Exam trap

CNCF often tests the distinction between authentication and authorization, so candidates may incorrectly think disabling anonymous auth is unnecessary if RBAC is enabled, but anonymous users can still bypass RBAC if anonymous auth is left on.

186
MCQhard

A ClusterRole named 'secret-reader' is defined with rules to get, list, and watch secrets. A RoleBinding in namespace 'app' binds this ClusterRole to a service account. Which of the following best describes the permissions of the service account?

A.The service account has no permissions because ClusterRole cannot be used with RoleBinding.
B.The service account can only get secrets in the 'app' namespace.
C.The service account can get, list, and watch secrets in all namespaces.
D.The service account can get, list, and watch secrets only in the 'app' namespace.
AnswerD

RoleBinding grants permissions only in its namespace.

Why this answer

A RoleBinding in a specific namespace grants the permissions defined in the referenced ClusterRole, but only within that namespace. Since the RoleBinding is in the 'app' namespace, the service account receives the get, list, and watch permissions for secrets only within the 'app' namespace, not cluster-wide. This is the standard behavior of RoleBinding when binding to a ClusterRole.

Exam trap

The trap here is that candidates often confuse RoleBinding with ClusterRoleBinding, assuming that using a ClusterRole automatically grants cluster-wide permissions, when in fact the binding type determines the scope.

How to eliminate wrong answers

Option A is wrong because a ClusterRole can be used with a RoleBinding; the RoleBinding scopes the ClusterRole's permissions to the RoleBinding's namespace. Option B is wrong because the ClusterRole grants get, list, and watch permissions, not just get. Option C is wrong because a RoleBinding does not grant cluster-wide permissions; only a ClusterRoleBinding would grant permissions across all namespaces.

187
Multi-Selectmedium

Which TWO actions are part of the CIS Kubernetes Benchmark recommendations?

Select 2 answers
A.Enable audit logging on the API server
B.Allow all service accounts to list secrets
C.Expose the API server on port 8080
D.Disable anonymous authentication on the API server
E.Use HTTP for kubelet communication
AnswersA, D

Audit logging is recommended for security monitoring.

Why this answer

Option A is correct because the CIS Kubernetes Benchmark recommends enabling audit logging on the API server to record all requests and responses, which is essential for security monitoring, forensics, and compliance. Audit logs capture the sequence of activities, including who performed an action, what resource was accessed, and the outcome, enabling detection of unauthorized or suspicious behavior.

Exam trap

CNCF often tests the misconception that disabling anonymous authentication is optional or that audit logging is only for debugging, when in fact both are mandatory hardening steps per the CIS Benchmark to prevent unauthorized access and ensure accountability.

188
Multi-Selecthard

Which THREE of the following are valid ways to secure etcd in a Kubernetes cluster? (Select THREE)

Select 3 answers
A.Allow anonymous access to etcd for ease of management
B.Enable encryption at rest for etcd data
C.Expose etcd on a public IP for external monitoring
D.Use etcd RBAC to restrict access to the etcd datastore
E.Enable TLS client-to-server authentication
AnswersB, D, E

Encryption at rest protects data if etcd storage is compromised.

Why this answer

Option B is correct because enabling encryption at rest for etcd data ensures that the stored Kubernetes secrets and cluster state are encrypted on disk using a provider like AES-CBC or AES-GCM. This protects sensitive data if the underlying storage is compromised, and is a required hardening step for compliance with standards like PCI-DSS or SOC 2.

Exam trap

The trap here is that candidates may confuse 'encryption at rest' with 'encryption in transit' (which is TLS), or mistakenly think that etcd RBAC (Option D) is not a valid security measure, when in fact etcd supports its own RBAC via `etcdctl` commands to restrict access to keys and users.

189
MCQeasy

Which of the following is a recommended practice for securing Kubernetes Dashboard?

A.Deploy Dashboard with minimal RBAC permissions and access it via kubectl proxy.
B.Expose Dashboard using a NodePort service with a ClusterRole binding to cluster-admin.
C.Use a LoadBalancer service without authentication.
D.Disable HTTPS and expose Dashboard on port 80.
AnswerA

Minimal permissions and kubectl proxy provide secure access without public exposure.

Why this answer

Option A is correct because deploying the Kubernetes Dashboard with minimal RBAC permissions and accessing it via `kubectl proxy` follows the principle of least privilege and avoids exposing the Dashboard to the network. `kubectl proxy` creates a local HTTP proxy to the Kubernetes API server, which authenticates the user's kubeconfig credentials, ensuring that only authorized users can reach the Dashboard and that the Dashboard itself has no direct network exposure.

Exam trap

The trap here is that candidates often think exposing the Dashboard via NodePort or LoadBalancer is acceptable for convenience, but the CKS exam emphasizes that any direct network exposure of the Dashboard without strong authentication and TLS is a critical security violation.

How to eliminate wrong answers

Option B is wrong because exposing the Dashboard via a NodePort service with a ClusterRole binding to `cluster-admin` grants unrestricted superuser access to anyone who can reach the NodePort, bypassing authentication and authorization controls. Option C is wrong because using a LoadBalancer service without authentication exposes the Dashboard to the internet or internal network without any credential check, allowing unauthorized access to the cluster. Option D is wrong because disabling HTTPS and exposing the Dashboard on port 80 transmits all traffic in cleartext, violating TLS encryption requirements and making the Dashboard vulnerable to man-in-the-middle attacks.

190
MCQeasy

Which of the following flags should be set to `false` to disable anonymous authentication to the Kubernetes API server?

A.--disable-anonymous=true
B.--auth-mode=RBAC
C.--anonymous-auth=false
D.--enable-anonymous-auth=false
AnswerC

This flag disables anonymous authentication.

Why this answer

Option C is correct because setting `--anonymous-auth=false` on the kube-apiserver disables anonymous requests. By default, anonymous authentication is enabled (set to `true`), allowing unauthenticated users to access the API server. Disabling it is a critical hardening step to prevent unauthorized access.

Exam trap

CNCF often tests the exact flag name and syntax, so the trap here is confusing `--anonymous-auth` with non-existent flags like `--disable-anonymous` or `--enable-anonymous-auth`, or mixing up authentication with authorization flags like `--authorization-mode`.

How to eliminate wrong answers

Option A is wrong because `--disable-anonymous=true` is not a valid kube-apiserver flag; the correct flag is `--anonymous-auth`. Option B is wrong because `--auth-mode=RBAC` is not a valid flag (the correct flag is `--authorization-mode=RBAC`) and it controls authorization, not authentication. Option D is wrong because `--enable-anonymous-auth=false` is not a valid flag; the correct flag is `--anonymous-auth` which takes a boolean value directly.

191
Multi-Selecthard

Which THREE of the following are valid methods to restrict access to etcd in a Kubernetes cluster? (Select THREE)

Select 3 answers
A.Use TLS certificates for client and server authentication
B.Enable RBAC authorization in etcd
C.Use simple username and password authentication
D.Put etcd on the same network as the API server without firewall
E.Encrypt etcd data at rest
AnswersA, B, E

Mutual TLS ensures only authenticated clients can connect.

Why this answer

Option A is correct because etcd supports mutual TLS (mTLS) authentication, where both the client (e.g., kube-apiserver) and the etcd server present TLS certificates to verify each other's identity. This is the standard and recommended method for securing communication between the API server and etcd, as it prevents unauthorized clients from accessing the key-value store and ensures data-in-transit encryption.

Exam trap

CNCF often tests the misconception that etcd can use simple username/password authentication or that network placement alone is sufficient for security, when in fact TLS mutual authentication and encryption at rest are the required hardening measures.

192
MCQeasy

A DevOps engineer needs to restrict the outbound network traffic from pods running in namespace 'secure-ns'. Which NetworkPolicy configuration achieves this by default?

A.Apply a NetworkPolicy that selects pods in 'secure-ns' and has an empty egress section.
B.Apply a NetworkPolicy that selects pods in 'secure-ns' and has an egress rule allowing all traffic.
C.No NetworkPolicy is needed because egress is denied by default.
D.Apply a NetworkPolicy that selects pods in 'secure-ns' and has an egress rule allowing traffic to port 53.
AnswerA

An empty egress rule blocks all egress traffic.

Why this answer

By default, Kubernetes NetworkPolicies are additive and deny-all unless explicitly allowed. Applying a NetworkPolicy with an empty egress section (no egress rules) to pods in 'secure-ns' effectively denies all outbound traffic from those pods, because the policy's egress field defaults to an empty list, which matches no traffic. This is the standard Kubernetes behavior for restricting egress.

Exam trap

The trap here is that candidates often assume egress is denied by default (Option C), but Kubernetes allows all egress until a NetworkPolicy explicitly restricts it, and an empty egress section in a policy is the correct way to achieve a deny-all for outbound traffic.

How to eliminate wrong answers

Option B is wrong because an egress rule allowing all traffic (e.g., an empty `to` and `ports` block) would permit all outbound traffic, not restrict it. Option C is wrong because egress is not denied by default; Kubernetes allows all egress traffic unless a NetworkPolicy explicitly restricts it. Option D is wrong because allowing traffic only to port 53 (DNS) would permit DNS queries but still deny all other outbound traffic, which is more permissive than the required full restriction.

193
MCQeasy

Which flag must be set on the kube-apiserver to disable anonymous authentication?

A.--anonymous-auth-enabled=false
B.--enable-anonymous-auth=false
C.--anonymous-auth=false
D.--disable-anonymous
AnswerC

This flag disables anonymous authentication as required by CIS benchmarks.

Why this answer

Option C is correct because the `--anonymous-auth=false` flag on the kube-apiserver disables anonymous authentication. When this flag is set to false, the API server rejects requests from unauthenticated users, enforcing that all requests must present valid credentials. This is a critical hardening measure to prevent unauthorized access to the cluster control plane.

Exam trap

The trap here is that candidates confuse the kube-apiserver flag syntax with similar flags from other Kubernetes components (e.g., kubelet's `--anonymous-auth-enabled`), leading them to pick the incorrect `--anonymous-auth-enabled=false` option.

How to eliminate wrong answers

Option A is wrong because `--anonymous-auth-enabled=false` is not a valid kube-apiserver flag; the correct flag is `--anonymous-auth` without the `-enabled` suffix. Option B is wrong because `--enable-anonymous-auth=false` is also not a valid flag; the kube-apiserver uses `--anonymous-auth` to control anonymous access, not `--enable-anonymous-auth`. Option D is wrong because `--disable-anonymous` is not a recognized flag; the kube-apiserver does not have a `--disable-anonymous` option, and the correct approach is to set `--anonymous-auth=false`.

194
MCQhard

A pod in namespace 'ns1' has automountServiceAccountToken: false. However, the container still has a mounted service account token at /var/run/secrets/kubernetes.io/serviceaccount. What is the most likely cause?

A.The automountServiceAccountToken field is set in the container spec instead of the pod spec
B.The kubelet is configured to always mount tokens
C.The namespace has a default automountServiceAccountToken: true
D.The pod is using a custom service account with automountServiceAccountToken: true
AnswerA

The field is a pod-level field; setting it at the container level has no effect.

Why this answer

The `automountServiceAccountToken` field is a pod-level setting. If it is set to `false` in the pod spec, the kubelet will not automatically mount the service account token. However, if the field is mistakenly set inside a container spec (which is not a valid field for containers), the pod-level setting is ignored, and the default behavior (mounting the token) applies.

This is why the token still appears mounted despite the intention to disable it.

Exam trap

The trap here is that candidates assume setting `automountServiceAccountToken: false` anywhere in the pod YAML will work, but they overlook that it must be at the pod spec level, not inside a container definition.

How to eliminate wrong answers

Option B is wrong because the kubelet does not have a global configuration to always mount tokens; the decision is controlled by the pod or namespace-level `automountServiceAccountToken` field. Option C is wrong because a namespace-level default only applies if the pod spec does not explicitly set `automountServiceAccountToken`; here the pod spec explicitly sets it to `false`, which overrides the namespace default. Option D is wrong because a custom service account's `automountServiceAccountToken` field only affects pods that use that service account; the pod's own `automountServiceAccountToken: false` in the pod spec takes precedence over the service account's setting.

195
MCQeasy

Which flag disables anonymous authentication on the Kubernetes API server?

A.--disable-anonymous-auth
B.--anonymous-auth=false
C.--anonymous-auth=true
D.--no-anonymous-auth
AnswerB

Correct flag to disable anonymous authentication.

Why this answer

Option B is correct because the `--anonymous-auth=false` flag explicitly disables anonymous authentication on the Kubernetes API server. By default, anonymous requests are allowed (equivalent to `--anonymous-auth=true`), so setting this flag to `false` prevents unauthenticated users from accessing the API server, which is a key hardening requirement for the CKS exam.

Exam trap

CNCF often tests the exact flag syntax, and the trap here is that candidates may misremember the flag as `--disable-anonymous-auth` or `--no-anonymous-auth` instead of the correct `--anonymous-auth=false` boolean pattern.

How to eliminate wrong answers

Option A is wrong because `--disable-anonymous-auth` is not a valid kube-apiserver flag; the correct flag uses a boolean value with `--anonymous-auth`. Option C is wrong because `--anonymous-auth=true` enables anonymous authentication, which is the default and does not disable it. Option D is wrong because `--no-anonymous-auth` is not a recognized flag; the Kubernetes API server uses `--anonymous-auth` with a boolean argument, not a negated prefix.

196
MCQeasy

Which of the following is a correct method to enable encryption at rest for secrets in etcd using the EncryptionConfiguration?

A.Use provider: aescbc
B.Use provider: encryption
C.Use provider: secretbox
D.Use provider: aesgcm
AnswerA

aescbc is a valid encryption provider for Kubernetes encryption at rest.

Why this answer

Option A is correct because `aescbc` (AES in Cipher Block Chaining mode) is the only provider listed that is officially supported by Kubernetes for encrypting secrets at rest in etcd. The EncryptionConfiguration resource allows you to specify `aescbc` as a provider, which encrypts data using a 32-byte key and is the recommended default for production clusters.

Exam trap

CNCF often tests the misconception that any encryption provider name like `encryption` or `aesgcm` is valid, but the trap here is that only `aescbc` is the correct and recommended provider for enabling encryption at rest in etcd, while `secretbox` and `aesgcm` are valid but not the intended correct answer in this context.

How to eliminate wrong answers

Option B is wrong because `encryption` is not a valid provider name in the Kubernetes EncryptionConfiguration; valid providers include `aescbc`, `secretbox`, `aesgcm`, and `identity`. Option C is wrong because `secretbox` is a valid provider (using XSalsa20-Poly1305) but it is not the correct answer for this question, which asks for a correct method; however, the question implies selecting the one that is correct among the options, and `aescbc` is the most commonly recommended and correct one. Option D is wrong because `aesgcm` (AES-GCM) is a valid provider but requires careful nonce management and is not recommended for general use due to the risk of nonce reuse; it is not the correct answer here.

197
MCQmedium

An administrator wants to enable RBAC authorization and disable anonymous authentication on the API server. Which set of flags should be added to the kube-apiserver configuration?

A.--enable-admission-plugins=NodeRestriction --anonymous-auth=false
B.--authorization-mode=AlwaysAllow --anonymous-auth=false
C.--authorization-mode=RBAC --anonymous-auth=false
D.--authorization-mode=Node --anonymous-auth=true
AnswerC

These flags enable RBAC authorization and disable anonymous access, following CIS recommendations.

Why this answer

Option C is correct because to enable RBAC authorization on the API server, you must set `--authorization-mode=RBAC`. Disabling anonymous authentication is achieved with `--anonymous-auth=false`, which prevents unauthenticated requests from being processed. Together, these flags enforce role-based access control and block anonymous access, meeting the administrator's requirements.

Exam trap

The trap here is confusing admission controllers (like NodeRestriction) with authorization modes, or thinking that `--authorization-mode=Node` alone provides full RBAC, when it only handles node-specific authorization and must be combined with RBAC in a chain (e.g., `--authorization-mode=Node,RBAC`).

How to eliminate wrong answers

Option A is wrong because `--enable-admission-plugins=NodeRestriction` is an admission controller flag, not an authorization mode; it restricts node self-updates but does not enable RBAC or disable anonymous auth. Option B is wrong because `--authorization-mode=AlwaysAllow` permits all requests without any authorization checks, which directly contradicts the goal of enabling RBAC. Option D is wrong because `--authorization-mode=Node` only authorizes node-specific requests (e.g., kubelet API calls) and `--anonymous-auth=true` leaves anonymous authentication enabled, failing both requirements.

198
MCQhard

A pod is failing with status 'CrashLoopBackOff'. The pod manifest includes a liveness probe that runs every 10 seconds. You suspect the probe is causing the crash. Which command would you use to verify the liveness probe configuration?

A.kubectl logs <pod>
B.kubectl exec <pod> -- cat /etc/kubernetes/manifests/pod.yaml
C.kubectl describe pod <pod>
D.kubectl get pod <pod> -o yaml
AnswerC

'kubectl describe pod' shows the liveness probe configuration under the container section, including the command, initial delay, period, etc.

Why this answer

Option C is correct because `kubectl describe pod <pod>` displays the pod's full configuration, including the liveness probe's exact parameters (e.g., initialDelaySeconds, periodSeconds, failureThreshold, and the probe action like HTTP GET, TCP socket, or exec command). This allows you to verify if the probe is misconfigured (e.g., too aggressive or pointing to a non-existent endpoint) and causing the CrashLoopBackOff.

Exam trap

CNCF often tests the distinction between `kubectl describe` (human-readable, includes probe status and events) and `kubectl get -o yaml` (full API object, more verbose but less immediate for troubleshooting), leading candidates to pick the latter when the former is more efficient for verifying probe configuration.

How to eliminate wrong answers

Option A is wrong because `kubectl logs <pod>` shows the container's stdout/stderr output, which may reveal crash reasons but does not show the liveness probe configuration. Option B is wrong because `kubectl exec <pod> -- cat /etc/kubernetes/manifests/pod.yaml` attempts to read a static pod manifest from inside the container, which typically does not exist (static manifests are on the node's filesystem, not inside the container), and even if it did, it would not reflect the live probe configuration from the API. Option D is wrong because `kubectl get pod <pod> -o yaml` outputs the pod's full YAML manifest from the API server, which includes the liveness probe, but `kubectl describe pod` is more concise and human-readable for quickly verifying probe details like periodSeconds and failureThreshold.

199
MCQmedium

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?

A.Delete the service account and recreate it without any role binding
B.Keep the binding but add a Deny policy for write actions
C.Set automountServiceAccountToken: false in the pod spec
D.Create a new ClusterRoleBinding that binds 'monitor' to a less privileged role (e.g., view) and delete the cluster-admin binding
AnswerD

Replacing with a read-only role like 'view' follows least-privilege.

Why this answer

Option D is correct because 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.

Exam trap

The trap here is that candidates may 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.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the service account without any role binding would remove all permissions, potentially breaking the monitoring functionality that requires some level of access. Option B is wrong because Kubernetes does not support a native 'Deny policy' for write actions on a ClusterRoleBinding; access control is managed via RBAC roles, not deny policies, and keeping the binding still violates least-privilege. Option C is wrong because setting automountServiceAccountToken: false in the pod spec only prevents automatic mounting of the service account token, but does not revoke the excessive permissions granted by the cluster-admin binding; the service account still has full cluster access if used elsewhere.

200
Multi-Selecthard

Which THREE of the following are best practices for RBAC hardening in Kubernetes? (Select THREE)

Select 3 answers
A.Avoid using the cluster-admin ClusterRole for service accounts
B.Grant cluster-admin to all service accounts for simplicity
C.Apply the principle of least privilege when creating Roles and ClusterRoles
D.Use the default namespace for all service accounts
E.Regularly audit ClusterRoleBindings for excessive permissions
AnswersA, C, E

Service accounts should have only the permissions they need.

Why this answer

Option A is correct because the cluster-admin ClusterRole grants unrestricted access to all Kubernetes resources across all namespaces, which violates the principle of least privilege. Service accounts should be assigned only the specific permissions required for their function, not full administrative access. Using cluster-admin for service accounts increases the blast radius of a potential compromise and is a common misconfiguration that the CKS exam penalizes.

Exam trap

CNCF often tests the misconception that 'simplicity' (Option B) or 'using the default namespace' (Option D) are acceptable shortcuts, when in fact the CKS exam strictly enforces least privilege and namespace isolation as core hardening principles.

201
MCQmedium

Which admission plugin should be enabled to prevent kubelets from modifying Node objects they should not have access to?

A.NamespaceLifecycle
B.NodeRestriction
C.PodSecurity
D.ServiceAccount
AnswerB

NodeRestriction restricts what a kubelet can modify on its node object.

Why this answer

The NodeRestriction admission plugin limits the kubelet's ability to modify Node and Pod objects to only those it is authorized to manage based on its credentials. It ensures a kubelet can only label, taint, or update status on its own Node object and cannot modify other Nodes, preventing privilege escalation or misconfiguration.

Exam trap

CNCF often tests the distinction between admission plugins that control Pod security (PodSecurity) versus those that control Node-level access (NodeRestriction), leading candidates to confuse PodSecurity with Node-level restrictions.

How to eliminate wrong answers

Option A is wrong because NamespaceLifecycle ensures namespaces exist and prevents deletion of system namespaces, but it does not restrict kubelet actions on Node objects. Option C is wrong because PodSecurity enforces Pod Security Standards (e.g., privileged, baseline, restricted) on Pods, not Node-level modifications. Option D is wrong because ServiceAccount manages automatic creation and mounting of service account tokens, but it has no role in controlling kubelet access to Node objects.

202
MCQmedium

Which kubelet flag prevents the kubelet from serving anonymous requests?

A.--authentication-anonymous=false
B.--anonymous-auth=false
C.--enable-anonymous=false
D.--anonymous-requests=false
AnswerB

This flag disables anonymous authentication on the kubelet.

Why this answer

The kubelet flag `--anonymous-auth=false` disables anonymous authentication, preventing unauthenticated requests from being served. By default, anonymous requests are enabled (`--anonymous-auth=true`), which allows any user without credentials to access the kubelet API. Setting this flag to `false` enforces authentication for all requests, a critical hardening step for cluster security.

Exam trap

CNCF often tests the exact flag name `--anonymous-auth` versus similar-sounding alternatives like `--authentication-anonymous` or `--enable-anonymous`, exploiting candidates' tendency to guess based on generic naming patterns rather than precise Kubernetes documentation.

How to eliminate wrong answers

Option A is wrong because `--authentication-anonymous=false` is not a valid kubelet flag; the correct flag uses `anonymous-auth`, not `authentication-anonymous`. Option C is wrong because `--enable-anonymous=false` does not exist; the kubelet uses `--anonymous-auth` to control anonymous access. Option D is wrong because `--anonymous-requests=false` is not a recognized kubelet flag; the correct parameter is `--anonymous-auth`.

203
MCQeasy

Which admission plugin is recommended by the CIS Benchmark to restrict what nodes can modify?

A.PodSecurity
B.AlwaysPullImages
C.ServiceAccount
D.NodeRestriction
AnswerD

NodeRestriction limits kubelet permissions.

Why this answer

The NodeRestriction admission plugin is recommended by the CIS Benchmark for Kubernetes to restrict what nodes can modify. It limits the Node and Pod objects a kubelet can modify, ensuring that a node can only modify its own Node object and Pods bound to it. This prevents a compromised node from affecting other nodes or pods in the cluster.

Exam trap

CNCF often tests the distinction between admission plugins that enforce security at the pod level (like PodSecurity) versus those that restrict node-level actions (like NodeRestriction), causing candidates to confuse the scope of each plugin.

How to eliminate wrong answers

Option A is wrong because PodSecurity is a deprecated admission plugin (replaced by Pod Security Admission) that enforces pod security standards, not node modification restrictions. Option B is wrong because AlwaysPullImages forces image pull policy to Always, ensuring images are always pulled from the registry, but does not restrict node-level modifications. Option C is wrong because ServiceAccount is an admission plugin that manages service account automounting and token projection, not node modification controls.

204
MCQeasy

Which kube-apiserver flag enables encryption at rest for secrets?

A.--encryption-provider-config
B.--encryption-key-file
C.--secret-encryption
D.--enable-encryption
AnswerA

This flag specifies the EncryptionConfiguration file.

Why this answer

The `--encryption-provider-config` flag is the correct answer because it is the kube-apiserver flag that specifies the path to a configuration file containing the encryption providers (like `aescbc`, `secretbox`, or `aesgcm`) and the associated keys for encrypting Kubernetes secrets at rest. This flag enables the encryption at rest feature for secrets and other resources, as defined in the encryption configuration file.

Exam trap

The trap here is that candidates may confuse the `--encryption-provider-config` flag with a non-existent flag like `--enable-encryption` or `--secret-encryption`, assuming encryption at rest is enabled by a simple boolean flag rather than a configuration file reference.

How to eliminate wrong answers

Option B is wrong because `--encryption-key-file` is not a valid kube-apiserver flag; encryption keys are defined within the encryption provider configuration file, not via a separate key file flag. Option C is wrong because `--secret-encryption` is not a real kube-apiserver flag; the encryption at rest feature is configured through the encryption provider configuration, not a dedicated secret encryption flag. Option D is wrong because `--enable-encryption` is not a valid kube-apiserver flag; the encryption at rest feature is enabled by providing the `--encryption-provider-config` flag, not a boolean enable flag.

205
Multi-Selecteasy

Which TWO checks are performed by kube-bench for the master node?

Select 2 answers
A.Ensure that the kubelet uses the NodeRestriction admission plugin
B.Ensure that the API server uses TLS 1.2
C.Ensure that the container runtime is Docker
D.Ensure that the --anonymous-auth argument is set to false
E.Ensure that the --audit-log-path argument is set
AnswersD, E

This is a CIS check for the API server.

Why this answer

Option D is correct because kube-bench checks that the kubelet's `--anonymous-auth` argument is set to `false` to prevent unauthenticated requests from reaching the kubelet API. This is a CIS Kubernetes Benchmark recommendation (e.g., 4.2.1) to enforce authentication for all kubelet requests. Setting this to false ensures that anonymous users cannot perform operations on the kubelet, reducing the attack surface.

Exam trap

CNCF often tests the distinction between kube-bench checks for the master node vs. worker node, and candidates mistakenly think kube-bench checks for container runtime type (like Docker) or TLS version specifics, when in reality kube-bench focuses on CIS benchmark items like authentication settings and audit logging.

206
MCQmedium

An administrator runs `kube-bench` and sees that the check 'Ensure that the --protect-kernel-defaults flag is set to true' has failed. Which component does this check apply to?

A.etcd
B.API server
C.Kubelet
D.Controller manager
AnswerC

The flag belongs to the kubelet to protect kernel defaults.

Why this answer

The `--protect-kernel-defaults` flag is a kubelet-specific security option that ensures the kubelet does not modify kernel parameters that could weaken node security. When set to true, it enforces that the kubelet respects kernel defaults, preventing privilege escalation via sysctl overrides. This check is part of the CIS Benchmark for the kubelet component, not for etcd, the API server, or the controller manager.

Exam trap

The trap here is that candidates often associate kernel parameter protection with the kubelet's sysctl management, but mistakenly attribute it to the API server or controller manager, which handle authorization and scheduling, not node-level kernel interactions.

How to eliminate wrong answers

Option A is wrong because etcd does not have a `--protect-kernel-defaults` flag; etcd uses flags like `--auto-compaction-retention` and `--peer-cert-file` for security. Option B is wrong because the API server does not have a `--protect-kernel-defaults` flag; its security flags include `--anonymous-auth`, `--authorization-mode`, and `--tls-cert-file`. Option D is wrong because the controller manager does not have a `--protect-kernel-defaults` flag; its relevant security flags are `--use-service-account-credentials` and `--root-ca-file`.

207
MCQhard

An etcd cluster uses TLS for peer and client communication. You need to secure etcd further by enabling RBAC. Which flag do you set on the etcd process to enable authentication?

A.--client-cert-auth=true
B.--enable-rbac=true
C.--authentication-mode=RBAC
D.--auth-mode=rbac
AnswerA

This enables client certificate authentication, which is required for RBAC.

Why this answer

In etcd, RBAC is not enabled by a dedicated RBAC flag; instead, authentication must first be turned on using `--client-cert-auth=true`. This flag requires clients to present a valid TLS certificate, which is the prerequisite for enabling RBAC. After setting this flag, you can use `etcdctl` commands like `etcdctl role add` and `etcdctl user add` to configure RBAC roles and users.

Exam trap

The trap here is that candidates often assume there is a direct `--enable-rbac` or `--auth-mode` flag for RBAC, but etcd requires `--client-cert-auth=true` first, and then RBAC is enabled via the etcd API or `etcdctl` commands.

How to eliminate wrong answers

Option B is wrong because `--enable-rbac=true` is not a valid etcd flag; etcd does not have a direct flag to enable RBAC. Option C is wrong because `--authentication-mode=RBAC` is not a recognized etcd flag; authentication in etcd is controlled via TLS client certificate authentication, not a mode parameter. Option D is wrong because `--auth-mode=rbac` is not a valid etcd flag; etcd uses `--client-cert-auth` for authentication and then RBAC is configured via the API or `etcdctl` commands.

208
Multi-Selectmedium

Which TWO admission plugins should be enabled to improve cluster security according to the CIS Benchmark? (Select 2)

Select 2 answers
A.NodeRestriction
B.PodSecurity
C.AlwaysPullImages
D.NamespaceLifecycle
E.ServiceAccount
AnswersA, B

CIS recommends enabling NodeRestriction to limit kubelet permissions.

Why this answer

NodeRestriction (A) is correct because it limits the permissions of kubelet nodes to only modify their own pods and node objects, preventing a compromised node from accessing or modifying other nodes' resources. PodSecurity (B) is correct because it enforces Pod Security Standards (Privileged, Baseline, Restricted) at the namespace level, replacing the deprecated PodSecurityPolicy and ensuring pods comply with security contexts like running as non-root or dropping capabilities. Both are explicitly recommended in the CIS Benchmark for Kubernetes to reduce the attack surface.

Exam trap

CNCF often tests the distinction between plugins that are 'recommended for security' (like NodeRestriction and PodSecurity) versus those that are 'useful but not CIS-mandated' (like AlwaysPullImages), leading candidates to over-select based on general security benefits rather than the specific CIS Benchmark requirements.

209
MCQmedium

An administrator runs 'kube-bench master' and receives a warning that etcd has no client certificate authentication. What is the recommended remediation?

A.Remove the --client-cert-auth flag
B.Set --anonymous-auth=true on etcd
C.Use etcdctl to enable authentication
D.Set --client-cert-auth=true and --trusted-ca-file on the etcd process
AnswerD

This enables mutual TLS authentication for etcd clients.

Why this answer

The warning indicates that etcd is running without client certificate authentication, which means any client can communicate with etcd without verifying its identity. Setting `--client-cert-auth=true` enables TLS-based client certificate authentication, and `--trusted-ca-file` specifies the CA certificate used to validate client certificates. This is the recommended remediation because it ensures only clients with valid certificates signed by the trusted CA can access etcd, preventing unauthorized access to the cluster's key-value store.

Exam trap

The trap here is that candidates might think enabling authentication via `etcdctl` (Option C) is sufficient, but etcd's client certificate authentication must be configured at the server process level via startup flags, not through a client command.

How to eliminate wrong answers

Option A is wrong because removing the `--client-cert-auth` flag would disable client certificate authentication entirely, which is the opposite of the required remediation and would worsen the security issue. Option B is wrong because setting `--anonymous-auth=true` on etcd allows unauthenticated anonymous requests, which would bypass authentication and increase the attack surface, not fix the missing client certificate authentication. Option C is wrong because `etcdctl` is a client tool for interacting with etcd, not a mechanism to enable client certificate authentication on the etcd server process; authentication must be configured via etcd's startup flags or configuration file.

210
Multi-Selecthard

Which TWO practices help secure the Kubernetes Dashboard?

Select 2 answers
A.Enable anonymous access to the Dashboard
B.Use a ClusterIP service and access it via kubectl proxy
C.Grant the Dashboard service account cluster-admin role for full functionality
D.Use RBAC to restrict Dashboard service account permissions to read-only
E.Expose the Dashboard via a NodePort service for easy access
AnswersB, D

Access via proxy avoids public exposure.

Why this answer

Option B is correct because accessing the Kubernetes Dashboard via `kubectl proxy` creates a secure, authenticated HTTP proxy between your local machine and the API server. This method leverages the API server's built-in authentication and authorization, ensuring that only users with valid kubeconfig credentials can reach the Dashboard. It also avoids exposing the Dashboard directly to the network, reducing the attack surface.

Exam trap

The trap here is that candidates often think exposing the Dashboard via a NodePort or granting it cluster-admin is acceptable for 'full functionality,' but the CKS exam strictly enforces least privilege and network security, making RBAC-restricted access via kubectl proxy the only secure approach among the options.

211
Multi-Selectmedium

Which TWO of the following are valid ways to restrict access to etcd? (Select 2)

Select 2 answers
A.Enable RBAC on etcd by setting --auth-token=jwt and configuring roles.
B.Use --peer-auto-tls=true to auto-generate certificates.
C.Use --admission-control=NodeRestriction on etcd.
D.Use TLS client certificates for authentication.
E.Set --client-cert-auth=false to disable authentication.
AnswersA, D

etcd supports RBAC with JWT tokens to restrict access.

Why this answer

Option A is correct because etcd supports Role-Based Access Control (RBAC) when you enable it with the `--auth-token=jwt` flag and then configure roles and users via `etcdctl`. This allows you to restrict which clients can read or write to the etcd key-value store, which is critical for securing Kubernetes cluster state. Without RBAC, any client that can reach the etcd port can access all secrets and configuration data.

Exam trap

The trap here is that candidates confuse etcd's `--client-cert-auth` flag (which enables TLS client certificate authentication) with the Kubernetes API server's `--admission-control` flag, or they assume that peer TLS options restrict client access.

212
MCQhard

You need to create an RBAC role that allows reading secrets only in namespace 'production'. Which ClusterRole and RoleBinding combination is correct?

A.Create a ClusterRole with get and list on secrets, then a RoleBinding in 'production'
B.Create a Role with get and list on secrets in namespace 'production', then a ClusterRoleBinding
C.Create a ClusterRole with get and list on secrets, then a ClusterRoleBinding to bind it to the user
D.Create a Role with get and list on secrets in namespace 'production', then a RoleBinding in 'production'
AnswerD

A Role is namespaced and the RoleBinding binds it within the same namespace, restricting access to 'production'.

Why this answer

Option D is correct because a Role is namespaced and can only grant permissions within a specific namespace, which is 'production' in this case. A RoleBinding then binds that Role to a user, group, or service account within the same namespace, ensuring the permissions are scoped correctly. This combination restricts secret read access exclusively to the 'production' namespace, meeting the requirement precisely.

Exam trap

CNCF often tests the misconception that ClusterRoles are always cluster-wide even when bound via a RoleBinding, but the trap here is that a ClusterRole bound with a RoleBinding actually scopes permissions to that namespace, yet the question's requirement for a Role (not ClusterRole) is the precise answer because a Role is inherently namespaced and avoids any ambiguity about scope.

How to eliminate wrong answers

Option A is wrong because a ClusterRole is cluster-scoped and, when used with a RoleBinding, grants permissions across all namespaces unless explicitly restricted by a RoleBinding's namespace, but the RoleBinding itself does not limit the ClusterRole's scope to a single namespace; the ClusterRole's rules apply cluster-wide, so this would allow reading secrets in all namespaces. Option B is wrong because a Role is namespaced, but a ClusterRoleBinding binds cluster-wide, which would fail as a Role cannot be bound to a ClusterRoleBinding; ClusterRoleBindings only bind ClusterRoles, not Roles. Option C is wrong because a ClusterRole with get and list on secrets, when bound via a ClusterRoleBinding, grants permissions across all namespaces, not just 'production', violating the requirement to restrict access to a single namespace.

213
MCQeasy

Which of the following is a valid method to disable automatic mounting of service account tokens for a pod?

A.Delete the service account token secret
B.Add 'automountServiceAccountToken: false' to the pod spec
C.Use a NetworkPolicy to block access to the token
D.Set the service account's 'automountServiceAccountToken' field to false
AnswerB

This field in the pod spec disables token mounting for that pod.

Why this answer

Option B is correct because setting `automountServiceAccountToken: false` in the pod spec explicitly disables the automatic mounting of the service account token into the pod. This is the most direct and granular way to prevent the token from being available inside the container, which is a key hardening step to reduce the attack surface if the pod does not need to interact with the Kubernetes API.

Exam trap

CNCF often tests the distinction between pod-level and service account-level settings, and candidates mistakenly choose the service account-level option (D) thinking it applies to all pods, but the pod-level setting (B) is the only one that directly and unconditionally disables mounting for that specific pod.

How to eliminate wrong answers

Option A is wrong because deleting the service account token secret does not prevent automatic mounting; Kubernetes will recreate the secret or the pod may still mount a token from a different secret. Option C is wrong because a NetworkPolicy controls network traffic, not filesystem mounts; it cannot block the pod's access to the token file that is already mounted inside the container. Option D is wrong because setting the service account's `automountServiceAccountToken` field to false only affects pods that use that service account by default, but a pod can override this by explicitly setting the field in its own spec; the pod-level setting takes precedence.

214
Multi-Selecthard

You are securing a cluster and want to ensure that service account tokens are not automatically mounted in pods that do not need them. Which THREE actions should you take?

Select 3 answers
A.Set --service-account-lookup=false on the API server
B.Set automountServiceAccountToken: false in the service account definition for service accounts that do not need tokens
C.Audit all service accounts to determine which ones need token mounting disabled
D.Set automountServiceAccountToken: false in the pod spec for each pod that does not need the token
E.Delete all service accounts except those used by system components
AnswersB, C, D

Correct. This disables mounting for all pods using that service account.

Why this answer

Option B is correct because setting `automountServiceAccountToken: false` in the service account definition prevents the automatic mounting of the service account token into any pod that uses that service account. This is a declarative, scalable approach to disable token mounting for all pods associated with that service account, aligning with the principle of least privilege.

Exam trap

The trap here is that candidates often confuse `automountServiceAccountToken: false` with deleting service accounts or disabling token validation, when the correct approach is to disable mounting at the service account or pod level, not to remove accounts or alter API server flags.

215
MCQhard

An administrator applies the following manifest to enable audit logging: apiVersion: audit.k8s.io/v1 kind: Policy metadata: name: audit-policy rules: - level: Metadata resources: - group: "" resources: ["secrets"] Which audit level is being used for requests to the Secrets API?

A.RequestResponse
B.Metadata
C.Request
D.None
AnswerB

Metadata logs request metadata without request/response bodies.

Why this answer

The manifest defines an audit policy rule with `level: Metadata` for the Secrets API (group: "", resources: ["secrets"]). The Metadata level logs only the metadata of the request—such as user, timestamp, and resource—without logging the request body or response body. Therefore, the correct audit level for requests to the Secrets API is Metadata.

Exam trap

CNCF often tests the distinction between audit levels, and the trap here is that candidates may confuse Metadata with Request or RequestResponse, thinking that Secrets require logging the full request/response for security, when in fact Metadata is the recommended level to avoid exposing sensitive data in audit logs.

How to eliminate wrong answers

Option A is wrong because RequestResponse logs both the request and response bodies, which is a higher verbosity level than what is specified in the policy. Option C is wrong because Request logs the request body but not the response body, which is also not the level set in the policy. Option D is wrong because the policy explicitly sets the level to Metadata, so the audit level is not None.

216
MCQeasy

Which flag must be set on the kube-apiserver to disable anonymous authentication?

A.--tls-cert-file=/etc/kubernetes/pki/apiserver.crt
B.--audit-log-path=/var/log/audit.log
C.--anonymous-auth=false
D.--authorization-mode=RBAC
AnswerC

This flag disables anonymous authentication, ensuring all requests are authenticated.

Why this answer

Option C is correct because the `--anonymous-auth=false` flag explicitly disables anonymous authentication on the kube-apiserver. By default, anonymous requests are allowed (the flag defaults to `true`), which can permit unauthenticated users to access the API server. Setting this flag to `false` ensures that all requests must present valid credentials, aligning with the principle of least privilege and hardening the cluster against unauthorized access.

Exam trap

CNCF often tests the distinction between authentication and authorization flags, so candidates may mistakenly choose `--authorization-mode=RBAC` (option D) thinking it controls who can access the API, when in fact it only governs what authenticated users are allowed to do, not whether anonymous users are permitted at all.

How to eliminate wrong answers

Option A is wrong because `--tls-cert-file` specifies the TLS certificate file for serving HTTPS, not authentication; it secures the transport layer but does not control whether anonymous requests are accepted. Option B is wrong because `--audit-log-path` enables audit logging to record API requests, but it does not affect authentication or disable anonymous access. Option D is wrong because `--authorization-mode=RBAC` sets the authorization mode to Role-Based Access Control, which governs what authenticated users can do, but it does not disable anonymous authentication; anonymous users could still be authorized if RBAC grants them permissions.

217
MCQmedium

A security audit reveals that several pods have the service account token mounted automatically. Which annotation should be added to the pod's service account to prevent automatic mounting?

A.Set 'automountServiceAccountToken: true' in the pod spec.
B.Add annotation 'seccomp.security.alpha.kubernetes.io/pod: "runtime/default"' to the service account.
C.Add annotation 'kubernetes.io/enforce-mountable-secrets: "false"' to the service account.
D.Set 'automountServiceAccountToken: false' in the service account definition.
AnswerD

Setting this field to false on the service account prevents automatic mounting of the token in pods using that service account.

Why this answer

Option D is correct because setting `automountServiceAccountToken: false` in the service account definition prevents pods that use that service account from automatically mounting the service account token. This is the recommended way to disable automatic token mounting at the service account level, as per Kubernetes security best practices.

Exam trap

The trap here is that candidates may confuse the `automountServiceAccountToken` field with other security mechanisms like seccomp profiles or secret mounting annotations, or mistakenly think that setting it to `true` in the pod spec would disable mounting.

How to eliminate wrong answers

Option A is wrong because setting `automountServiceAccountToken: true` in the pod spec explicitly enables automatic mounting, which is the opposite of what is needed to prevent it. Option B is wrong because the annotation `seccomp.security.alpha.kubernetes.io/pod: "runtime/default"` is used to set a seccomp profile for the pod, not to control service account token mounting. Option C is wrong because the annotation `kubernetes.io/enforce-mountable-secrets: "false"` does not exist; the correct annotation for controlling secret mounting is `kubernetes.io/enforce-mountable-secrets` but it is used to restrict which secrets can be mounted, not to disable automatic service account token mounting.

218
Multi-Selecthard

Which THREE of the following are valid methods to restrict access to the Kubernetes Dashboard? (Choose three.)

Select 3 answers
A.Use a ClusterIP service and only allow access via kubectl proxy
B.Expose the Dashboard via a NodePort service to the internet
C.Use an Ingress with authentication and TLS
D.Apply RBAC policies that restrict who can access the Dashboard
E.Deploy the Dashboard with a hostNetwork: true configuration
AnswersA, C, D

By using a ClusterIP service and kubectl proxy, access is limited to users who have kubectl and cluster access.

Why this answer

Option A is correct because using a ClusterIP service restricts the Dashboard to internal cluster access only. Access is then granted exclusively through `kubectl proxy`, which creates a local proxy server that authenticates the user via their kubeconfig context, ensuring that only authenticated and authorized users can reach the Dashboard without exposing it to the network.

Exam trap

CNCF often tests the misconception that exposing a service via NodePort or hostNetwork is acceptable for internal-only access, when in fact both methods inherently expose the service to the node's network and require additional security measures to restrict access.

219
MCQmedium

You are tasked with enabling audit logging for the Kubernetes API server. You have created an audit policy file at /etc/kubernetes/audit-policy.yaml. Which flag must be added to the API server manifest to enable audit logging?

A.--audit-policy-file=/etc/kubernetes/audit-policy.yaml
B.--audit-log-level=2
C.--enable-audit-log
D.--audit-log-path=/var/log/kubernetes/audit.log
AnswerD

This flag enables audit logging by specifying the output file.

Why this answer

Option D is correct because the `--audit-log-path` flag is required to enable audit logging in the Kubernetes API server. Without specifying a log path, the API server will not write audit events to a file, even if an audit policy is defined. The `--audit-policy-file` flag (Option A) defines the rules for what to audit, but audit logging itself is only activated when a log destination is provided via `--audit-log-path`.

Exam trap

CNCF often tests the misconception that `--audit-policy-file` alone enables audit logging, but the trap is that the log destination flag (`--audit-log-path`) is mandatory to actually start writing audit events.

How to eliminate wrong answers

Option A is wrong because `--audit-policy-file` only specifies the policy file that defines which events to audit; it does not enable the writing of audit logs. Option B is wrong because `--audit-log-level` is not a valid Kubernetes API server flag; audit log verbosity is controlled by the policy file, not a command-line level. Option C is wrong because `--enable-audit-log` is not a real flag; audit logging is enabled implicitly by providing a log path and policy file.

220
MCQhard

A security scanner reports that the Kubernetes dashboard is publicly accessible. Which recommended action should be taken?

A.Expose the dashboard as a NodePort service for easy access
B.Configure firewall rules to restrict access to the dashboard's ClusterIP
C.Enable authentication on the dashboard
D.Delete the dashboard deployment and use kubectl proxy to access it
AnswerD

kubectl proxy provides secure local access. Deleting the dashboard or restricting its service is recommended.

Why this answer

The Kubernetes Dashboard is a powerful administrative tool that should never be exposed to the public internet. Deleting the dashboard deployment and using `kubectl proxy` to access it locally is the recommended action because it eliminates the attack surface entirely and ensures that access is restricted to the machine running the kubectl command, leveraging the API server's built-in authentication and authorization.

Exam trap

CNCF often tests the misconception that adding authentication or network restrictions is sufficient to secure an exposed dashboard, when the correct answer is to remove the public-facing component and use a secure, authenticated proxy method like `kubectl proxy`.

How to eliminate wrong answers

Option A is wrong because exposing the dashboard as a NodePort service makes it accessible on every node's IP address at a high port, which directly contradicts the goal of restricting public access and increases the attack surface. Option B is wrong because configuring firewall rules to restrict access to the dashboard's ClusterIP is ineffective; ClusterIP is only reachable from within the cluster, so the scanner's report of public accessibility indicates the dashboard is already exposed via a different service type (e.g., LoadBalancer or NodePort), and firewall rules on ClusterIP do not address the actual exposure. Option C is wrong because enabling authentication on the dashboard does not prevent public network-level access; the dashboard would still be reachable from the internet, and authentication alone does not protect against denial-of-service attacks or unauthorized network scanning.

221
Multi-Selecthard

Which THREE of the following are recommended practices for hardening RBAC in a Kubernetes cluster? (Select 3)

Select 3 answers
A.Use the default service account in each namespace with cluster-admin.
B.Regularly audit ClusterRoleBindings and RoleBindings for over-privileged subjects.
C.Grant only the minimum permissions necessary for each subject.
D.Avoid binding cluster-admin to service accounts unless absolutely necessary.
E.Use RoleBindings with ClusterRoles in the same namespace to increase security.
AnswersB, C, D

Auditing helps identify and reduce excessive permissions.

Why this answer

Option B is correct because regular auditing of ClusterRoleBindings and RoleBindings helps identify over-privileged subjects, such as service accounts or users with excessive permissions, which is a key hardening practice. This aligns with the principle of least privilege and is recommended by Kubernetes security best practices to reduce the attack surface.

Exam trap

CNCF often tests the misconception that using RoleBindings with ClusterRoles is always more secure, but the trap here is that ClusterRoles can contain cluster-scoped permissions that are not namespace-restricted, potentially granting broader access than intended if not carefully reviewed.

222
MCQmedium

A security auditor runs kube-bench on your cluster and reports that the apiserver is using default service account tokens. Which admission plugin should be enabled to address this?

A.DefaultStorageClass
B.PodSecurity
C.NodeRestriction
D.ServiceAccount
AnswerB

PodSecurity (or legacy PodSecurityPolicy) can enforce policies that require automountServiceAccountToken: false.

Why this answer

The correct answer is B (PodSecurity) because the PodSecurity admission plugin (replacing the deprecated PodSecurityPolicy) enforces a restricted security context on pods, preventing them from automatically mounting the default service account token. By default, Kubernetes mounts a service account token into every pod, which can be exploited if an attacker gains access to a pod. Enabling PodSecurity with a policy that restricts automounting of service account tokens addresses the kube-bench finding.

Exam trap

The trap here is that candidates often confuse the ServiceAccount admission plugin (which handles token creation) with the PodSecurity plugin (which enforces restrictions on token mounting), leading them to select D instead of B.

How to eliminate wrong answers

Option A is wrong because DefaultStorageClass is an admission plugin that sets a default storage class for PersistentVolumeClaims, not related to service account token security. Option C is wrong because NodeRestriction limits the Node API permissions for kubelets, preventing them from modifying pods or secrets on other nodes, but does not control service account token mounting. Option D is wrong because ServiceAccount is an admission plugin that handles service account creation and token binding, but it does not enforce restrictions on automatic token mounting; in fact, it is the plugin that enables the default behavior of mounting tokens.

223
MCQeasy

Which admission plugin should be enabled on the kube-apiserver to enforce that kubelets cannot modify nodes they are not assigned to?

A.AlwaysPullImages
B.NodeSelector
C.PodSecurity
D.NodeRestriction
AnswerD

NodeRestriction ensures kubelets can only modify their own node objects.

Why this answer

The NodeRestriction admission plugin ensures that kubelets can only modify their own Node API objects and pods bound to them. When enabled, it prevents a kubelet from modifying nodes it is not assigned to, enforcing the principle of least privilege and limiting the blast radius of a compromised kubelet.

Exam trap

The trap here is that candidates confuse admission plugins that control pod behavior (like PodSecurity or AlwaysPullImages) with those that restrict kubelet actions, or they mistakenly think NodeSelector is a security control rather than a scheduling feature.

How to eliminate wrong answers

Option A is wrong because AlwaysPullImages forces every pod to pull container images from the registry on each start, but it does not restrict kubelet actions on nodes. Option B is wrong because NodeSelector is a scheduling constraint that limits which nodes a pod can run on, not a mechanism to control kubelet node modifications. Option C is wrong because PodSecurity (formerly PodSecurityPolicy) enforces security contexts on pods, such as privilege escalation or host namespace usage, but does not regulate kubelet behavior regarding node objects.

224
MCQmedium

An administrator runs kubectl get clusterrolebindings and sees a binding named 'system:node'. This binding is part of the legacy node authorization. According to CIS benchmarks, what should be done with it?

A.Delete it and rely on NodeRestriction and Node authorizer
B.Modify the role to include only necessary permissions
C.Keep it as it is required for cluster functionality
D.Add a condition to limit it to read-only
AnswerA

CIS recommends removing the system:node binding and using NodeRestriction.

Why this answer

The 'system:node' ClusterRoleBinding is a legacy binding that grants the 'system:node' cluster role to all nodes, effectively bypassing the Node Authorizer and NodeRestriction admission plugin. The CIS Benchmark for Kubernetes (section 5.1.1) recommends deleting this binding because it allows nodes to have broad, unrestricted access to the API server, which undermines the principle of least privilege. Instead, the Node Authorizer and NodeRestriction plugin should be used to enforce fine-grained, node-specific permissions based on the node's identity and the pods it runs.

Exam trap

The trap here is that candidates may think the 'system:node' binding is essential for node-to-API-server communication, but in reality, the Node Authorizer and NodeRestriction plugin handle this securely, making the legacy binding a security risk that should be removed.

How to eliminate wrong answers

Option B is wrong because modifying the role to include only necessary permissions does not address the fundamental issue: the binding itself grants the 'system:node' role to all nodes, which is a legacy mechanism that bypasses the Node Authorizer; the correct action is to delete the binding entirely and rely on the Node Authorizer. Option C is wrong because the binding is not required for cluster functionality; modern Kubernetes clusters use the Node Authorizer and NodeRestriction plugin to manage node permissions, making this legacy binding obsolete and a security risk. Option D is wrong because adding a read-only condition does not solve the problem; the binding still grants broad access to all nodes, and the Node Authorizer provides more granular, dynamic permissions based on the node's identity and the pods it runs, which is the recommended approach.

225
MCQhard

You are asked to ensure that a specific Kubernetes dashboard (e.g., kubernetes-dashboard) is not publicly accessible. The dashboard is deployed in the 'kube-system' namespace. Which NetworkPolicy should you apply?

A.NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Ingress], ingress: [{from: [{namespaceSelector: {matchLabels: {}}}]}]
B.NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Ingress], ingress: []
C.NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Ingress], ingress: [{from: [{podSelector: {matchLabels: {app: kubernetes-dashboard}}}]}]
D.NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Egress], egress: [{to: [{podSelector: {}}]}]
AnswerB

An empty ingress list with Ingress policy type denies all ingress traffic.

Why this answer

Option B is correct because a NetworkPolicy with an empty `ingress` array (i.e., `ingress: []`) explicitly denies all inbound traffic to the selected pods. This ensures that the kubernetes-dashboard pod in the kube-system namespace is not publicly accessible, as no ingress rules are defined to allow any source. By default, if no NetworkPolicy selects a pod, all traffic is allowed; applying this policy changes the default to deny for ingress.

Exam trap

The trap here is that candidates often think an empty `ingress: []` means 'no restriction' (like an empty allow list) or confuse it with omitting the `ingress` field entirely, but in NetworkPolicy, an empty array explicitly denies all ingress traffic, while omitting the field leaves the default allow behavior unchanged.

How to eliminate wrong answers

Option A is wrong because it uses `namespaceSelector: {matchLabels: {}}` which matches all namespaces (since an empty label selector matches everything), effectively allowing traffic from any namespace, thus not restricting public access. Option C is wrong because it allows ingress only from pods with the same label `app: kubernetes-dashboard`, which would permit traffic from other dashboard pods (e.g., replicas) but still denies external traffic; however, the goal is to deny all ingress, and this rule still allows some internal traffic, which is not the strictest deny. Option D is wrong because it defines an Egress policy (controlling outbound traffic) instead of an Ingress policy, and it allows egress to all pods (`podSelector: {}`), which does not address inbound access to the dashboard.

← PreviousPage 3 of 4 · 239 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Cluster Setup and Hardening questions.