CCNA Cks Cluster Setup Hardening Questions — Page 4 of 4

226

Multi-Selectmedium

Which THREE options are valid methods to secure etcd in a Kubernetes cluster?

Select 3 answers

A.Set --auto-compaction-mode=periodic

B.Enable TLS with peer and client certificates

C.Use a firewall to restrict access to etcd's port

D.Encrypt secrets at rest using EncryptionConfiguration

E.Enable RBAC authorization in etcd

AnswersB, C, D

Encrypts communication and authenticates clients.

Why this answer

Option B is correct because enabling TLS with peer and client certificates encrypts all communication between etcd members and between etcd and the Kubernetes API server, preventing man-in-the-middle attacks and unauthorized access. This is a fundamental security requirement for etcd in production clusters, as etcd stores all cluster state and secrets.

Exam trap

The trap here is that candidates may confuse etcd's maintenance features (like compaction) with security controls, or assume that Kubernetes RBAC extends to etcd, when in fact etcd has its own separate access control mechanisms.

Practice this question →

227

MCQmedium

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

A.Access the Dashboard using 'kubectl proxy' and never expose it publicly.

B.Expose the Dashboard via a LoadBalancer service for easy access.

C.Disable authentication for the Dashboard to simplify access.

D.Grant the Dashboard service account cluster-admin permissions.

AnswerA

kubectl proxy provides a secure way to access the Dashboard without exposing it to the network.

Why this answer

Accessing the Kubernetes Dashboard via 'kubectl proxy' is recommended because it creates a local HTTP proxy between your workstation and the API server, ensuring the Dashboard is never exposed to external networks. This approach leverages the API server's authentication and authorization mechanisms, avoiding the need to open network ports or expose the Dashboard directly, which aligns with the principle of least privilege and reduces the attack surface.

Exam trap

The trap here is that candidates often assume exposing the Dashboard via a LoadBalancer or NodePort is acceptable for convenience, but Cisco tests the understanding that the Dashboard must never be publicly accessible and should only be accessed through the API server proxy to enforce authentication and authorization.

How to eliminate wrong answers

Option B is wrong because exposing the Dashboard via a LoadBalancer service makes it publicly accessible over the internet, which violates security best practices by increasing the attack surface and potentially allowing unauthorized access. Option C is wrong because disabling authentication for the Dashboard removes all access controls, allowing anyone who can reach the Dashboard URL to perform actions with the Dashboard's service account permissions, which is a severe security risk. Option D is wrong because granting the Dashboard service account cluster-admin permissions provides unrestricted superuser access across the entire cluster, violating the principle of least privilege and enabling privilege escalation if the Dashboard is compromised.

Practice this question →

228

MCQhard

You want to ensure that kubelets only serve pods that have been scheduled by the API server. Which admission plugin should be enabled?

A.ServiceAccount

B.AlwaysPullImages

C.PodNodeSelector

D.NodeRestriction

AnswerD

This plugin restricts kubelet self-modification and ensures pods are bound to the node.

Why this answer

The NodeRestriction admission plugin limits the Node and Pod objects a kubelet can modify. When enabled, each kubelet can only create/modify pods bound to its own node, and only pods that have been scheduled by the API server (i.e., have a non-empty `spec.nodeName` set by the scheduler). This prevents a compromised kubelet from creating arbitrary pods or modifying pods on other nodes, enforcing that only the API server schedules pods.

Exam trap

The trap here is that candidates confuse admission plugins that control pod placement (like PodNodeSelector) with the plugin that restricts kubelet actions (NodeRestriction), leading them to select PodNodeSelector because it sounds related to node selection, but it does not enforce that pods are only created by the API server.

How to eliminate wrong answers

Option A is wrong because ServiceAccount is an admission plugin that enforces service account automounting and token projection, not node-level pod scheduling restrictions. Option B is wrong because AlwaysPullImages forces every pod to pull its images with credentials, which is a security measure for image integrity, not for restricting pod scheduling to API-server-scheduled pods. Option C is wrong because PodNodeSelector enforces namespace-level node selector constraints on pods, but it does not prevent a kubelet from creating or modifying pods that were not scheduled by the API server.

Practice this question →

229

Multi-Selecthard

Which THREE flags should be set on the kubelet to comply with the CIS Benchmark for worker node security?

Select 3 answers

A.--authentication-token-webhook=false

B.--read-only-port=10255

C.--anonymous-auth=false

D.--protect-kernel-defaults=true

