Knowledge + Practice

CCNA Cluster Setup and Hardening Questions

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

Practice these questions Domain overview All questions

1

MCQmedium

What is the purpose of the --authorization-mode=RBAC flag on the API server?

A.It enables role-based access control for the API server

B.It disables anonymous authentication

C.It enables the NodeRestriction admission plugin

D.It enables audit logging for RBAC events

AnswerA

RBAC is the standard authorization mode for Kubernetes.

Why this answer

The `--authorization-mode=RBAC` flag configures the Kubernetes API server to use Role-Based Access Control (RBAC) as its authorization mode. This means that when a request reaches the API server, after authentication, the authorization module checks the request against RBAC roles and role bindings to determine if the user or service account has permission to perform the requested action. Without this flag, the API server would default to other modes (e.g., AlwaysAllow) or require explicit configuration of a different authorizer.

Exam trap

CNCF often tests the distinction between authorization modes and other API server flags (like admission plugins or audit logging), so candidates may confuse `--authorization-mode=RBAC` with enabling audit logging or admission controllers, when in fact each flag controls a completely separate subsystem.

How to eliminate wrong answers

Option B is wrong because anonymous authentication is controlled by the `--anonymous-auth` flag (defaults to true), not by the `--authorization-mode` flag; disabling anonymous auth is a separate configuration. Option C is wrong because the NodeRestriction admission plugin is enabled via the `--enable-admission-plugins` flag, not through the authorization mode flag. Option D is wrong because audit logging for RBAC events is configured via the `--audit-policy-file` flag and audit policy rules, not by setting the authorization mode to RBAC.

Practice this question →

2

MCQhard

After running kube-bench, you see a failing check: '1.1.1 Ensure that the API server pod specification file permissions are set to 600 or more restrictive'. What is the remediation?

A.Change permissions of /var/lib/kubelet/config.yaml to 600

B.Change permissions of /var/log/audit.log to 600

C.Change permissions of /etc/kubernetes/manifests/kube-apiserver.yaml to 600

D.Change permissions of /etc/kubernetes/manifests/kube-controller-manager.yaml to 600

AnswerC

This file contains the API server's static pod definition; restrictive permissions prevent unauthorized changes.

Why this answer

Check 1.1.1 from kube-bench specifically targets the API server pod specification file, which is located at /etc/kubernetes/manifests/kube-apiserver.yaml. The remediation is to set its permissions to 600 or more restrictive to prevent unauthorized read or write access, as this file contains critical configuration parameters for the API server.

Exam trap

CNCF often tests the exact mapping between kube-bench check IDs and their corresponding file paths, so the trap here is confusing the API server pod spec file with other static pod manifests (like controller-manager) or configuration files (like kubelet config or audit logs).

How to eliminate wrong answers

Option A is wrong because /var/lib/kubelet/config.yaml is the kubelet configuration file, not the API server pod spec, and its permissions are covered by a different kube-bench check (e.g., 4.1.1). Option B is wrong because /var/log/audit.log is an audit log file, not a pod specification file, and its permissions are addressed by checks related to audit logging, not check 1.1.1. Option D is wrong because /etc/kubernetes/manifests/kube-controller-manager.yaml is the controller manager pod spec, which is a separate component; check 1.1.1 is specific to the API server pod spec file.

Practice this question →

3

Multi-Selectmedium

Which TWO of the following are valid methods to secure the etcd datastore in a Kubernetes cluster?

Select 2 answers

A.Enable TLS encryption for client-to-server communication.

B.Enable peer authentication using TLS certificates.

C.Use HTTP instead of HTTPS for better performance.

D.Disable client authentication to simplify configuration.

E.Expose the etcd port (2379) on a public IP for easier monitoring.

AnswersA, B

TLS encrypts data in transit between etcd and clients.

Why this answer

Option A is correct because enabling TLS encryption for client-to-server communication ensures that all data transmitted between etcd clients (such as the Kubernetes API server) and the etcd server is encrypted, preventing eavesdropping and man-in-the-middle attacks. This is a fundamental security measure for protecting sensitive cluster state and secrets stored in etcd.

Exam trap

The trap here is that candidates may think enabling TLS for client-to-server communication is optional or that peer authentication is not required, but the CKS exam emphasizes that both client and peer TLS are mandatory for securing etcd in a hardened cluster.

Practice this question →

4

MCQmedium

An administrator wants to enable audit logging on the API server. Which three flags are required to set up basic audit logging?

A.--audit-log-maxage=30

B.--audit-log-format=json

C.--audit-log-path=/var/log/kubernetes/audit.log

D.--audit-policy-file=/etc/kubernetes/audit-policy.yaml

AnswerA, C, D

Sets the number of days to retain old audit log files.

Why this answer

Option A is correct because the `--audit-log-maxage` flag defines the maximum number of days to retain old audit log files. This is a required flag for basic audit logging setup, as it ensures log rotation and prevents disk exhaustion. Without this flag, the API server will not rotate logs, which can lead to data loss or storage issues.

Exam trap

CNCF often tests the misconception that `--audit-log-format=json` is required for basic audit logging, when in fact JSON is the default format and the flag is optional, leading candidates to select it as a required flag.

How to eliminate wrong answers

Option B is wrong because `--audit-log-format=json` is not a required flag for basic audit logging; it is optional and defaults to JSON format if not specified. The basic audit logging setup only requires flags for log path, policy file, and retention settings, not the format. Option C is correct as it specifies the log file path, which is mandatory for enabling audit logging.

Option D is correct as it points to the audit policy file, which defines what events to log and is required for audit logging to function.

Practice this question →

5

MCQhard

You are tasked with securing the kubelet. Which flag must be set on the kubelet to enable the NodeRestriction admission plugin?

A.--admission-control=NodeRestriction on the kubelet

B.--enable-admission-plugins=NodeRestriction on the kubelet

C.--node-restriction=true on the kubelet

D.--enable-admission-plugins=NodeRestriction on the kube-apiserver

AnswerD

The NodeRestriction plugin is an admission controller on the API server, enabled with this flag.

Why this answer

Option D is correct because the NodeRestriction admission plugin is an admission controller that runs on the kube-apiserver, not on the kubelet. It limits the Node and Pod objects a kubelet can modify, enforcing that nodes can only modify their own node object and pods bound to them. The flag `--enable-admission-plugins=NodeRestriction` on the kube-apiserver activates this plugin, which is a key security control for hardening the cluster.

Exam trap

The trap here is that candidates confuse the kubelet's role with the kube-apiserver's role, assuming admission plugins are configured on the kubelet because the NodeRestriction plugin directly affects kubelet behavior, but in reality admission plugins are always server-side components on the kube-apiserver.

How to eliminate wrong answers

Option A is wrong because the kubelet does not have an `--admission-control` flag; admission plugins are configured on the kube-apiserver, and the deprecated `--admission-control` flag was replaced by `--enable-admission-plugins`. Option B is wrong because the kubelet does not support the `--enable-admission-plugins` flag; that flag is exclusive to the kube-apiserver, and the kubelet has no concept of admission plugins. Option C is wrong because there is no `--node-restriction` flag on the kubelet; the NodeRestriction admission plugin is enabled via the kube-apiserver, not through a boolean flag on the kubelet.

Practice this question →

6

MCQmedium

You need to audit all API requests to the cluster. Which set of apiserver flags should be configured?

A.--audit-log-path, --audit-policy-file

B.--audit-log-maxage, --audit-log-maxbackup

C.--audit-webhook-config-file, --audit-webhook-mode

D.--audit-dynamic-configuration

AnswerA

These two enable audit logging.

Why this answer

To audit all API requests to the cluster, you must enable the audit logging feature in the kube-apiserver. The two essential flags are `--audit-log-path` to specify the file where audit events are written and `--audit-policy-file` to define the rules that determine which events are logged. Without both, the apiserver will not generate audit logs at all.

Exam trap

CNCF often tests the distinction between enabling audit logging and configuring its advanced features, so candidates mistakenly pick rotation or webhook options thinking they are the primary enablers.

How to eliminate wrong answers

Option B is wrong because `--audit-log-maxage` and `--audit-log-maxbackup` control log rotation and retention, not the enabling of audit logging itself. Option C is wrong because `--audit-webhook-config-file` and `--audit-webhook-mode` configure a webhook backend for audit events, but they still require `--audit-policy-file` to define which events to send; they are not the minimal set to enable auditing. Option D is wrong because `--audit-dynamic-configuration` enables runtime changes to the audit policy, but it is an additional feature that requires a base audit policy file to be already configured; it does not enable auditing by itself.

Practice this question →

7

MCQmedium

An administrator creates an EncryptionConfiguration with aescbc and saves it to /etc/kubernetes/enc/enc.yaml. Which flag must be added to the kube-apiserver to enable encryption at rest?

A.--encryption-config=/etc/kubernetes/enc/enc.yaml

B.--enable-encryption

C.--encryption-provider=aescbc

D.--encryption-provider-config=/etc/kubernetes/enc/enc.yaml

AnswerD

This flag specifies the path to the encryption configuration file.

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 that defines the encryption provider (e.g., aescbc) and resources to encrypt. This flag enables encryption at rest for Kubernetes secrets and other API data stored in etcd.

Exam trap

The trap here is that candidates confuse the valid `--encryption-provider-config` flag with similar-sounding but invalid flags like `--encryption-config` or `--encryption-provider`, or assume a simple `--enable-encryption` toggle exists, when in reality encryption at rest requires a detailed configuration file.

How to eliminate wrong answers

Option A is wrong because `--encryption-config` is not a valid kube-apiserver flag; the correct flag is `--encryption-provider-config`. Option B is wrong because `--enable-encryption` does not exist; encryption at rest is configured via a provider configuration file, not a boolean flag. Option C is wrong because `--encryption-provider` is not a valid flag; the encryption provider (e.g., aescbc) is specified inside the EncryptionConfiguration YAML, not as a separate command-line argument.

Practice this question →

8

MCQhard

An etcd cluster uses TLS for peer and client communication. Which command correctly tests connectivity to an etcd member with client certificate authentication?

A.etcdctl --endpoints=https://10.0.0.1:2379 --cert=/etc/etcd/etcd-client.crt endpoint health

B.etcdctl --endpoints=https://10.0.0.1:2379 --cacert=/etc/etcd/ca.crt --cert=/etc/etcd/etcd-client.crt --key=/etc/etcd/etcd-client.key endpoint health

C.etcdctl --endpoints=https://10.0.0.1:2379 --cacert=/etc/etcd/ca.crt endpoint health

D.etcdctl --endpoints=http://10.0.0.1:2379 endpoint health

AnswerB

Correct command with all necessary TLS flags.

Why this answer

Option B is correct because it provides all three required TLS components for mutual TLS (mTLS) authentication: the CA certificate (`--cacert`) to verify the server's identity, the client certificate (`--cert`) for the client's identity, and the client key (`--key`) to prove possession of the private key. The `endpoint health` command then performs a TLS handshake and checks the etcd member's health over HTTPS. Without any of these three, the connection will fail due to certificate validation errors or missing client authentication.

Exam trap

CNCF often tests the misconception that only the client certificate is needed for mTLS, causing candidates to forget the `--key` flag, or that only the CA certificate is sufficient for client authentication, leading them to omit the client certificate and key entirely.

How to eliminate wrong answers

Option A is wrong because it omits the `--cacert` flag, so the client cannot verify the server's TLS certificate against the trusted CA, causing a TLS handshake failure. Option C is wrong because it omits the `--cert` and `--key` flags, so the client cannot provide its own certificate for mutual TLS authentication, and the etcd server will reject the connection if client certificate authentication is enforced. Option D is wrong because it uses `http://` instead of `https://`, bypassing TLS entirely; if the etcd cluster requires TLS, this command will either be rejected or communicate over an unencrypted channel, failing the connectivity test.

Practice this question →

9

MCQmedium

A security auditor runs kube-bench on a Kubernetes node and reports that the check '1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive' fails. What is the most appropriate remediation?

A.Delete the API server manifest file

B.Run 'chmod 755 /etc/kubernetes/manifests/kube-apiserver.yaml'

C.Restart the kubelet service

D.Run 'chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml'

AnswerD

Correct. Setting permissions to 644 or more restrictive (e.g., 600) satisfies the benchmark.

Why this answer

Option D is correct because the CIS benchmark for Kubernetes requires the API server manifest file to have permissions of 644 or more restrictive (e.g., 600, 640, or 644) to prevent unauthorized modifications. Running 'chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml' sets the file to read-write for the owner and read-only for group and others, satisfying the benchmark. The kubelet automatically detects the change and reloads the static pod, so no restart is needed.

Exam trap

The trap here is that candidates often assume a service restart is required after a file permission change, but the kubelet automatically detects manifest file modifications, making a restart redundant and incorrect.

How to eliminate wrong answers

Option A is wrong because deleting the API server manifest file would remove the static pod definition, causing the API server to stop and the cluster to become unavailable. Option B is wrong because 'chmod 755' sets permissions to rwxr-xr-x, which is less restrictive than 644 (it grants execute permissions to all), failing the CIS check. Option C is wrong because restarting the kubelet service is unnecessary; the kubelet watches the manifest directory for changes and automatically reloads the static pod when the file permissions are updated.

Practice this question →

10

MCQmedium

You need to ensure that the kubelet only serves authenticated and authorized requests. Which flag(s) should be set on the kubelet?

A.--anonymous-auth=false and --authorization-mode=AlwaysAllow

B.--anonymous-auth=true and --authorization-mode=Webhook

C.--authenticated=true and --authorization=RBAC

D.--anonymous-auth=false and --authorization-mode=Webhook

AnswerD

These flags disable anonymous access and use webhook authorization via the API server.

Why this answer

Option D is correct because setting `--anonymous-auth=false` disallows unauthenticated requests to the kubelet, and `--authorization-mode=Webhook` delegates authorization decisions to an external service (e.g., the API server's SubjectAccessReview), ensuring that only authenticated and authorized requests are served. This combination enforces both authentication and authorization, which is required for hardening the kubelet.

Exam trap

CNCF often tests the misconception that `--authorization-mode=RBAC` is a valid kubelet flag, but the kubelet only supports `AlwaysAllow`, `Webhook`, and `AlwaysDeny` for authorization, and RBAC is configured on the API server, not directly on the kubelet.

How to eliminate wrong answers

Option A is wrong because `--authorization-mode=AlwaysAllow` bypasses all authorization checks, allowing any authenticated request to proceed, which violates the requirement to serve only authorized requests. Option B is wrong because `--anonymous-auth=true` allows unauthenticated requests, which directly contradicts the need to serve only authenticated requests. Option C is wrong because `--authenticated` is not a valid kubelet flag; the correct flag is `--anonymous-auth`, and `--authorization=RBAC` is not a valid flag (the correct flag is `--authorization-mode` and RBAC is not a supported mode for the kubelet; the kubelet supports `AlwaysAllow`, `Webhook`, and `AlwaysDeny`).

Practice this question →

11

MCQhard

A cluster has been configured with the NodeRestriction admission plugin. A developer tries to create a pod that uses a hostPath volume pointing to /var/log. The pod's nodeSelector is set to 'kubernetes.io/hostname: worker-1'. Which statement is true?

A.The pod will be created only if the node label matches the nodeSelector; the hostPath volume is irrelevant.

B.The pod will be rejected because hostPath volumes are not allowed by NodeRestriction.

C.The pod will be created because NodeRestriction does not restrict hostPath volumes.

D.The pod will be rejected because the nodeSelector conflicts with the NodeRestriction plugin.

AnswerC

NodeRestriction only restricts node self-updates, not hostPath.

Why this answer

The NodeRestriction admission plugin limits the node labels that a kubelet can set and restricts pods from modifying their node affinity to gain access to node-specific resources. However, it does not restrict the use of hostPath volumes. Therefore, a pod with a hostPath volume pointing to /var/log and a nodeSelector for 'worker-1' will be created, as long as the nodeSelector matches an existing node label and the hostPath volume is otherwise permitted by the PodSecurityPolicy or other security contexts.

Exam trap

The trap here is that candidates often confuse NodeRestriction with other admission plugins like PodSecurityPolicy or think it enforces broad security restrictions, when in fact it only targets node label and kubelet certificate behavior.

How to eliminate wrong answers

Option A is wrong because the hostPath volume is relevant: it must be allowed by the cluster's security policies (e.g., PodSecurityPolicy, OPA), but NodeRestriction does not block it. Option B is wrong because NodeRestriction does not restrict hostPath volumes; it only restricts node label modifications and kubelet self-approval of certificates. Option D is wrong because nodeSelector does not conflict with NodeRestriction; NodeRestriction does not evaluate nodeSelector values for conflicts.

Practice this question →

12

MCQhard

You have enabled etcd encryption at rest using an EncryptionConfiguration with aescbc provider. After applying the configuration, you create a new Secret. Which of the following is true regarding the encrypted Secret?

A.All Secrets are encrypted because the EncryptionConfiguration applies to all resources.

B.All Secrets in the cluster, including existing ones, are immediately encrypted.

C.Only the new Secret is encrypted; existing Secrets remain in plaintext.

D.The new Secret is stored in plaintext because aescbc is not a valid provider.

AnswerC

Encryption applies to writes; existing data is not re-encrypted without manual intervention.

Why this answer

When you apply an EncryptionConfiguration with aescbc provider, only newly created Secrets are encrypted at rest. Existing Secrets remain in plaintext because encryption is applied at write time; the API server does not retroactively re-encrypt data already stored in etcd. This is why option C is correct.

Exam trap

The trap here is that candidates assume encryption is applied retroactively to all existing data, but Kubernetes only encrypts data at write time, so existing Secrets remain unencrypted until they are updated or re-created.

How to eliminate wrong answers

Option A is wrong because the EncryptionConfiguration applies only to the resources listed in its `resources` field, not to all resources by default. Option B is wrong because etcd encryption is not retroactive; existing Secrets are not automatically re-encrypted when the configuration is applied. Option D is wrong because aescbc is a valid provider in Kubernetes (AES-CBC with PKCS#7 padding) and is commonly used for encryption at rest.

Practice this question →

13

MCQeasy

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

A.--anonymous-auth-enabled=false

B.--disable-anonymous-auth

C.--enable-anonymous-auth=false

D.--anonymous-auth=false

AnswerD

Correct. Setting --anonymous-auth=false prevents anonymous requests.

Why this answer

The correct flag to disable anonymous authentication on the kube-apiserver is `--anonymous-auth=false`. This flag explicitly sets the anonymous authentication mode to disabled, preventing unauthenticated requests from being processed. The kube-apiserver uses this boolean flag to control whether anonymous requests (those with no authentication credentials) are allowed, and setting it to `false` disables them entirely.

Exam trap

The trap here is that candidates often confuse the flag name with common patterns like `--enabled` or `--disable-` prefixes, but the kube-apiserver uses a simple boolean flag `--anonymous-auth` that must be set to `false` to disable anonymous access.

How to eliminate wrong answers

Option A is wrong because `--anonymous-auth-enabled=false` is not a valid kube-apiserver flag; the correct flag name is `--anonymous-auth`, not `--anonymous-auth-enabled`. Option B is wrong because `--disable-anonymous-auth` is not a recognized kube-apiserver flag; the kube-apiserver uses a boolean flag `--anonymous-auth` rather than a disable prefix. Option C is wrong because `--enable-anonymous-auth=false` is also not a valid flag; the kube-apiserver does not use an `--enable-` prefix for this setting, and the correct flag is simply `--anonymous-auth`.

Practice this question →

14

MCQeasy

Which kubectl command runs kube-bench against a Kubernetes cluster?

A.kubectl benchmark

B.kube-bench run

C.kube-bench scan

D.kubectl run kube-bench

AnswerB

The correct command to execute kube-bench is 'kube-bench run'. It runs the CIS benchmark checks and outputs results.

Why this answer

Option B is correct because `kube-bench run` is the actual command syntax for executing kube-bench, a CIS Kubernetes Benchmark assessment tool. Kube-bench is a standalone binary, not a kubectl subcommand, and it runs checks against the cluster's configuration files and processes. The `run` subcommand triggers the benchmark evaluation.

Exam trap

CNCF often tests the distinction between kubectl commands and standalone security tools like kube-bench, trapping candidates who assume all security tasks are performed via kubectl subcommands.

How to eliminate wrong answers

Option A is wrong because `kubectl benchmark` is not a valid kubectl command; kubectl has no built-in benchmark subcommand. Option C is wrong because `kube-bench scan` is not a valid subcommand; kube-bench uses `run` to execute the benchmark, not `scan`. Option D is wrong because `kubectl run kube-bench` would attempt to run a pod named 'kube-bench' using a container image, not execute the kube-bench binary directly against the host's configuration files.

Practice this question →

15

MCQmedium

What is the purpose of the Kubernetes Dashboard?

A.To provide a command-line interface for cluster management

B.To provide a web-based user interface for deploying and managing applications

C.To monitor cluster performance metrics

D.To enforce security policies on the cluster

AnswerB

The Dashboard allows users to manage applications, view logs, and more via a GUI.

Why this answer

The Kubernetes Dashboard is a web-based user interface that allows users to deploy containerized applications to a Kubernetes cluster, troubleshoot them, and manage the cluster resources. It provides a graphical alternative to the kubectl command-line tool, enabling operations such as viewing workloads, scaling deployments, and editing resources through a browser.

Exam trap

CNCF often tests the misconception that the Dashboard is a monitoring or security tool, but the CKS exam emphasizes that its role is purely a web UI for cluster management, and that security enforcement is the job of admission controllers and RBAC, not the Dashboard itself.

How to eliminate wrong answers

Option A is wrong because the command-line interface for cluster management is provided by kubectl, not the Dashboard. Option C is wrong because while the Dashboard can display some basic metrics (like CPU/memory usage) via integrations like metrics-server, its primary purpose is not performance monitoring; dedicated tools like Prometheus and Grafana are used for comprehensive cluster monitoring. Option D is wrong because security policies (e.g., Pod Security Standards, RBAC, NetworkPolicies) are enforced by the Kubernetes API server and admission controllers, not by the Dashboard; the Dashboard itself is subject to those policies.

Practice this question →

16

MCQhard

You are auditing RBAC and find a ClusterRoleBinding that grants cluster-admin to a service account. Which command should you run to list all ClusterRoleBindings in the cluster?

A.kubectl get clusterrolebinding

B.kubectl get clusterrolebindings

C.kubectl get clusterrolebindings.rbac.authorization.k8s.io

D.kubectl get clusterrolebinding --all-namespaces

AnswerB, C

This is the standard command to list ClusterRoleBindings.

Why this answer

The correct command to list all ClusterRoleBindings in the cluster is `kubectl get clusterrolebindings` (option B). This uses the standard plural form of the resource name, which is the default and recommended way to query RBAC resources. The command retrieves all ClusterRoleBindings across the cluster, as ClusterRoleBindings are non-namespaced resources.

Exam trap

The trap here is that candidates may think `--all-namespaces` is needed for cluster-scoped resources, but it is only applicable to namespaced resources, and using the singular form `clusterrolebinding` will cause an error.

How to eliminate wrong answers

Option A is wrong because `kubectl get clusterrolebinding` uses the singular form, which is not a valid kubectl resource name; kubectl requires the plural form to list resources. Option D is wrong because `--all-namespaces` is redundant for ClusterRoleBindings, as they are cluster-scoped resources and not bound to any namespace; the flag has no effect and is misleading. Option C is also marked as correct in the question, but the prompt asks for the single correct answer; however, `kubectl get clusterrolebindings.rbac.authorization.k8s.io` is technically valid as it uses the fully qualified resource name, but the simpler plural form is the standard and expected answer.

Practice this question →

17

MCQeasy

Which kubectl command will disable anonymous authentication on a kube-apiserver?

A.kubectl edit pod kube-apiserver -n kube-system and add --anonymous-auth=false

B.kubectl run --image=k8s.gcr.io/kube-apiserver --env=ANONYMOUS_AUTH=false

C.kubectl patch node <nodename> -p '{"spec":{"anonymousAuth":false}}'

D.kubectl set env deployment/kube-apiserver -n kube-system ANONYMOUS_AUTH=false

AnswerA

This command allows editing the kube-apiserver pod to set the flag.

Why this answer

Option A is correct because the kube-apiserver is a static pod managed by the kubelet, and its configuration is defined in a manifest file located in /etc/kubernetes/manifests/ on the control-plane node. Editing the pod directly with `kubectl edit pod kube-apiserver -n kube-system` allows you to add the `--anonymous-auth=false` flag to the kube-apiserver command, which disables anonymous authentication by rejecting requests from unauthenticated users. This change is automatically applied by the kubelet, which restarts the static pod with the updated configuration.

Exam trap

CNCF often tests the misconception that the kube-apiserver can be configured via environment variables or that it runs as a Deployment, when in fact it is a static pod configured solely through command-line arguments in its manifest file.

How to eliminate wrong answers

Option B is wrong because `kubectl run` creates a new pod from an image, not modify the existing kube-apiserver static pod, and environment variables like `ANONYMOUS_AUTH=false` are not recognized by the kube-apiserver binary (it uses command-line flags, not env vars). Option C is wrong because `kubectl patch node` modifies the Node object's spec, but the kube-apiserver's authentication settings are not part of the Node spec; the `anonymousAuth` field does not exist in the Node API. Option D is wrong because `kubectl set env` sets environment variables on a Deployment, but the kube-apiserver is a static pod, not a Deployment, and the kube-apiserver does not read authentication settings from environment variables.

Practice this question →

18

MCQmedium

Which kubectl command creates a Role named 'pod-reader' that allows only 'get', 'list', and 'watch' on pods in namespace 'ns1'?

A.kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods

B.kubectl create role pod-reader --verb=get,list,watch --resource=pods --namespace=ns1

C.kubectl create role pod-reader --verb=* --resource=pods --namespace=ns1

D.kubectl create rolebinding pod-reader --role=pod-reader --serviceaccount=ns1:default

AnswerB

This command creates the role with specified verbs and resource.

Why this answer

Option B is correct because the `kubectl create role` command creates a Role (namespaced resource) with the specified verbs and resources in the given namespace. The `--verb=get,list,watch` and `--resource=pods` flags define the exact permissions, and `--namespace=ns1` scopes the Role to that namespace, which matches the requirement.

Exam trap

The trap here is that candidates often confuse `kubectl create role` with `kubectl create clusterrole` (option A) or mistakenly use `--verb=*` (option C) thinking it means 'only these verbs', when in fact it grants all verbs, violating the principle of least privilege.

How to eliminate wrong answers

Option A is wrong because `kubectl create clusterrole` creates a ClusterRole, which is cluster-scoped, not namespaced; it would grant permissions across all namespaces, not just 'ns1'. Option C is wrong because `--verb=*` grants all verbs (including create, update, delete, etc.), not just 'get', 'list', and 'watch'. Option D is wrong because `kubectl create rolebinding` creates a RoleBinding (binding a role to a subject), not a Role; it also references a role named 'pod-reader' that does not exist yet, and the command does not create the Role itself.

Practice this question →

19

MCQmedium

A security scan reports that the etcd cluster does not encrypt data at rest. The cluster uses aescbc encryption. Which resource type should be created to configure encryption at rest?

A.ConfigMap

B.ClusterRole

C.EncryptionConfiguration

D.Secret

AnswerC

EncryptionConfiguration is the correct resource to define encryption providers and keys.

Why this answer

The correct resource type is an EncryptionConfiguration, which is a Kubernetes API object used to configure encryption at rest for etcd. When the aescbc provider is specified in the EncryptionConfiguration, Kubernetes encrypts secret data before writing it to etcd, ensuring data at rest is protected. This configuration is passed to the kube-apiserver via the --encryption-provider-config flag.

Exam trap

The trap here is that candidates often confuse the resource that stores sensitive data (Secret) with the resource that configures encryption at rest (EncryptionConfiguration), or they mistakenly think a ConfigMap can define encryption settings because it holds configuration data.

How to eliminate wrong answers

Option A is wrong because a ConfigMap is used to store non-confidential configuration data as key-value pairs, not to define encryption providers or settings for etcd encryption at rest. Option B is wrong because a ClusterRole defines permissions for RBAC (Role-Based Access Control) and has no relation to configuring encryption providers for etcd. Option D is wrong because a Secret is used to store sensitive data like passwords or tokens, but it is not the resource that configures how etcd data is encrypted; the EncryptionConfiguration resource defines the encryption providers and keys.

Practice this question →

20

Multi-Selecthard

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

Select 3 answers

A.Enable RBAC authorization on etcd

B.Disable the etcd API and use only the embedded etcd in control plane

C.Use firewall rules to limit access to etcd port 2379

D.Use TLS client certificates to authenticate clients

E.Encrypt etcd data at rest using EncryptionConfiguration

AnswersA, C, D

etcd supports RBAC to control which users can perform operations.

Why this answer

Option A is correct because etcd supports Role-Based Access Control (RBAC) natively since version 3.0. By enabling RBAC on etcd, you can define roles and permissions to restrict which users or processes can read or write to specific keys or prefixes. This is a direct method to secure the etcd datastore against unauthorized access.

Exam trap

CNCF often tests the distinction between access control (who can connect to etcd) and data protection (encryption at rest), leading candidates to incorrectly select encryption as a method to restrict access.

Practice this question →

21

MCQmedium

You run 'kubectl auth can-i --list --as=system:serviceaccount:kube-system:my-sa' and see that my-sa has cluster-admin access. What is the BEST way to reduce privileges?

A.Delete the service account and create a new one

B.Delete the ClusterRoleBinding that grants cluster-admin to the service account

C.Create a new RoleBinding with fewer privileges in the kube-system namespace

D.Modify the ClusterRole 'cluster-admin' to have fewer permissions

AnswerB

Removing the binding eliminates the excessive privileges.

Why this answer

Option B is correct because the service account 'my-sa' has cluster-admin privileges due to a ClusterRoleBinding that binds it to the 'cluster-admin' ClusterRole. Deleting that specific ClusterRoleBinding removes the excessive permissions without affecting other subjects or the underlying ClusterRole, which is shared and may be needed by other users or components. This is the most targeted and least disruptive approach to reduce privileges.

Exam trap

CNCF often tests the misconception that modifying a ClusterRole or recreating a service account is sufficient to revoke privileges, when in reality the binding is the source of the permission grant and must be removed directly.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the service account does not remove the existing ClusterRoleBinding; the new service account would still be bound to the same ClusterRoleBinding and retain cluster-admin access. Option C is wrong because creating a new RoleBinding with fewer privileges in the kube-system namespace does not revoke the existing ClusterRoleBinding; the service account would still have cluster-admin access from the binding, and RoleBindings are namespace-scoped and cannot override a ClusterRoleBinding. Option D is wrong because modifying the 'cluster-admin' ClusterRole would affect all subjects bound to it, including other service accounts and users, potentially breaking critical system components that rely on its permissions.

Practice this question →

22

MCQeasy

To disable service account token automount for a pod, which field should be set to false in the pod spec?

A.automountServiceAccountToken

B.serviceAccountToken

C.automountToken

D.enableServiceAccountToken

AnswerA

Setting this to false prevents automatic token mounting.

Why this answer

In Kubernetes, the `automountServiceAccountToken` field in the Pod spec, when set to `false`, prevents the automatic mounting of the service account token (a JWT) into the pod's containers. This is a security hardening measure to reduce the attack surface, as the token could be used to authenticate to the Kubernetes API server if compromised. The default behavior is `true`, meaning the token is automatically mounted unless explicitly disabled.

Exam trap

The trap here is that candidates confuse the Pod spec field name with the ServiceAccount-level field or invent plausible-sounding names like `automountToken` or `enableServiceAccountToken`, while the exact API field is `automountServiceAccountToken`.

How to eliminate wrong answers

Option B is wrong because `serviceAccountToken` is not a valid field in the Pod spec; the correct field is `automountServiceAccountToken`. Option C is wrong because `automountToken` is not a recognized Kubernetes field; the exact API field name is `automountServiceAccountToken`. Option D is wrong because `enableServiceAccountToken` does not exist in the Pod spec; the field to disable automount is `automountServiceAccountToken`, not an enable/disable toggle.

Practice this question →

23

MCQhard

After setting up etcd encryption at rest using EncryptionConfiguration with aescbc, which resource stores the encryption key?

A.A ConfigMap in the etcd namespace

B.A Secret in the kube-system namespace

C.The EncryptionConfiguration file itself

D.An annotation on the etcd pod

AnswerC

The encryption key is defined in the EncryptionConfiguration YAML file under the 'keys' section. This file is passed to the API server via --encryption-provider-config.

Why this answer

When etcd encryption at rest is configured via an EncryptionConfiguration file, the encryption key is defined within that file itself under the 'keys' field for the specified provider (e.g., aescbc). The EncryptionConfiguration file is passed to the kube-apiserver via the --encryption-provider-config flag, and the key material is read from this file at startup. No separate Secret or ConfigMap stores the key; the file is the authoritative source.

Exam trap

The trap here is that candidates assume encryption keys must be stored in a Kubernetes Secret (like other secrets in kube-system), but the EncryptionConfiguration file itself is the sole storage for the key material, and it is not managed as a Kubernetes resource.

How to eliminate wrong answers

Option A is wrong because there is no 'etcd' namespace in Kubernetes; etcd runs as a static pod or systemd service, and ConfigMaps are not used to store encryption keys for etcd. Option B is wrong because while Secrets in kube-system store sensitive data like service account tokens, the etcd encryption key is not stored as a Kubernetes Secret; it resides in the EncryptionConfiguration file. Option D is wrong because annotations on the etcd pod are metadata only and cannot store the encryption key; the key is not injected via annotations.

Practice this question →

24

MCQmedium

Which etcd security measure should be implemented to ensure only authorized clients can access the etcd cluster?

A.Enable anonymous authentication on etcd

B.Configure etcd to listen on localhost only

C.Enable TLS client-to-server authentication

D.Use etcd RBAC with role-based access control

AnswerC

TLS ensures that only clients presenting valid certificates can connect to etcd.

Why this answer

Option C is correct because enabling TLS client-to-server authentication (mutual TLS) ensures that only clients presenting a valid certificate signed by a trusted Certificate Authority (CA) can communicate with the etcd cluster. This cryptographically verifies the client's identity, preventing unauthorized access and man-in-the-middle attacks. Without client certificate validation, any client with network access could potentially interact with etcd, compromising the Kubernetes control plane.

Exam trap

CNCF often tests the distinction between authentication (verifying identity) and authorization (controlling actions), so candidates may mistakenly choose RBAC (Option D) thinking it controls access, when in fact TLS client authentication is the prerequisite for ensuring only authorized clients can connect.

How to eliminate wrong answers

Option A is wrong because enabling anonymous authentication on etcd would allow unauthenticated clients to access the cluster, directly contradicting the requirement to restrict access to authorized clients only. Option B is wrong because configuring etcd to listen on localhost only restricts network access to the local machine, which is impractical for a multi-node etcd cluster and does not provide authentication or authorization for clients that do have access. Option D is wrong because etcd RBAC (role-based access control) controls what operations an authenticated user can perform, but it does not authenticate the client itself; without TLS client authentication, an attacker could still connect and attempt to exploit RBAC misconfigurations.

Practice this question →

25

Multi-Selectmedium

Which TWO of the following are recommended CIS benchmark practices for securing etcd? (Choose two.)

Select 2 answers

A.Use TLS certificates for client-to-server communication

B.Run etcd as root user

C.Disable authentication for etcd to reduce latency

D.Enable encryption at rest

E.Expose etcd to the public internet for easier management

AnswersA, D

CIS recommends using TLS to secure communication between the API server and etcd.

Why this answer

Option A is correct because the CIS benchmark for etcd recommends using TLS certificates for client-to-server communication to ensure data in transit is encrypted and authenticated. This prevents man-in-the-middle attacks and unauthorized access to the etcd cluster, which stores critical cluster state and secrets.

Exam trap

CNCF often tests the misconception that disabling authentication reduces latency and is acceptable for performance, but the CIS benchmark explicitly requires authentication and encryption for all etcd communication, and candidates may overlook the security implications of running etcd as root or exposing it publicly.

Practice this question →

26

MCQmedium

To enforce Pod Security Standards at the namespace level, which admission plugin must be enabled on the API server?

A.SecurityContextDeny

B.NodeRestriction

C.PodSecurityPolicy

D.PodSecurity

AnswerD

This plugin enforces Pod Security Standards.

Why this answer

Pod Security Standards (PSS) are enforced at the namespace level using the PodSecurity admission plugin, which was introduced in Kubernetes v1.23 and graduated to stable in v1.25. This plugin evaluates pods against the predefined security levels (privileged, baseline, restricted) based on labels on the namespace, replacing the deprecated PodSecurityPolicy.

Exam trap

CNCF often tests the distinction between the deprecated PodSecurityPolicy (PSP) and the current PodSecurity admission plugin, leading candidates to mistakenly select PSP because they recall 'Pod Security' in the name, but PSP is no longer available in recent Kubernetes versions.

How to eliminate wrong answers

Option A is wrong because SecurityContextDeny is a deprecated admission plugin that only rejects pods with specific security context settings (like privileged containers) but does not implement the three-tier Pod Security Standards. Option B is wrong because NodeRestriction is an admission plugin that limits the kubelet's ability to modify node and pod objects, not related to enforcing pod security policies. Option C is wrong because PodSecurityPolicy (PSP) is a deprecated admission plugin that was removed in Kubernetes v1.25; it enforced security policies at the cluster level via PSP resources, not at the namespace level using Pod Security Standards.

Practice this question →

27

Multi-Selectmedium

Which TWO of the following are recommended settings from the CIS Kubernetes Benchmark for the kube-apiserver? (Select 2)

Select 2 answers

A.--anonymous-auth=false

B.--audit-log-path=/var/log/kubernetes/audit.log

C.--client-cert-auth=true

D.--profiling=false

E.--insecure-bind-address=0.0.0.0

AnswersA, B

Disables anonymous authentication.

Why this answer

Option A is correct because disabling anonymous authentication with `--anonymous-auth=false` ensures that all requests to the kube-apiserver must be authenticated, preventing unauthenticated access. This is a key hardening measure recommended by the CIS Kubernetes Benchmark to enforce identity verification for every API call.

Exam trap

CNCF often tests the distinction between flags that apply to different control plane components; candidates mistakenly apply profiling or insecure bind settings from other components to the kube-apiserver, or confuse `--client-cert-auth` with the actual `--client-ca-file` flag.

Practice this question →

28

MCQmedium

You have a requirement to encrypt secrets at rest in etcd. Which resource and apiVersion should be used?

A.EtcdEncryption with apiVersion apiserver.config.k8s.io/v1beta1

B.EncryptionConfig with apiVersion v1

C.SecretEncryption with apiVersion v1

D.EncryptionConfiguration with apiVersion apiserver.config.k8s.io/v1

AnswerD

This is the correct resource for configuring encryption at rest.

Why this answer

Option D is correct because the Kubernetes API server uses an `EncryptionConfiguration` resource with `apiVersion apiserver.config.k8s.io/v1` to define how secrets and other resources are encrypted at rest in etcd. This resource specifies providers (e.g., `aescbc`, `secretbox`) and keys, and is loaded via the `--encryption-provider-config` flag on the API server. The `v1` version is the stable, production-ready API version for this configuration.

Exam trap

CNCF often tests the exact resource name and API group, and the trap here is that candidates confuse `EncryptionConfiguration` with made-up names like `EtcdEncryption` or `SecretEncryption`, or incorrectly assume it belongs to the core `v1` API group instead of `apiserver.config.k8s.io`.

How to eliminate wrong answers

Option A is wrong because `EtcdEncryption` is not a valid Kubernetes resource; the correct resource is `EncryptionConfiguration`. Option B is wrong because `EncryptionConfig` with `apiVersion v1` does not exist; the resource is `EncryptionConfiguration` under `apiserver.config.k8s.io`, not core `v1`. Option C is wrong because `SecretEncryption` is not a real resource; Kubernetes uses `EncryptionConfiguration` to configure encryption at rest, not a resource named after the object type.

Practice this question →

29

MCQhard

You are tasked with securing a Kubernetes cluster. You want to ensure that the kubelet only serves APIs that are explicitly allowed and that it does not allow anonymous requests. Which kubelet configuration flags should you set?

A.--anonymous-auth=false and --authorization-mode=RBAC

B.--anonymous-auth=true and --authorization-mode=ABAC

C.--anonymous-auth=false and --authorization-mode=AlwaysAllow

D.--anonymous-auth=false and --authorization-mode=Webhook

AnswerD

Disables anonymous auth and uses webhook authorization.

Why this answer

Option D is correct because setting `--anonymous-auth=false` disables anonymous requests to the kubelet, and `--authorization-mode=Webhook` delegates authorization decisions to an external service (e.g., the API server), allowing fine-grained control over which APIs the kubelet serves. This combination ensures that only authenticated, authorized requests are processed, aligning with the principle of least privilege.

Exam trap

The trap here is that candidates confuse kubelet authorization modes with API server authorization modes, mistakenly selecting `RBAC` (Option A) which is not a valid kubelet flag, while overlooking that `Webhook` is the correct mode to enforce RBAC-like policies on the kubelet.

How to eliminate wrong answers

Option A is wrong because `--authorization-mode=RBAC` is not a valid kubelet flag; the kubelet supports `AlwaysAllow`, `Webhook`, and `ABAC` modes, but RBAC is an API server authorization mode, not a kubelet one. Option B is wrong because `--anonymous-auth=true` allows anonymous requests, which contradicts the requirement to disallow them, and `--authorization-mode=ABAC` is deprecated and less secure than Webhook for dynamic authorization. Option C is wrong because `--authorization-mode=AlwaysAllow` permits all authenticated requests without any authorization checks, failing to restrict APIs to only those explicitly allowed.

Practice this question →

30

MCQmedium

Which command can be used to check if the API server has anonymous authentication enabled?

A.kubectl get clusterrole cluster-admin -o yaml

B.kubectl describe pod kube-apiserver -n kube-system | grep anonymous-auth

C.kubectl get node -o yaml

D.kubectl auth can-i --list --as=system:anonymous

AnswerB

This shows the kube-apiserver's flags including anonymous-auth.

Why this answer

Option B is correct because the kube-apiserver pod's manifest (or its runtime configuration) contains the `--anonymous-auth` flag. By inspecting the pod's YAML with `kubectl describe pod kube-apiserver -n kube-system` and grepping for `anonymous-auth`, you can see whether the flag is set to `true` (enabled) or `false` (disabled). This is the direct way to check the API server's runtime configuration for anonymous authentication.

Exam trap

CNCF often tests the misconception that RBAC commands (like `kubectl auth can-i`) can detect server-level flags, when in fact they only test authorization after authentication has already succeeded, making them useless for checking if anonymous auth is enabled.

How to eliminate wrong answers

Option A is wrong because `kubectl get clusterrole cluster-admin -o yaml` shows the permissions of the `cluster-admin` ClusterRole, which has no bearing on whether the API server accepts anonymous requests; anonymous authentication is a server-level flag, not a RBAC setting. Option C is wrong because `kubectl get node -o yaml` displays node metadata and status, which contains no information about the API server's authentication configuration. Option D is wrong because `kubectl auth can-i --list --as=system:anonymous` checks what actions the `system:anonymous` user can perform *after* authentication, but it does not reveal whether anonymous authentication is enabled; if anonymous auth is disabled, the command would fail with an authentication error, but the command itself does not inspect the server's flag.

Practice this question →

31

MCQmedium

An administrator runs 'kubectl describe nodes' and notices that the node status shows 'Ready,SchedulingDisabled'. What is the most likely cause?

A.The kubelet is not running

B.The node was cordoned using 'kubectl cordon <node>'

C.The node has insufficient resources

D.The node is tainted with NoSchedule

AnswerB

Cordoning a node marks it as unschedulable, resulting in SchedulingDisabled.

Why this answer

The 'Ready,SchedulingDisabled' status indicates that the node is marked as unschedulable for new pods while remaining fully operational. This is exactly what happens when an administrator runs 'kubectl cordon <node>', which sets the node's 'spec.unschedulable' field to true. The kubelet continues to run and report readiness, but the scheduler will skip the node when placing new pods.

Exam trap

CNCF often tests the distinction between taints (which affect scheduling based on tolerations) and cordoning (which makes the node completely unschedulable), leading candidates to confuse taint-based scheduling restrictions with the explicit unschedulable flag.

How to eliminate wrong answers

Option A is wrong because if the kubelet were not running, the node status would be 'NotReady' or 'Unknown', not 'Ready,SchedulingDisabled'. Option C is wrong because insufficient resources would cause the node to report conditions like 'MemoryPressure' or 'DiskPressure', not the specific 'SchedulingDisabled' marker. Option D is wrong because a NoSchedule taint prevents pod scheduling via the scheduler's taint-toleration mechanism, but the node status would still show 'Ready' without the 'SchedulingDisabled' suffix; the node remains schedulable for pods that tolerate the taint.

Practice this question →

32

MCQeasy

Which admission plugin should be enabled on the kubelet to ensure it only registers nodes and sets labels as allowed by the Node REST API?

A.PodSecurity

B.NodeRestriction

C.DenyEscalatingExec

D.AlwaysPullImages

AnswerB

NodeRestriction limits the kubelet's self-modification capabilities, enhancing security.

Why this answer

The NodeRestriction admission plugin is the correct choice because it limits the kubelet's ability to modify node and pod labels, ensuring that nodes can only register themselves and set labels that are explicitly allowed by the Node REST API. This plugin enforces a whitelist of labels that the kubelet can set, preventing privilege escalation through label manipulation.

Exam trap

CNCF often tests the NodeRestriction plugin by pairing it with other admission controllers like PodSecurity or AlwaysPullImages, leading candidates to confuse node-level restrictions with pod-level security policies.

How to eliminate wrong answers

Option A is wrong because PodSecurity is an admission plugin that enforces Pod Security Standards (e.g., privileged, baseline, restricted) on pods, not node registration or label restrictions. Option C is wrong because DenyEscalatingExec is a deprecated admission plugin that prevents exec and attach commands to pods with escalated privileges, unrelated to node registration. Option D is wrong because AlwaysPullImages forces every pod to pull container images with the specified pull policy, which does not control node registration or label setting.

Practice this question →

33

MCQhard

You need to encrypt Kubernetes secrets at rest using aescbc. Which YAML snippet defines the EncryptionConfiguration correctly?

A.apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: c2VjcmV0LWtleS0zMi1ieXRlcw== - identity: {}

B.apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: my-plain-text-key

C.apiVersion: v1 kind: EncryptionConfig resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: c2VjcmV0LWtleS0zMi1ieXRlcw==

D.apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - secretbox: keys: - name: key1 secret: c2VjcmV0LWtleS0zMi1ieXRlcw==

AnswerA

Correct structure with aescbc and identity fallback.

Why this answer

Option A is correct because it defines an EncryptionConfiguration with the correct apiVersion (apiserver.config.k8s.io/v1), kind (EncryptionConfiguration), and a valid provider list. It uses the aescbc provider with a base64-encoded key (c2VjcmV0LWtleS0zMi1ieXRlcw==) for encrypting secrets, and includes the identity provider as a fallback to allow reading existing unencrypted data. This configuration ensures that secrets are encrypted at rest using AES-CBC with a properly encoded 32-byte key.

Exam trap

CNCF often tests the requirement that the aescbc provider's secret must be base64-encoded (not plain text) and that the correct apiVersion/kind must be used, leading candidates to pick options with plain-text keys or wrong resource types.

How to eliminate wrong answers

Option B is wrong because the secret value for the aescbc provider must be base64-encoded, not a plain-text key like 'my-plain-text-key'; Kubernetes expects the key to be base64-decoded to obtain the raw 32-byte key for AES-CBC. Option C is wrong because it uses an incorrect apiVersion 'v1' and kind 'EncryptionConfig' — the correct apiVersion is 'apiserver.config.k8s.io/v1' and kind is 'EncryptionConfiguration'. Option D is wrong because it uses the 'secretbox' provider, which implements XSalsa20-Poly1305 encryption, not AES-CBC; the question specifically requires aescbc.

Practice this question →

34

Multi-Selecthard

Which THREE of the following are valid methods to disable automount of service account tokens for a pod?

Select 3 answers

A.Set --service-account-issuer flag on API server

B.Set env: - name: KUBERNETES_SERVICE_ACCOUNT_TOKEN to false

C.Set automountServiceAccountToken: false in the ServiceAccount YAML

D.Set spec.automountServiceAccountToken: false in the Pod spec

E.Use the 'default' service account with automount disabled

AnswersC, D, E

Correct service account level setting.

Why this answer

Option C is correct because setting `automountServiceAccountToken: false` in the ServiceAccount YAML disables automatic mounting of the service account token for all pods that use that ServiceAccount. This is a declarative way to prevent the Kubernetes API server from injecting the token volume into pods, which is a key security hardening step to reduce the attack surface from compromised pods.

Exam trap

CNCF often tests the distinction between the Pod spec field (`spec.automountServiceAccountToken`) and the ServiceAccount field, and candidates may incorrectly think that environment variables or API server flags can disable token mounting, when only the `automountServiceAccountToken` boolean field in the Pod or ServiceAccount spec is valid.

Practice this question →

35

MCQmedium

A security audit reveals that a service account in the 'default' namespace has been granted cluster-admin privileges via a ClusterRoleBinding. What is the best mitigation?

A.Disable the service account token automount

B.Delete the service account

C.Modify the ClusterRoleBinding to use a less privileged role

D.Set --authorization-mode=AlwaysDeny

AnswerC

The best approach is to follow least-privilege: bind the service account to a role with only the necessary permissions.

Why this answer

Option C is correct because the best practice is to apply the principle of least privilege: instead of deleting the service account or disabling its token, you should modify the ClusterRoleBinding to bind the service account to a ClusterRole with only the permissions it actually needs. This retains the service account's functionality while removing excessive cluster-admin privileges, which grant unrestricted access to all cluster resources.

Exam trap

The trap here is that candidates often think disabling the token automount or deleting the service account removes the RBAC permissions, but in reality, the ClusterRoleBinding itself must be updated or deleted to actually revoke the granted privileges.

How to eliminate wrong answers

Option A is wrong because disabling the service account token automount (e.g., via automountServiceAccountToken: false) prevents the token from being mounted into pods, but it does not revoke the already-granted cluster-admin privileges; the ClusterRoleBinding remains in effect. Option B is wrong because deleting the service account removes the identity, but any pods or workloads that depend on it will fail, and the ClusterRoleBinding would become orphaned (pointing to a non-existent subject), which is a disruptive and incomplete fix. Option D is wrong because setting --authorization-mode=AlwaysDeny on the API server would deny all requests cluster-wide, breaking all administrative and workload operations, and is not a targeted mitigation for an over-privileged binding.

Practice this question →

36

MCQmedium

You are reviewing RBAC permissions and notice a ClusterRoleBinding that binds the cluster-admin role to a service account in the 'monitoring' namespace. What is the best practice recommendation?

A.Keep the binding as it is required for monitoring

B.Delete the service account

C.Replace cluster-admin with a custom Role granting only necessary permissions

D.Change the binding to a RoleBinding in the monitoring namespace

AnswerC

This follows least-privilege principle.

Why this answer

Option C is correct because the principle of least privilege dictates that a service account should only have the permissions necessary for its function. The cluster-admin role grants superuser access across the entire cluster, which is excessive for a monitoring service account. Replacing it with a custom Role that includes only the required API operations (e.g., get, list, watch on pods and nodes) reduces the attack surface and aligns with Kubernetes security best practices.

Exam trap

CNCF often tests the misconception that a RoleBinding can replace a ClusterRoleBinding for cluster-scoped tasks, but a RoleBinding cannot grant access to cluster-scoped resources like nodes or persistent volumes, so candidates must recognize when a ClusterRoleBinding is necessary even after reducing permissions.

How to eliminate wrong answers

Option A is wrong because keeping a cluster-admin binding for a monitoring service account violates the principle of least privilege and unnecessarily exposes the cluster to privilege escalation if the service account is compromised. Option B is wrong because deleting the service account would break the monitoring functionality; the correct approach is to adjust its permissions, not remove it entirely. Option D is wrong because changing to a RoleBinding in the monitoring namespace would restrict permissions to that namespace only, but the monitoring service account likely needs cluster-scoped access (e.g., to read node metrics) and a RoleBinding cannot grant cluster-scoped permissions.

Practice this question →

37

MCQhard

A security policy requires that all communication to etcd be encrypted. Which two components must be configured with TLS certificates to achieve this? (Select two)

A.kubelet

B.kube-apiserver

C.kube-scheduler

D.kube-controller-manager

E.etcd

AnswerB, E

The API server connects to etcd as a client.

Why this answer

The kube-apiserver is the only Kubernetes control plane component that directly communicates with etcd. To encrypt this communication, TLS certificates must be configured on both the kube-apiserver (as the client) and etcd (as the server). The kube-apiserver presents its client certificate to etcd, and etcd presents its server certificate to the kube-apiserver, establishing a mutually authenticated TLS session.

Exam trap

The trap here is that candidates often assume all control plane components (scheduler, controller-manager) communicate directly with etcd, but in reality only the kube-apiserver interacts with etcd, while the others only talk to the apiserver.

How to eliminate wrong answers

Option A is wrong because the kubelet communicates with the kube-apiserver, not directly with etcd, so its TLS configuration is for node-to-apiserver encryption, not etcd communication. Option C is wrong because the kube-scheduler communicates only with the kube-apiserver via HTTPS, not directly with etcd, and thus does not require TLS certificates for etcd encryption. Option D is wrong because the kube-controller-manager also communicates solely with the kube-apiserver, not with etcd directly, so its TLS setup is irrelevant to encrypting etcd traffic.

Practice this question →

38

MCQmedium

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

A.--audit-log-path and --audit-log-maxage

B.--audit-policy-file and --audit-log-maxbackup

C.--audit-log-path and --audit-policy-file

D.--audit-log-path and --authorization-mode=RBAC

AnswerC

Correct. Both are required.

Why this answer

Option C is correct because to enable audit logging in the Kubernetes API server, you must specify both an audit policy file (using --audit-policy-file) to define which events should be logged and at what level, and a log file path (using --audit-log-path) to specify where the audit logs should be written. Without the policy file, the API server does not know which requests to audit; without the log path, the audit events have no output destination.

Exam trap

CNCF often tests the distinction between mandatory flags (--audit-log-path and --audit-policy-file) and optional retention flags (--audit-log-maxage, --audit-log-maxbackup, --audit-log-maxsize), leading candidates to select options that include only retention flags or mix authorization flags with audit flags.

How to eliminate wrong answers

Option A is wrong because --audit-log-maxage is an optional flag that controls the maximum number of days to retain old audit log files, but it is not required to enable audit logging; the two mandatory flags are --audit-log-path and --audit-policy-file. Option B is wrong because --audit-log-maxbackup is also an optional flag that sets the maximum number of old audit log files to retain, and it does not replace the need for --audit-log-path or --audit-policy-file. Option D is wrong because --authorization-mode=RBAC is used to enable Role-Based Access Control for authorization, not for audit logging; audit logging requires the policy file and log path flags.

Practice this question →

39

MCQeasy

Which kubectl command checks the CIS Benchmark compliance of a cluster node using the kube-bench tool?

A.kubectl apply -f job.yaml

B.kubectl kube-bench

C.kubectl run kube-bench --image=aquasec/kube-bench

D.kube-bench run --targets=node

AnswerA

kube-bench is often deployed as a Kubernetes Job; applying the job YAML runs the benchmark.

Why this answer

Option A is correct because kube-bench runs as a Kubernetes Job, and the standard way to execute it against a cluster node is to apply a Job YAML manifest that runs the aquasec/kube-bench image. This Job performs CIS Benchmark checks on the node where it is scheduled, and the results are output to the Job's logs. The `kubectl apply -f job.yaml` command deploys the pre-configured Job, which is the recommended method for running kube-bench in a cluster context.

Exam trap

The trap here is that candidates confuse running a container directly with `kubectl run` versus deploying a proper Job manifest, or they assume `kubectl` has a native kube-bench subcommand, when in fact kube-bench must be run as a Kubernetes workload (typically a Job) to comply with the CIS Benchmark scanning methodology.

How to eliminate wrong answers

Option B is wrong because `kubectl kube-bench` is not a valid kubectl subcommand; kubectl does not have a built-in kube-bench plugin, and this command would fail. Option C is wrong because `kubectl run kube-bench --image=aquasec/kube-bench` creates a Pod, not a Job, and kube-bench is designed to run as a Job to properly handle completion and logging; a Pod may not terminate correctly or provide the expected output format. Option D is wrong because `kube-bench run --targets=node` is a direct command-line invocation of the kube-bench binary, not a kubectl command, and the question specifically asks for a kubectl command.

Practice this question →

40

MCQmedium

An administrator discovers that a container has been running with root privileges despite a PodSecurityPolicy that should prevent it. What is the most likely cause?

A.The PodSecurityPolicy is applied in the wrong order and a less restrictive policy overrides it.

B.The pod's service account lacks RBAC permissions to use the PSP.

C.The PodSecurityPolicy admission controller is not enabled in the kube-apiserver.

D.The PodSecurityPolicy resource is misconfigured with an empty allowPrivilegeEscalation field.

AnswerC

Without the admission controller, PSPs are not enforced regardless of RBAC.

Why this answer

Option C is correct because the PodSecurityPolicy (PSP) admission controller must be explicitly enabled in the kube-apiserver's `--enable-admission-plugins` flag. Without it, PSP resources are stored in etcd but never enforced, allowing any pod to run with root privileges regardless of PSP definitions.

Exam trap

CNCF often tests the distinction between creating a policy resource and actually enabling the admission controller that enforces it, tricking candidates into focusing on RBAC or policy content rather than the fundamental admission plugin flag.

How to eliminate wrong answers

Option A is wrong because PSPs are evaluated in an additive manner; the most restrictive policy is applied, not the least restrictive, and order does not override. Option B is wrong because RBAC permissions for PSPs control which service accounts can use a PSP, but if the admission controller is not enabled, no PSP is enforced at all. Option D is wrong because an empty `allowPrivilegeEscalation` field defaults to `true` in Kubernetes, but this only matters if the PSP admission controller is active; without it, the field is irrelevant.

Practice this question →

41

MCQhard

A security team wants to ensure that only approved container images can run in their production cluster. Which admission controller should be configured in the kube-apiserver to enforce this policy?

A.PodSecurityPolicy

B.AlwaysPullImages

C.NodeRestriction

D.ImagePolicyWebhook

AnswerD

ImagePolicyWebhook allows integration with an external webhook to enforce image admission policies.

Why this answer

The ImagePolicyWebhook admission controller allows a cluster to enforce a policy that only approved container images can run by sending image admission requests to an external webhook backend. This webhook can validate images against an allowlist, a trusted registry, or a custom policy engine, and it returns an admission decision (allow or deny) before the pod is created. This directly meets the requirement of restricting which container images are permitted in the cluster.

Exam trap

The trap here is that candidates confuse PodSecurityPolicy (which restricts pod security attributes) with image admission control, or they assume AlwaysPullImages can enforce image approval because it forces a fresh pull, but it never checks the image source or registry allowlist.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (PSP) is a deprecated admission controller that enforces security context constraints (e.g., privilege escalation, host namespaces) on pods, not image approval or registry allowlisting. Option B is wrong because AlwaysPullImages forces the kubelet to pull images with the specified pull policy every time a pod is created, but it does not validate whether the image is from an approved source or registry. Option C is wrong because NodeRestriction limits the permissions of kubelet nodes to modify their own node and pod objects via the Kubernetes API, and it has no role in image admission control.

Practice this question →

42

MCQhard

You are a security engineer for a financial services company running a Kubernetes cluster on-premises. The cluster uses kubeadm for bootstrapping and Calico for network policy. Recently, a compliance audit revealed that all nodes in the cluster have the kubelet port 10250 open to the public network, allowing unauthenticated access to the kubelet API. This poses a severe security risk. The cluster has 10 worker nodes and 3 control plane nodes. You need to remediate this without disrupting running workloads. The nodes are behind a corporate firewall, but the internal network is considered untrusted. You have access to the node's iptables and can modify configuration files. Which course of action best secures the kubelet port while maintaining cluster functionality?

A.Use iptables on each node to allow incoming connections to port 10250 only from the cluster's CIDR (e.g., 10.0.0.0/8).

B.Configure a Calico GlobalNetworkPolicy to block inbound traffic to port 10250 on all nodes.

C.Change the kubelet port to a non-standard port (e.g., 10260) and update all kubelet configurations.

D.Set the --anonymous-auth flag to false on each kubelet and restart them one by one.

AnswerA

Restricting source IPs to the cluster network reduces exposure while allowing legitimate kubelet API calls from the control plane and other nodes.

Why this answer

Option A is correct because using iptables to restrict access to port 10250 to only the cluster's internal CIDR (e.g., 10.0.0.0/8) directly addresses the audit finding by blocking unauthenticated public access while allowing necessary kubelet API communication from within the cluster. This approach does not disrupt running workloads, as it only modifies firewall rules without restarting kubelet or changing its configuration. It leverages the existing network infrastructure (iptables) and is consistent with the principle of least privilege for an untrusted internal network.

Exam trap

The trap here is that candidates often confuse Kubernetes network policies (like Calico) with host-level firewall rules, assuming they can block node ports, when in fact network policies only apply to pod-to-pod traffic and cannot control access to the kubelet's host network interface.

How to eliminate wrong answers

Option B is wrong because Calico GlobalNetworkPolicy operates at the Kubernetes network policy layer, which applies to pods and their traffic, not to node-level ports like the kubelet API (port 10250) which is a host network service; Calico policies cannot block traffic to the node's own kubelet endpoint. Option C is wrong because changing the kubelet port to a non-standard port (e.g., 10260) does not address the root cause of unauthenticated access; it only obscures the port, and the new port would still be open to the public network unless additional firewall rules are applied, plus it requires restarting kubelet which could disrupt workloads. Option D is wrong because setting --anonymous-auth to false only disables anonymous requests but does not block unauthenticated access from other sources (e.g., requests with valid but compromised credentials); the audit finding specifically highlights unauthenticated access, and this flag does not prevent network-level exposure of the port.

Practice this question →

43

MCQeasy

Which of the following is a recommended setting from the CIS Kubernetes Benchmark for the kubelet?

A.--authorization-mode=AlwaysAllow

B.--anonymous-auth=true

C.--anonymous-auth=false

D.--read-only-port=10255

AnswerC

Disabling anonymous authentication is a CIS recommendation.

Why this answer

The CIS Kubernetes Benchmark recommends disabling anonymous authentication on the kubelet to ensure that all requests are authenticated. Setting `--anonymous-auth=false` forces the kubelet to reject requests from unauthenticated users, reducing the attack surface and preventing unauthorized access to the kubelet API.

Exam trap

The trap here is that candidates often confuse `--anonymous-auth` with authorization modes, mistakenly thinking that disabling anonymous auth is less important than setting a strict authorization mode, but the CIS Benchmark prioritizes disabling anonymous access as a foundational security control.

How to eliminate wrong answers

Option A is wrong because `--authorization-mode=AlwaysAllow` disables authorization checks, allowing any authenticated request to proceed, which violates the principle of least privilege and is not recommended by the CIS Benchmark. Option B is wrong because `--anonymous-auth=true` allows unauthenticated requests to the kubelet, which is explicitly discouraged as it opens the node to potential exploitation. Option D is wrong because `--read-only-port=10255` is a legacy insecure port that exposes read-only kubelet endpoints without authentication; the CIS Benchmark recommends disabling this port (setting it to 0) to avoid unauthenticated information disclosure.

Practice this question →

44

MCQeasy

Which of the following is a recommended CIS benchmark setting for the kubelet?

A.--anonymous-auth=true

B.--anonymous-auth=false

C.--protect-kernel-defaults=false

D.--read-only-port=10255

AnswerB

This disables anonymous access.

Why this answer

The CIS benchmark for Kubernetes recommends disabling anonymous authentication on the kubelet to ensure that all requests to the kubelet API are authenticated. Setting `--anonymous-auth=false` forces the kubelet to reject requests from unauthenticated users, preventing potential unauthorized access to node-level operations such as pod logs, exec, and port-forwarding.

Exam trap

CNCF often tests the distinction between kubelet flags that control authentication versus authorization, and candidates may confuse `--anonymous-auth` with `--authentication-token-webhook` or incorrectly assume that disabling anonymous auth also blocks legitimate service account tokens.

How to eliminate wrong answers

Option A is wrong because `--anonymous-auth=true` allows unauthenticated requests to the kubelet, which violates the CIS benchmark and exposes the node to unauthorized access. Option C is wrong because `--protect-kernel-defaults=false` disables kernel parameter protection, which is a security hardening setting that should be `true`, not `false`, to ensure the kubelet enforces safe kernel defaults. Option D is wrong because `--read-only-port=10255` enables the read-only port on the kubelet, which serves unauthenticated read-only access and is deprecated; the CIS benchmark recommends disabling this port entirely (setting it to `0`).

Practice this question →

45

Multi-Selectmedium

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

Select 3 answers

A.Apply a NetworkPolicy to block traffic to etcd pods.

B.Use RBAC to restrict access to etcd.

C.Enable TLS peer and client authentication.

D.Expose the etcd client port (2379) to the public internet for monitoring.

E.Set file permissions on etcd data directory to 700.

AnswersB, C, E

RBAC can limit which users/service accounts can access etcd via the API server.

Why this answer

RBAC is a valid method to secure etcd because etcd supports role-based access control for its API, allowing you to define roles and permissions that restrict which users or processes can read or write keys. By enabling RBAC on etcd, you can limit access to sensitive cluster data, such as secrets and configuration, to only authorized components like the Kubernetes API server.

Exam trap

CNCF often tests the misconception that NetworkPolicy can secure etcd, but candidates forget that etcd may not be a regular pod subject to NetworkPolicy, or that NetworkPolicy only controls pod-to-pod traffic and not external access to the etcd port.

Practice this question →

46

MCQmedium

You want to ensure that kubelet does not allow anonymous requests. Which flag must be set on the kubelet?

A.--anonymous-auth=false

B.--authentication-anonymous=false

C.--allow-anonymous=false

D.--read-only-port=0

AnswerA

Correct.

Why this answer

The kubelet's `--anonymous-auth` flag controls whether anonymous requests to the kubelet API are permitted. Setting `--anonymous-auth=false` explicitly denies all anonymous requests, ensuring that only authenticated users can interact with the kubelet. This is a critical hardening step to prevent unauthenticated access to node-level operations.

Exam trap

CNCF often tests the exact flag name `--anonymous-auth` versus similar-sounding alternatives like `--authentication-anonymous` or `--allow-anonymous`, exploiting the fact that candidates may guess based on generic naming conventions rather than knowing the precise kubelet flag syntax.

How to eliminate wrong answers

Option B is wrong because `--authentication-anonymous=false` is not a valid kubelet flag; the correct flag name is `--anonymous-auth`. Option C is wrong because `--allow-anonymous=false` does not exist as a kubelet flag; the kubelet uses `--anonymous-auth` for this purpose. Option D is wrong because `--read-only-port=0` disables the read-only port (port 10255) but does not affect anonymous authentication on the main kubelet API port (10250); anonymous requests can still be made on the secure port unless `--anonymous-auth=false` is set.

Practice this question →

47

MCQmedium

The Kubernetes Dashboard is deployed in the cluster. To secure it, which of the following is a recommended practice?

A.Create a NodePort service to access it externally

B.Access it via kubectl proxy

C.Use an Ingress without TLS

D.Expose it using a LoadBalancer service for easy access

AnswerB

kubectl proxy provides a secure way to access the Dashboard locally with proper authentication.

Why this answer

Accessing the Kubernetes Dashboard via `kubectl proxy` is recommended because it creates an authenticated HTTP proxy between your local machine and the Kubernetes API server. This ensures that all traffic to the Dashboard is tunneled through the API server's authentication and authorization mechanisms, preventing direct exposure of the Dashboard to the network and reducing the attack surface.

Exam trap

CNCF often tests the misconception that exposing the Dashboard via a NodePort or LoadBalancer is acceptable for convenience, but the trap is that these methods bypass the API server's authentication layer, which is a fundamental security requirement for the Dashboard.

How to eliminate wrong answers

Option A is wrong because creating a NodePort service exposes the Dashboard on a high port across all cluster nodes, bypassing API server authentication and allowing potential network-level attacks. Option C is wrong because using an Ingress without TLS exposes the Dashboard over unencrypted HTTP, making it vulnerable to man-in-the-middle attacks and credential interception. Option D is wrong because exposing the Dashboard via a LoadBalancer service grants direct external access without the API server's authentication proxy, violating the principle of least privilege and increasing the risk of unauthorized access.

Practice this question →

48

MCQmedium

A developer creates a pod with the following YAML: apiVersion: v1 kind: Pod metadata: name: mypod spec: serviceAccountName: default automountServiceAccountToken: true containers: - name: app image: nginx What is the security concern with this configuration?

A.The pod does not specify resource limits

B.The container runs as root

C.The service account token is automatically mounted, potentially providing excessive permissions

D.The pod uses the 'default' namespace

AnswerC

Automounting the default service account token can be a security risk if the token has broad permissions.

Why this answer

Option C is correct because setting `automountServiceAccountToken: true` (or omitting it, as it defaults to true) causes the pod to automatically mount the service account token of the `default` service account into the container. This token can grant excessive permissions if the default service account has been bound to roles with broad access, such as cluster-admin or other privileged RBAC bindings, which is a common misconfiguration. An attacker who compromises the container can then use this token to authenticate to the Kubernetes API server and perform unauthorized actions within the cluster.

Exam trap

CNCF often tests the misconception that the `default` service account is always safe or that the namespace choice is the primary risk, when in fact the automatic mounting of the service account token—especially when combined with overly permissive RBAC bindings—is the direct security concern.

How to eliminate wrong answers

Option A is wrong because while resource limits are a best practice for preventing resource starvation, their absence is not a direct security concern related to service account token exposure or privilege escalation. Option B is wrong because running as root inside a container is a security concern, but the provided YAML does not explicitly set `securityContext.runAsNonRoot` or `runAsUser`, so it is not guaranteed that the container runs as root; the nginx image may run as a non-root user by default in newer versions, and the question specifically asks about the security concern with the given configuration, which highlights the token mount. Option D is wrong because using the 'default' namespace is not inherently a security issue; namespaces are logical isolation boundaries, and the security risk comes from the service account token being mounted, not the namespace itself.

Practice this question →

49

MCQeasy

What is the purpose of the 'automountServiceAccountToken: false' setting in a Pod spec?

A.It disables the service account controller

B.It prevents the automatic mounting of the service account token into the pod

C.It deletes the service account after the pod starts

D.It prevents the pod from using any service account

AnswerB

This is the correct definition.

Why this answer

Setting `automountServiceAccountToken: false` in a Pod spec prevents the automatic mounting of the Kubernetes service account token (a JWT) into the Pod's filesystem at `/var/run/secrets/kubernetes.io/serviceaccount/token`. This is a security hardening measure to reduce the attack surface for compromised containers, as the token can be used to authenticate to the Kubernetes API server. By default, Kubernetes mounts this token into every Pod, so explicitly disabling it is necessary when the Pod does not require API access.

Exam trap

CNCF often tests the misconception that disabling token mounting also disables the service account entirely, but the service account remains assignable and usable for other purposes (e.g., RBAC bindings), and the token can still be manually mounted if needed.

How to eliminate wrong answers

Option A is wrong because disabling the automatic mount of the service account token does not affect the service account controller; the controller continues to manage service accounts and their tokens independently. Option C is wrong because the setting does not delete the service account after the Pod starts; service accounts are persistent resources that remain until explicitly deleted. Option D is wrong because the Pod can still use a service account (e.g., via `serviceAccountName`), but the token is not automatically mounted; the Pod could still access the token if manually mounted or if the service account is used for other purposes like pod identity.

Practice this question →

50

MCQeasy

Which flag should you set on the kube-apiserver to disable anonymous authentication?

A.--disable-anonymous=true

B.--anonymous-auth=false

C.--enable-anonymous-auth=false

D.--auth-mode=RBAC

AnswerB

This flag disables anonymous authentication.

Why this answer

The `--anonymous-auth` flag on the kube-apiserver controls whether anonymous requests are allowed. Setting `--anonymous-auth=false` explicitly disables anonymous authentication, meaning requests without valid credentials will be rejected with a 401 Unauthorized response. This is the correct parameter to harden the API server against unauthenticated access.

Exam trap

The trap here is that candidates confuse authentication flags with authorization flags (like `--authorization-mode=RBAC`) or invent non-existent flags like `--disable-anonymous`, when the actual flag uses a simple boolean `--anonymous-auth`.

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 C is wrong because `--enable-anonymous-auth=false` does not exist; the flag uses the `--anonymous-auth` boolean directly, not a negated form. Option D is wrong because `--auth-mode=RBAC` is not a valid flag; RBAC is configured via `--authorization-mode=RBAC` and controls authorization, not authentication, so it does not disable anonymous access.

Practice this question →

51

Multi-Selectmedium

Which THREE of the following are valid fields in an EncryptionConfiguration YAML to encrypt secrets at rest?

Select 3 answers

A.providers

B.resources

C.apiVersion

D.key

E.kind

AnswersB, C, E

Correct. Specifies which resources to encrypt.

Why this answer

Option B is correct because `resources` is a valid field in an EncryptionConfiguration YAML that specifies which Kubernetes resources (e.g., secrets) should be encrypted. The EncryptionConfiguration object defines how to encrypt data at rest in etcd, and the `resources` field lists the resource types to encrypt, such as `secrets`. Without this field, the encryption configuration would not know which resources to apply encryption to.

Exam trap

CNCF often tests the distinction between top-level fields and nested fields in EncryptionConfiguration, so candidates mistakenly select `providers` as a top-level field when it actually belongs under `resources`.

Practice this question →

52

Multi-Selecthard

Which THREE are valid ways to restrict access to the Kubernetes API server?

Select 3 answers

A.Disable anonymous authentication

B.Enable RBAC authorization mode

C.Use webhook token authentication

D.Use TLS client certificate authentication

E.Set the API server's bind address to 0.0.0.0

AnswersA, B, D

Prevents unauthenticated access.

Why this answer

A is correct because disabling anonymous authentication (via the `--anonymous-auth=false` flag on the API server) removes the ability for unauthenticated requests to reach the API server. This forces all requests to present valid credentials, thereby restricting access to only authenticated users.

Exam trap

CNCF often tests the distinction between authentication (who you are) and authorization (what you can do), so candidates may mistakenly think webhook token authentication restricts access when it only identifies the user, and may overlook that binding to 0.0.0.0 is a security risk, not a restriction.

Practice this question →

53

Multi-Selectmedium

Which TWO of the following are CIS Benchmark recommendations for securing the Kubernetes API server? (Select TWO)

Select 2 answers

A.Disable RBAC

B.Enable audit logging

C.Disable anonymous authentication

D.Enable anonymous authentication

E.Use TLS 1.0

AnswersB, C

Audit logging is recommended to monitor API requests.

Why this answer

Option B is correct because the CIS Benchmark for Kubernetes recommends enabling audit logging to record all API server requests, which is essential for security monitoring, incident response, and compliance. Audit logs capture the sequence of actions performed by users, administrators, and system components, providing an immutable record that can be analyzed for suspicious activity or policy violations.

Exam trap

CNCF often tests the distinction between authentication and authorization, so candidates may confuse disabling anonymous authentication (a correct security practice) with enabling RBAC (also correct), but the trap is that the question asks for two specific CIS Benchmark recommendations, and disabling RBAC is never recommended—it is a dangerous misconfiguration.

Practice this question →

54

MCQmedium

Which kubectl command can be used to view the audit log policy currently in use by the API server?

A.kubectl logs -n kube-system kube-apiserver-<node> | grep audit

B.kubectl describe clusterrolebinding audit

C.kubectl get -n kube-system pods kube-apiserver-<node> -o yaml | grep audit-policy-file

D.kubectl get auditpolicy

AnswerC

This command retrieves the API server manifest and shows the audit policy file path.

Why this answer

Option C is correct because the audit policy file path is specified in the kube-apiserver manifest (usually a static pod YAML in /etc/kubernetes/manifests/). Running `kubectl get pod kube-apiserver-<node> -n kube-system -o yaml` and grepping for `audit-policy-file` reveals the exact path to the policy file currently in use, which is the authoritative way to confirm which audit policy the API server is loading.

Exam trap

The trap here is that candidates assume audit logs can be viewed via `kubectl logs` (Option A) or that audit policies are a native Kubernetes resource (Option D), when in fact the audit policy is a file referenced by a command-line flag in the API server manifest and must be inspected indirectly.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` shows the API server's runtime logs, which may contain audit log entries but does not reveal the audit policy file path or its contents; grepping for 'audit' in logs is unreliable and not the intended method to view the policy. Option B is wrong because `clusterrolebinding audit` is not a standard Kubernetes resource; there is no default ClusterRoleBinding named 'audit' related to audit policies, and this command would fail or return unrelated RBAC information. Option D is wrong because `kubectl get auditpolicy` is not a valid kubectl command; audit policies are not a native Kubernetes API resource and cannot be retrieved with `kubectl get`.

Practice this question →

55

MCQeasy

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

A.--enable-anonymous=false

B.--anonymous-auth=false

C.--anonymous-enabled=false

D.--authentication-mode=Anonymous

AnswerB

This flag disables anonymous authentication.

Why this answer

Option B is correct because the `--anonymous-auth=false` flag explicitly disables anonymous authentication on the kube-apiserver. By default, anonymous requests are allowed (with a system:anonymous user), so setting this flag to false prevents unauthenticated users from accessing the API server. This is a key hardening measure to ensure only authenticated clients can interact with the cluster.

Exam trap

The trap here is that candidates confuse the `--anonymous-auth` flag with non-existent variants like `--enable-anonymous` or `--anonymous-enabled`, or mistakenly think anonymous authentication is controlled via an `--authentication-mode` flag.

How to eliminate wrong answers

Option A is wrong because `--enable-anonymous=false` is not a valid kube-apiserver flag; the correct flag uses `--anonymous-auth`, not `--enable-anonymous`. Option C is wrong because `--anonymous-enabled=false` is not a recognized flag; the kube-apiserver uses `--anonymous-auth` to control anonymous access. Option D is wrong because `--authentication-mode=Anonymous` does not exist; authentication modes are configured via `--authorization-mode` and `--authentication-token-webhook`, and anonymous authentication is controlled by the `--anonymous-auth` flag, not a mode setting.

Practice this question →

56

MCQhard

A pod is in a CrashLoopBackOff state. You run 'kubectl logs pod-name' and see: 'Error: failed to start container: exec: "/app": stat /app: no such file or directory'. What is the most likely cause?

A.The pod is out of memory

B.The container's working directory is incorrect

C.The pod has a liveness probe that is failing

D.The container image is missing the /app executable

AnswerD

Correct. The container is trying to run /app, but the file does not exist in the image.

Why this answer

The error message 'exec: "/app": stat /app: no such file or directory' indicates that the container runtime (e.g., containerd) cannot find the executable specified in the container's ENTRYPOINT or CMD. This occurs when the container image does not include the /app binary or script at that path, causing the container to fail immediately on start and enter CrashLoopBackOff. Option D correctly identifies that the container image is missing the /app executable.

Exam trap

CNCF often tests the distinction between container startup failures (e.g., missing executable) and runtime failures (e.g., probe failures or resource limits), so candidates may confuse a liveness probe failure (which occurs after the container is running) with an exec error that prevents the container from starting at all.

How to eliminate wrong answers

Option A is wrong because an out-of-memory (OOM) condition would typically result in an OOMKilled status or a different error in logs, such as 'container exited with code 137', not a 'no such file or directory' exec error. Option B is wrong because an incorrect working directory (WORKDIR) does not prevent the container from starting; the container would still execute the entrypoint, though it might fail later if it tries to access files relative to that directory. Option C is wrong because a failing liveness probe would cause the container to be restarted by kubelet after the probe fails, but the initial startup error is a container runtime exec failure, not a probe-related issue.

Practice this question →

57

MCQmedium

A security team wants to ensure that all API requests to the cluster are authenticated and uses RBAC for authorization. Which two flags must be set on the kube-apiserver?

A.--anonymous-auth=false --authorization-mode=Webhook

B.--enable-admission-plugins=NodeRestriction --authorization-mode=AlwaysAllow

C.--anonymous-auth=true --authorization-mode=ABAC

D.--anonymous-auth=false --authorization-mode=RBAC

AnswerD

Setting --anonymous-auth=false disables anonymous access, and --authorization-mode=RBAC enables RBAC authorization. Together they enforce authenticated access with RBAC.

Why this answer

Option D is correct because setting --anonymous-auth=false disables unauthenticated requests, ensuring all API calls require authentication, and --authorization-mode=RBAC enforces Role-Based Access Control for authorization. This combination aligns with the security team's requirement for authenticated and RBAC-authorized API requests, as RBAC is the standard Kubernetes authorization mode for fine-grained access control.

Exam trap

The trap here is that candidates may confuse authentication with authorization, thinking that setting --anonymous-auth=false alone satisfies the requirement, or they may mistakenly choose ABAC (option C) because it is an authorization mode, but the question explicitly requires RBAC, not ABAC.

How to eliminate wrong answers

Option A is wrong because --authorization-mode=Webhook delegates authorization to an external HTTP service, not RBAC, and --anonymous-auth=false alone does not enforce RBAC. Option B is wrong because --authorization-mode=AlwaysAllow permits all requests without any authorization checks, violating the requirement for RBAC, and --enable-admission-plugins=NodeRestriction is an admission controller, not an authorization mode. Option C is wrong because --anonymous-auth=true allows unauthenticated requests, bypassing authentication, and --authorization-mode=ABAC uses Attribute-Based Access Control, not RBAC.

Practice this question →

58

Multi-Selectmedium

Which TWO of the following are recommended actions to harden service account security in a Kubernetes cluster? (Select TWO)

Select 2 answers

A.Delete all service accounts except the default one

B.Use a single service account for all workloads

C.Avoid granting cluster-admin ClusterRole to service accounts

D.Grant cluster-admin to all service accounts for simplicity

E.Disable automountServiceAccountToken for pods that do not require API access

AnswersC, E

Cluster-admin should be reserved for break-glass scenarios.

Why this answer

Option C is correct because granting the cluster-admin ClusterRole to a service account provides unrestricted superuser access across the entire cluster, violating the principle of least privilege. The CKS exam emphasizes that service accounts should be bound only to the minimal RBAC permissions required for their function, and cluster-admin should never be used for routine workloads.

Exam trap

CNCF often tests the misconception that deleting all non-default service accounts or using a single shared service account simplifies management, when in fact these actions break security boundaries and are explicitly discouraged in Kubernetes hardening guides.

Practice this question →

59

MCQmedium

You want to ensure that a pod only runs on nodes that have a specific label, 'disktype=ssd'. Which field should be specified in the pod spec?

A.affinity.nodeAffinity

B.nodeName

C.nodeSelector

D.tolerations

AnswerC

nodeSelector is a simple field that selects nodes with matching labels.

Why this answer

C is correct because `nodeSelector` is the simplest and most direct field in a Pod spec for constraining which nodes the Pod can be scheduled on based on node labels. By setting `nodeSelector` with `disktype: ssd`, the scheduler will only place the Pod on nodes that have that exact label key-value pair, making it the ideal choice for this straightforward label-based scheduling requirement.

Exam trap

CNCF often tests the distinction between `nodeSelector` (simple label match) and `nodeAffinity` (advanced label matching with operators), leading candidates to overcomplicate and choose `nodeAffinity` when `nodeSelector` is the correct, minimal answer.

How to eliminate wrong answers

Option A is wrong because `affinity.nodeAffinity` provides more complex and flexible scheduling rules (e.g., required vs. preferred constraints, matchExpressions with operators like In/NotIn), but it is not the simplest field for a basic label match; the question asks for a field to ensure the pod only runs on nodes with a specific label, and `nodeSelector` is the correct minimal field. Option B is wrong because `nodeName` directly assigns the Pod to a specific node by name, bypassing the scheduler entirely and ignoring labels; it does not use the `disktype=ssd` label and would fail if the named node does not have that label. Option D is wrong because `tolerations` allow a Pod to be scheduled on nodes with matching taints, but they do not actively select nodes based on labels; tolerations only permit scheduling on tainted nodes, they do not enforce that a node must have a specific label.

Practice this question →

60

Multi-Selectmedium

Which TWO admission plugins are recommended by the CIS benchmark to be enabled on the kube-apiserver? (Choose two.)

Select 2 answers

A.AlwaysDeny

B.NodeRestriction

C.ServiceAccount

D.AlwaysAdmit

E.PodSecurityPolicy

AnswersB, C

NodeRestriction limits kubelet permissions and is recommended by CIS.

Why this answer

The CIS Benchmark for Kubernetes recommends enabling the NodeRestriction and ServiceAccount admission plugins on the kube-apiserver. NodeRestriction limits the Node identity's ability to modify Node and Pod objects, enforcing the principle of least privilege for kubelets. ServiceAccount ensures that every Pod is assigned a default ServiceAccount and that the token is automatically mounted, which is essential for secure pod-to-API-server communication.

Exam trap

CNCF often tests the misconception that deprecated or removed plugins like PodSecurityPolicy are still recommended, or that blanket deny/admit plugins are viable hardening measures, when in fact the CIS Benchmark focuses on least-privilege and default-secure plugins like NodeRestriction and ServiceAccount.

Practice this question →

61

MCQeasy

What is the recommended way to provide TLS certificates to the API server?

A.Use --tls-cert-file and --tls-private-key-file flags

B.Store certificates in a ConfigMap and mount them

C.Place certificates in /etc/kubernetes/pki/ without additional flags

D.Use --client-ca-file only

AnswerA

These flags directly specify the certificate and key files.

Why this answer

The recommended way to provide TLS certificates to the API server is by using the `--tls-cert-file` and `--tls-private-key-file` flags. These flags explicitly point the kube-apiserver to the certificate and key files, ensuring the server presents a valid TLS certificate for encrypted HTTPS communication. This is the standard, documented method for configuring TLS on the API server, as it allows the server to authenticate itself to clients.

Exam trap

The trap here is that candidates often confuse the purpose of `--client-ca-file` (for client authentication) with the server TLS flags, or assume that placing certificates in `/etc/kubernetes/pki/` is sufficient without setting the corresponding flags, because kubeadm automates this but the exam tests manual configuration knowledge.

How to eliminate wrong answers

Option B is wrong because ConfigMaps are designed for storing non-sensitive configuration data, not TLS private keys, which must be kept confidential; mounting a ConfigMap would expose the private key in plaintext, violating security best practices. Option C is wrong because while `/etc/kubernetes/pki/` is the default directory for certificates on a kubeadm cluster, the API server does not automatically load certificates from this path without the corresponding `--tls-cert-file` and `--tls-private-key-file` flags being set. Option D is wrong because `--client-ca-file` is used to specify the CA certificate for verifying client certificates (mutual TLS), not for providing the server's own TLS certificate and key.

Practice this question →

62

MCQmedium

You run 'kube-bench' and see a failure: '1.2.7 Ensure that the --kubelet-client-certificate and --kubelet-client-key arguments are set as appropriate'. What is the impact of this misconfiguration?

A.The apiserver will use the kubelet's own certificate

B.The kubelet will refuse to register with the cluster

C.The apiserver will use anonymous authentication when connecting to kubelets

D.The apiserver will reject all requests to kubelets

AnswerC

kubelet may allow anonymous access if --anonymous-auth is true.

Why this answer

When the API server lacks a properly configured client certificate and key for kubelet communication, it falls back to anonymous authentication when making requests to kubelets. This means the kubelet cannot verify the API server's identity, allowing any unauthenticated request to be processed, which violates the principle of mutual TLS (mTLS) and weakens cluster security.

Exam trap

The trap here is that candidates often assume the API server will simply fail or reject requests when missing client certificates, but in reality, Kubernetes defaults to allowing anonymous authentication unless explicitly disabled, so the impact is a security bypass rather than a denial of service.

How to eliminate wrong answers

Option A is wrong because the API server does not use the kubelet's own certificate; it uses its own client certificate to authenticate to the kubelet, and the kubelet's certificate is used for the server side of the TLS handshake. Option B is wrong because kubelet registration with the cluster depends on the kubelet's bootstrap token or client certificate, not on the API server's kubelet client certificate; the kubelet will still register even if this flag is missing. Option D is wrong because the API server does not reject all requests; instead, it falls back to anonymous authentication, which may still allow requests to succeed but without proper authentication.

Practice this question →

63

MCQmedium

An administrator runs 'kube-bench run --targets=master' and sees a failing check for 'Ensure that the --audit-log-path argument is set'. What is the correct remediation?

A.Add '--audit-policy-file=/etc/kubernetes/audit-policy.yaml' to the API server

B.Add '--audit-log-path=/var/log/audit.log' to the kube-apiserver

C.Add '--audit-log-path=/var/log/audit.log' to the kube-controller-manager

D.Add '--audit-log-maxsize=100' to the API server

AnswerB

The API server audit log path is set with this flag.

Why this answer

The kube-bench check for 'Ensure that the --audit-log-path argument is set' specifically targets the kube-apiserver component, as it is the primary component that handles API requests and should log them for audit purposes. The correct remediation is to add '--audit-log-path=/var/log/audit.log' to the kube-apiserver's startup arguments, which enables writing audit logs to a specified file path. This ensures that all API server requests are recorded for security monitoring and compliance.

Exam trap

The trap here is that candidates often confuse the audit policy file argument with the audit log path argument, or mistakenly think audit logging applies to other control plane components like the controller-manager, when in fact it is exclusively a kube-apiserver configuration.

How to eliminate wrong answers

Option A is wrong because '--audit-policy-file' defines the audit policy rules (what to log), not the log file path; it is a separate required setting but does not satisfy the check for '--audit-log-path'. Option C is wrong because the kube-controller-manager does not handle API requests directly and is not the target of this audit logging requirement; audit logging is a kube-apiserver responsibility. Option D is wrong because '--audit-log-maxsize' controls the maximum size of a log file before rotation, not the path where logs are written; it is an auxiliary setting, not the primary remediation for the missing log path.

Practice this question →

64

MCQmedium

An administrator wants to ensure that no service account in the 'development' namespace has cluster-admin privileges. Which command should be used to identify such bindings?

A.kubectl get serviceaccounts -n development

B.kubectl get clusterrolebindings -o yaml | grep -B 10 namespace: development

C.kubectl get rolebindings -n development --all-namespaces

D.kubectl describe clusterrole cluster-admin

AnswerB

This searches for cluster role bindings that include subjects from the development namespace.

Why this answer

Option B is correct because `ClusterRoleBindings` are cluster-scoped resources that grant permissions across all namespaces, including the `development` namespace. By piping the YAML output through `grep -B 10 namespace: development`, you can identify which `ClusterRoleBinding` references a service account in the `development` namespace, revealing any binding that could grant cluster-admin privileges to that namespace's service accounts.

Exam trap

The trap here is that candidates often confuse `RoleBindings` (namespace-scoped) with `ClusterRoleBindings` (cluster-scoped), assuming that `RoleBindings` can grant cluster-admin privileges, or they mistakenly think listing service accounts or describing the ClusterRole itself will reveal the bindings.

How to eliminate wrong answers

Option A is wrong because `kubectl get serviceaccounts -n development` only lists service accounts in the namespace, not the bindings that grant them permissions; it cannot reveal whether any service account has cluster-admin privileges. Option C is wrong because `kubectl get rolebindings -n development --all-namespaces` is syntactically incorrect (you cannot combine `-n` with `--all-namespaces`), and even if corrected, `RoleBindings` are namespace-scoped and cannot grant cluster-admin privileges (which require a `ClusterRoleBinding`). Option D is wrong because `kubectl describe clusterrole cluster-admin` only describes the permissions of the `cluster-admin` ClusterRole, but does not show which subjects (users, groups, or service accounts) are bound to it, so it cannot identify bindings in the `development` namespace.

Practice this question →

65

MCQhard

A Kubernetes cluster is experiencing issues where pods cannot pull images from a private container registry. The registry requires authentication via imagePullSecrets. The cluster has a pod running with the following spec snippet. What is the likely cause of the failure?

A.The secret 'regcred' does not exist in the namespace

B.The service account lacks RBAC permissions to use the secret

C.The pod does not set serviceAccountName to the service account that has the imagePullSecrets

D.The imagePullSecret is of type 'Opaque' instead of 'kubernetes.io/dockerconfigjson'

AnswerC

Without explicit service account, pod uses 'default' SA which has no imagePullSecrets.

Why this answer

The pod spec snippet shows that the pod does not have a `serviceAccountName` field set, meaning it uses the default service account in the namespace. The default service account typically does not have `imagePullSecrets` attached. Even if the secret 'regcred' exists, the pod cannot use it unless the service account associated with the pod has that secret linked via `imagePullSecrets` in the service account definition.

Therefore, the pod fails to authenticate to the private registry.

Exam trap

CNCF often tests the nuance that simply referencing a secret in a pod spec via `imagePullSecrets` is not enough; the pod must be associated with a service account that has that secret attached, or the pod must explicitly list the secret in its own `imagePullSecrets` field.

How to eliminate wrong answers

Option A is wrong because the question states the cluster has a pod running with the given spec, and the secret 'regcred' is referenced in the spec; if the secret did not exist, the pod would fail with a different error (e.g., 'secret not found') and the spec would not be valid. Option B is wrong because RBAC permissions are not required for a service account to use a secret as an imagePullSecret; the secret is referenced directly in the pod spec or via the service account, and no RBAC authorization is needed for pulling images. Option D is wrong because while an Opaque secret is not the correct type for docker registry credentials, the pod spec references 'regcred' which is assumed to be of the correct type; the core issue is the missing service account linkage, not the secret type.

Practice this question →

66

MCQhard

You run kube-bench on a node and it reports a failure for control plane component etcd. The check says 'Ensure that the --cert-file and --key-file arguments are set as appropriate'. You examine the etcd manifest file and find that the cert-file and key-file are configured with a self-signed certificate. What is the BEST action to remediate this finding?

A.Add the --trusted-ca-file flag pointing to the CA certificate.

B.Remove the --cert-file and --key-file flags to disable TLS.

C.Change the self-signed certificate to one signed by the Kubernetes CA.

D.Set the --auto-tls flag to true to let etcd automatically generate a certificate.

AnswerC

Using a certificate signed by the Kubernetes CA is a valid approach that satisfies the benchmark.

Why this answer

Option C is correct because kube-bench expects etcd to use certificates signed by a trusted CA (typically the Kubernetes CA) for secure communication. Self-signed certificates are not trusted by default and can lead to man-in-the-middle attacks or connection failures. Replacing the self-signed certificate with one signed by the Kubernetes CA ensures that the certificate chain is validated, aligning with the CIS Benchmark requirement for etcd.

Exam trap

The trap here is that candidates may confuse 'self-signed' with 'auto-generated' (option D) or think that adding a CA file (option A) fixes the issue, but the core requirement is that the certificate itself must be signed by a trusted CA, not just that a CA file is present.

How to eliminate wrong answers

Option A is wrong because adding --trusted-ca-file alone does not address the requirement that the server certificate itself must be signed by a trusted CA; it only specifies which CA to trust for client connections, but the self-signed cert still lacks a proper CA signature. Option B is wrong because removing --cert-file and --key-file disables TLS entirely, which violates the CIS Benchmark requirement for encrypted communication and exposes etcd to unencrypted traffic. Option D is wrong because setting --auto-tls to true enables automatic self-signed certificate generation, which still results in a self-signed certificate that is not trusted by the Kubernetes CA, failing the same check.

Practice this question →

67

Multi-Selectmedium

Which two of the following are recommended by the CIS Kubernetes Benchmark? (Choose two.)

Select 2 answers

A.Use NodePort services for internal communication

B.Enable the insecure port on the API server

C.Disable anonymous authentication on the API server

D.Use the default service account for all pods

E.Enable audit logging on the API server

AnswersC, E

CIS benchmark recommends setting --anonymous-auth=false.

Why this answer

Option C is correct because the CIS Kubernetes Benchmark explicitly recommends disabling anonymous authentication on the API server to prevent unauthenticated access. Anonymous requests bypass all authentication checks and can lead to unauthorized cluster operations if RBAC is not properly scoped. Setting the `--anonymous-auth=false` flag on the API server ensures that only authenticated users can interact with the cluster.

Exam trap

CNCF often tests the misconception that NodePort services are suitable for internal cluster communication, but the trap is that NodePort is designed for external access and introduces unnecessary network exposure, while ClusterIP is the correct internal service type.

Practice this question →

68

MCQhard

A ClusterRoleBinding grants cluster-admin to a service account in the 'kube-system' namespace. What is the best way to audit this for least privilege?

A.Use 'kubectl auth can-i --list' to check the service account's permissions.

B.Delete the ClusterRoleBinding immediately.

C.Run 'kubectl get clusterrolebindings' to list all bindings.

D.Review the permissions granted by cluster-admin and create a custom Role with only necessary permissions, then bind it.

AnswerD

This follows the least privilege principle by scoping permissions to only what is needed.

Why this answer

Option D is correct because the cluster-admin ClusterRole grants superuser access across all namespaces, which violates the principle of least privilege. The best practice is to review the specific permissions required by the service account, create a custom Role with only those necessary permissions, and bind it via a RoleBinding or ClusterRoleBinding scoped appropriately. This minimizes the attack surface and aligns with Kubernetes RBAC hardening guidelines.

Exam trap

The trap here is that candidates may think simply listing or checking permissions (Options A or C) is sufficient for auditing, when the core requirement is to reduce permissions to the minimum necessary, which involves creating a custom Role.

How to eliminate wrong answers

Option A is wrong because 'kubectl auth can-i --list' only shows what the current user can do, not the permissions of a specific service account; to check a service account's permissions, you must use '--as' impersonation or inspect the RBAC bindings directly. Option B is wrong because immediately deleting the ClusterRoleBinding without understanding the service account's actual needs could break critical cluster functionality, such as controllers or add-ons running in kube-system. Option C is wrong because simply listing all ClusterRoleBindings does not audit for least privilege; it only provides a list without analyzing whether the bound permissions are excessive.

Practice this question →

69

Multi-Selectmedium

Which TWO admission plugins should be enabled to improve cluster security according to CIS benchmarks? (Choose two.)

Select 2 answers

A.PodSecurity

B.NodeRestriction

C.NamespaceLifecycle

D.PodSecurityPolicy

E.ServiceAccount

AnswersA, B

Enforces Pod Security Standards.

Why this answer

PodSecurity is correct because it replaces the deprecated PodSecurityPolicy (PSP) and enforces the Pod Security Standards (baseline, restricted, privileged) via admission webhooks or built-in admission controllers. This prevents pods from running with excessive privileges, such as privileged containers or hostPath mounts, directly aligning with CIS benchmarks for Kubernetes hardening. NodeRestriction is correct because it limits the Node and Pod objects a kubelet can modify, preventing a compromised node from escalating privileges or modifying other nodes' statuses, which is a key CIS control for node-level security.

Exam trap

CNCF often tests the distinction between PodSecurity (current) and PodSecurityPolicy (deprecated/removed), and candidates mistakenly choose PSP because they recall it from older CKA exams, not realizing CIS benchmarks now mandate PodSecurity.

Practice this question →

70

MCQeasy

Which kube-apiserver flag enables audit logging?

A.--audit-log-path

B.--audit-log-dir

C.--enable-audit

D.--audit-policy-file

AnswerA

This flag enables audit logging to a file.

Why this answer

The `--audit-log-path` flag is the correct kube-apiserver flag to enable audit logging because it specifies the file path where audit logs are written. When this flag is set, the API server starts recording audit events to the designated file, effectively enabling the audit logging feature. Without this flag, audit logging is disabled by default, even if other audit-related flags like `--audit-policy-file` are provided.

Exam trap

The trap here is that candidates often confuse `--audit-policy-file` (which defines what to log) with the flag that actually enables logging, or they assume a non-existent `--enable-audit` flag exists because other Kubernetes components use similar enable flags.

How to eliminate wrong answers

Option B is wrong because `--audit-log-dir` is not a valid kube-apiserver flag; the correct flag for specifying a directory is `--audit-log-path`, which accepts a full file path, not a directory. Option C is wrong because `--enable-audit` does not exist as a kube-apiserver flag; audit logging is implicitly enabled when `--audit-log-path` is set, and there is no separate boolean flag to enable it. Option D is wrong because `--audit-policy-file` defines the audit policy rules (what events to log) but does not enable audit logging itself; audit logging remains disabled unless `--audit-log-path` is also specified.

Practice this question →

71

MCQeasy

Which flag enables the NodeRestriction admission plugin on the API server?

A.--enable-admission-plugins=NodeRestriction

B.--admission-control=NodeRestriction

C.--kubelet-restriction=NodeRestriction

D.--node-restriction=true

AnswerA

This flag enables the NodeRestriction admission plugin.

Why this answer

The `--enable-admission-plugins` flag is the correct parameter to activate admission controllers in the kube-apiserver. The NodeRestriction plugin limits the Node and Pod objects a kubelet can modify, enforcing the principle of least privilege. Option A correctly uses this flag with the plugin name.

Exam trap

The trap here is that candidates confuse the deprecated `--admission-control` flag with the current `--enable-admission-plugins` flag, or they invent non-existent flags like `--kubelet-restriction` or `--node-restriction` that sound plausible but are not valid API server options.

How to eliminate wrong answers

Option B is wrong because `--admission-control` is a deprecated flag from older Kubernetes versions (pre-1.10) and is no longer supported; the correct flag is `--enable-admission-plugins`. Option C is wrong because `--kubelet-restriction` is not a valid kube-apiserver flag; it does not exist in the Kubernetes API server options. Option D is wrong because `--node-restriction` is not a valid boolean flag; the NodeRestriction feature is an admission plugin, not a simple boolean toggle.

Practice this question →

72

Multi-Selecthard

Which THREE of the following are valid ways to restrict access to etcd? (Select 3)

Select 3 answers

A.Enable etcd RBAC to restrict read/write access

B.Use HTTP instead of HTTPS

C.Disable client authentication for simplicity

D.Use firewall rules to restrict network access to etcd

E.Use TLS client certificates for authentication

AnswersA, D, E

etcd RBAC can limit access to keys.

Why this answer

Option A is correct because etcd supports Role-Based Access Control (RBAC) that allows you to define roles and permissions to restrict read and write access to keys. By enabling etcd RBAC, you can enforce fine-grained authorization, ensuring that only authenticated and authorized clients (e.g., the Kubernetes API server) can perform specific operations on etcd data.

Exam trap

CNCF often tests the misconception that disabling security features (like authentication or encryption) can simplify access control, but in reality, these features are essential for restricting access, and candidates may incorrectly think that network-level controls alone are insufficient or that HTTP is acceptable for internal traffic.

Practice this question →

73

Matchingmedium

Match each Kubernetes security component to its description.

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

Concepts

Matches

Admission controller that enforces security constraints on pods

Defines how groups of pods can communicate with each other and other network endpoints

Role-based access control for authorization within the cluster

Linux security facility to restrict system calls from a container

Mandatory access control system that confines programs to a limited set of resources

Why these pairings

These components are critical for securing Kubernetes clusters.

Practice this question →

74

Multi-Selectmedium

Which TWO of the following are valid arguments for etcd encryption at rest?

Select 2 answers

A.kms

B.identity

C.base64

D.secretbox

E.aescbc

AnswersD, E

Correct. secretbox is a supported provider.

Why this answer

Option D (secretbox) is correct because it is a valid encryption provider for etcd data at rest in Kubernetes, using XSalsa20 and Poly1305 for authenticated encryption. It is one of the supported providers alongside aescbc, and is specifically designed for encryption at rest within etcd.

Exam trap

CNCF often tests the distinction between encryption providers and encoding/identity, where candidates mistakenly think 'base64' or 'identity' provide encryption, or confuse KMS (a key management integration) with an etcd encryption provider.

Practice this question →

75

MCQmedium

Which command would you run to check if anonymous authentication is enabled on the API server?

A.ps aux | grep kube-apiserver | grep anonymous-auth

B.kubectl get nodes -o yaml | grep anonymous

C.kubectl describe configmap anonymous

D.kubectl get clusterrolebinding anonymous

AnswerA

This shows the command-line flags of the API server process.

Why this answer

Option A is correct because the `--anonymous-auth` flag on the kube-apiserver binary controls whether anonymous requests are allowed. Running `ps aux | grep kube-apiserver | grep anonymous-auth` directly inspects the running process arguments to see if the flag is set to `true` (enabled) or `false` (disabled). This is the most direct way to check the runtime configuration of the API server.

Exam trap

CNCF often tests the ability to distinguish between runtime process inspection and Kubernetes API resource queries, leading candidates to mistakenly use `kubectl` commands that query non-existent or irrelevant resources instead of checking the actual process arguments.

How to eliminate wrong answers

Option B is wrong because `kubectl get nodes -o yaml` retrieves node objects, which do not contain any information about the API server's authentication configuration. Option C is wrong because there is no standard Kubernetes resource called `configmap anonymous`; ConfigMaps are namespaced and unrelated to API server authentication settings. Option D is wrong because `ClusterRoleBinding` named `anonymous` does not exist by default; anonymous access is controlled by the `system:anonymous` user and `system:unauthenticated` group, not by a dedicated ClusterRoleBinding.

Practice this question →

Page 1 of 4 · 239 questions totalNext →

Ready to test yourself?

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

Start 20-question session