E.--authorization-mode=Webhook

AnswersC, D, E

Disables anonymous authentication.

Why this answer

Option C is correct because the CIS Benchmark for Kubernetes requires disabling anonymous authentication on the kubelet by setting `--anonymous-auth=false`. This ensures that all requests to the kubelet are authenticated, preventing unauthenticated access to the kubelet API, which could allow an attacker to execute commands or retrieve sensitive node information.

Exam trap

CNCF often tests the distinction between authentication and authorization flags, leading candidates to confuse `--authentication-token-webhook=false` (which weakens security) with the required `--authorization-mode=Webhook` (which strengthens it).

Practice this question →

230

MCQeasy

Which admission plugin should be enabled on the API server to ensure that the kubelet cannot modify its own Node object beyond its assigned node?

A.PodSecurityPolicy

B.AlwaysPullImages

C.ServiceAccount

D.NodeRestriction

AnswerD

This plugin enforces node-level restrictions.

Why this answer

The NodeRestriction admission plugin limits the kubelet's ability to modify its own Node object, ensuring it can only label, taint, or update status on its assigned Node. This prevents a compromised kubelet from impersonating other nodes or escalating privileges. It is the correct plugin for enforcing node-scoped kubelet permissions.

Exam trap

CNCF often tests the trap where candidates confuse NodeRestriction with PodSecurityPolicy or other admission controllers that deal with pod security, not kubelet node permissions.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy is a deprecated admission controller that enforces security constraints on pods (e.g., privileged containers, host namespaces), not on kubelet node modifications. Option B is wrong because AlwaysPullImages forces image pull policy to Always for all pods, addressing image freshness and registry authentication, not node object restrictions. Option C is wrong because ServiceAccount manages service account creation and token mounting for pods, not kubelet node access control.

Practice this question →

231

Multi-Selectmedium

Which TWO of the following are recommended practices according to the CIS Kubernetes Benchmark? (Select 2)

Select 2 answers

A.Enable audit logging on the API server

B.Disable anonymous authentication on the API server

C.Enable anonymous authentication on the kubelet

D.Use the AlwaysAllow authorization mode

E.Disable the NodeRestriction admission plugin

AnswersA, B

CIS recommends enabling audit logging with a policy file.

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. Option B is correct because disabling anonymous authentication on the API server prevents unauthenticated requests from being processed, reducing the attack surface. The benchmark specifically advises setting `--anonymous-auth=false` on the API server to enforce authentication for all requests.

Exam trap

CNCF often tests the distinction between the API server and the kubelet: candidates may incorrectly assume that disabling anonymous authentication on the API server also applies to the kubelet, or they may confuse the recommendation to disable anonymous authentication on the API server with enabling it on the kubelet, which is a common trap.

Practice this question →

232

Multi-Selectmedium

Which TWO of the following are recommendations from the CIS Kubernetes Benchmark?

Select 2 answers

A.Enable audit logging

B.Use TokenReview API for authentication

C.Disable anonymous authentication

D.Set --protect-kernel-defaults=false on kubelet

E.Enable the insecure port for kubelet

AnswersA, C

CIS recommends enabling audit logging.

Why this answer

The CIS Kubernetes Benchmark recommends enabling audit logging to record all API server requests, which is essential for security monitoring and forensic analysis. It also recommends disabling anonymous authentication to ensure that all requests are authenticated, preventing unauthenticated access to the cluster.

Exam trap

CNCF often tests the exact wording of CIS Benchmark recommendations, so candidates may confuse 'disable anonymous authentication' with 'disable authentication entirely' or mistakenly think the TokenReview API is a benchmark recommendation when it is just a standard API object.

Practice this question →

233

MCQhard

You are securing etcd. Which of the following is required to enable TLS client authentication for etcd?

A.Set --auto-tls to true

B.Set --peer-client-cert-auth to true

C.Use --cert-file and --key-file only

D.Set --client-cert-auth to true and provide --trusted-ca-file

AnswerD

These flags enable and configure client certificate authentication.

Why this answer

Option D is correct because etcd requires `--client-cert-auth=true` to enforce TLS client certificate authentication for incoming client requests, and `--trusted-ca-file` must be provided to specify the CA certificate used to validate client certificates. Without both, client certificate authentication is not enabled.

Exam trap

The trap here is that candidates confuse `--peer-client-cert-auth` (for inter-node communication) with `--client-cert-auth` (for client-to-server communication), leading them to select option B instead of D.

How to eliminate wrong answers

Option A is wrong because `--auto-tls` enables self-signed TLS for peer and client connections but does not enforce client certificate authentication; it is intended for development or testing, not secure production use. Option B is wrong because `--peer-client-cert-auth` enables client certificate authentication for peer-to-peer communication between etcd members, not for client connections to the etcd API. Option C is wrong because `--cert-file` and `--key-file` only configure the server certificate for TLS, but without `--client-cert-auth=true` and `--trusted-ca-file`, the server will not request or validate client certificates.

Practice this question →

234

Multi-Selecthard

Which THREE of the following are valid flags for enabling admission plugins on the API server?

Select 3 answers

A.--enable-admission-plugins=AlwaysPullImages

B.--enable-admission-plugins=PodSecurity,NodeRestriction

C.--plugin-dir=/admission

D.--enable-admission-plugins=NodeRestriction

E.--admission-control=NodeRestriction

AnswersA, B, D

AlwaysPullImages is a valid admission plugin.

Why this answer

Option A is correct because `--enable-admission-plugins=AlwaysPullImages` is the valid flag to enable the AlwaysPullImages admission plugin on the kube-apiserver. This flag accepts a comma-separated list of plugin names, and AlwaysPullImages is a built-in admission controller that forces every new Pod to pull images again, even if they already exist on the node, enhancing security by ensuring only authorized images are used.

Exam trap

CNCF often tests the distinction between the deprecated `--admission-control` flag and the current `--enable-admission-plugins` flag, as well as the difference between built-in plugin flags and plugin directory flags, to catch candidates who rely on outdated knowledge or confuse configuration parameters.

Practice this question →

235

MCQhard

An etcd cluster is configured with TLS. You need to enforce that only the API server can read and write to etcd. Which method should you use?

A.Configure etcd RBAC with a role that grants readwrite access only to the API server's client certificate CN

B.Set etcd's --peer-client-cert-auth flag to true

C.Set etcd's --client-cert-auth flag to false

D.Use a NetworkPolicy to restrict access to etcd port 2379

AnswerA

Correct. etcd RBAC can restrict access based on client certificate CN.

Why this answer

Option A is correct because etcd supports Role-Based Access Control (RBAC) that can restrict access based on the Common Name (CN) in the client certificate. By creating a role with readwrite access and binding it only to the API server's client certificate CN, you ensure that only the API server can read and write to etcd, while other clients are denied.

Exam trap

CNCF often tests the distinction between client-to-etcd authentication (--client-cert-auth) and peer-to-peer authentication (--peer-client-cert-auth), and candidates may confuse the two or think disabling client-cert-auth improves security, when it actually opens access.

How to eliminate wrong answers

Option B is wrong because --peer-client-cert-auth enables client certificate authentication for peer-to-peer communication between etcd members, not for client-to-etcd access, so it does not restrict API server access. Option C is wrong because setting --client-cert-auth to false disables client certificate authentication entirely, allowing any client to connect, which is the opposite of enforcing access control. Option D is wrong because a NetworkPolicy can restrict network-level access to port 2379, but it cannot enforce certificate-based identity; it would block all traffic including legitimate API server traffic if misconfigured, and does not provide the granularity of CN-based authorization.

Practice this question →

236

Matchingmedium

Match each container security context setting to its effect.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Prevents processes from gaining more privileges than their parent

Ensures the container runs with a user ID that is not 0 (root)

Mounts the container's root filesystem as read-only

Drops all Linux capabilities, minimizing kernel privileges

Disables privileged mode, preventing access to host devices

Why these pairings

These settings are used to enforce least privilege for containers.

Practice this question →

237

MCQhard

A pod running in the cluster is in a CrashLoopBackOff state. You run 'kubectl describe pod <pod>' and see the following event: 'Warning BackOff Back-off restarting failed container'. Which command would you run to see the standard error output of the container?

A.kubectl logs <pod> --previous

B.kubectl exec <pod> -- cat /var/log/syslog

C.kubectl describe pod <pod>

D.kubectl logs <pod>

AnswerA

Using --previous retrieves logs from the previous instance of the container, which is essential when the container is restarting due to a crash.

Why this answer

Option A is correct because `kubectl logs <pod> --previous` retrieves the logs from the previous instance of a crashed or restarting container. When a pod is in CrashLoopBackOff, the current container may have already restarted, so the standard error output from the failed run is only available in the previous container's logs. This command specifically fetches those logs, which typically contain the stderr output that caused the crash.

Exam trap

CNCF often tests the distinction between `kubectl logs <pod>` and `kubectl logs <pod> --previous`; the trap here is that candidates assume the current container's logs contain the crash information, but in a CrashLoopBackOff, the current container may have already restarted and its logs are empty or show only the restart loop, so the `--previous` flag is required to see the actual error output from the failed run.

How to eliminate wrong answers

Option B is wrong because `kubectl exec <pod> -- cat /var/log/syslog` attempts to run a command inside the currently running container, but in a CrashLoopBackOff state the container may not be running or may restart immediately, making exec unreliable; also, containerized applications often do not log to /var/log/syslog. Option C is wrong because `kubectl describe pod <pod>` shows events and metadata but does not display the container's standard error output; it only shows the back-off event already seen. Option D is wrong because `kubectl logs <pod>` fetches logs from the current (possibly restarted) container, which may be empty or show only the restart loop, not the stderr from the failed previous instance.

Practice this question →

238

MCQmedium

You are auditing RBAC and find a ClusterRoleBinding named 'admin-binding' that binds the 'cluster-admin' ClusterRole to the service account 'default' in namespace 'kube-system'. What is the risk?

A.The risk is only if the service account is used by external users

B.The ClusterRoleBinding is invalid because it uses a namespace-scoped service account

C.Any pod using the default service account in kube-system has cluster-admin privileges

D.No risk, as it is limited to kube-system namespace

AnswerC

The service account inherits the cluster-admin role.

Why this answer

Option C is correct because the ClusterRoleBinding 'admin-binding' binds the 'cluster-admin' ClusterRole to the 'default' service account in the 'kube-system' namespace. Since ClusterRoleBindings are cluster-scoped, they grant permissions across all namespaces. Any pod in the 'kube-system' namespace that uses the 'default' service account (which is the default if no other service account is specified) will inherit cluster-admin privileges, allowing full control over the entire cluster.

Exam trap

CNCF often tests the distinction between RoleBindings (namespace-scoped) and ClusterRoleBindings (cluster-scoped), and the trap here is that candidates mistakenly think a ClusterRoleBinding to a namespace-scoped service account is invalid or limited to that namespace.

How to eliminate wrong answers

Option A is wrong because the risk is not limited to external users; any pod (including internal workloads) using the default service account in kube-system gains cluster-admin privileges, regardless of user identity. Option B is wrong because ClusterRoleBindings can bind to namespace-scoped subjects (like service accounts) — the binding is valid and does not require the subject to be cluster-scoped. Option D is wrong because ClusterRoleBindings grant permissions cluster-wide, not limited to the kube-system namespace; the binding gives admin access to all namespaces.

Practice this question →

239

MCQeasy

Which kubectl command can be used to determine if anonymous authentication is enabled on the API server?

A.kubectl get --raw /api/v1

B.kubectl describe node | grep anonymous

C.kubectl cluster-info dump | grep -i anonymous

D.kubectl get pods -n kube-system kube-apiserver-<node> -o yaml | grep anonymous-auth

AnswerD

This shows the API server flags, including --anonymous-auth.

Why this answer

Option D is correct because the kube-apiserver manifest file (typically located in /etc/kubernetes/manifests/kube-apiserver.yaml) contains the `--anonymous-auth` flag. By inspecting the pod definition via `kubectl get pods -n kube-system kube-apiserver-<node> -o yaml`, you can see the exact command-line arguments passed to the API server, including whether `--anonymous-auth=false` is set (disabled) or absent (enabled by default). This is the most direct and reliable method to check anonymous authentication status.

Exam trap

The trap here is that candidates might think `kubectl cluster-info dump` or `kubectl get --raw` can reveal server flags, but these commands do not expose the API server's startup arguments; only inspecting the pod manifest or directly reading the static pod YAML file shows the actual `--anonymous-auth` setting.

How to eliminate wrong answers

Option A is wrong because `kubectl get --raw /api/v1` returns API resource listing and does not expose server configuration flags like anonymous authentication. Option B is wrong because `kubectl describe node` shows node metadata and conditions, not API server flags; the grep for 'anonymous' would not match anything relevant. Option C is wrong because `kubectl cluster-info dump` outputs cluster-wide logs and resource dumps, but it does not parse the API server's command-line arguments; grepping for 'anonymous' might yield false positives from logs or other components, not a definitive check of the `--anonymous-auth` flag.

Practice this question →