CCNA Cluster Setup and Hardening Questions — Page 2 of 4

MCQeasy

A DevOps team is tasked with upgrading a Kubernetes cluster from version 1.21 to 1.22. They want to minimize downtime and follow best practices. Which approach should they take?

A.Upgrade worker nodes first, then the control plane

B.Upgrade etcd to 1.22 first, then the API server

C.Upgrade the control plane from 1.21 to 1.22 first, then upgrade worker nodes

D.Drain all nodes, then upgrade all components to 1.22 at once

AnswerC

Component upgrades must follow version skew policy; control plane first.

Why this answer

Option C is correct because the Kubernetes upgrade process mandates upgrading the control plane first, as it is the authoritative source for cluster state and API operations. Worker nodes can then be upgraded to match the control plane version, ensuring compatibility and minimizing downtime by allowing workloads to continue running during the node upgrade phase.

Exam trap

The trap here is that candidates often assume upgrading worker nodes first is safer to avoid control plane downtime, but Kubernetes requires the control plane to be upgraded first to maintain version skew compatibility and cluster stability.

How to eliminate wrong answers

Option A is wrong because upgrading worker nodes before the control plane violates the Kubernetes version skew policy, which requires the control plane to be at the highest version; doing so could cause API server incompatibility with node components like kubelet. Option B is wrong because etcd is upgraded as part of the control plane upgrade process, not independently first, and the API server must be upgraded before or simultaneously with etcd to maintain cluster stability. Option D is wrong because draining all nodes before upgrading any component would cause unnecessary total cluster downtime, and upgrading all components at once ignores the required sequential upgrade order (control plane first, then nodes) and version skew support.

Practice this question →

MCQhard

During a security audit, you run kube-bench and find that the API server audit logging is not enabled. Which set of flags should be added to the kube-apiserver to enable audit logging with a policy file located at /etc/kubernetes/audit-policy.yaml?

A.--audit-log-path=/var/log/kubernetes/audit.log --audit-policy-file=/etc/kubernetes/audit-policy.yaml

B.--audit-log-maxage=30 --audit-policy-file=/etc/kubernetes/audit-policy.yaml

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

D.--audit-log-path=/var/log/kubernetes/audit.log --audit-webhook-config-file=/etc/kubernetes/audit-policy.yaml

AnswerA

These flags enable audit logging to the specified file and use the policy file to control what is logged.

Why this answer

Option A is correct because enabling audit logging in kube-apiserver requires both `--audit-log-path` to specify the output file and `--audit-policy-file` to define the audit policy rules. Without the policy file, the API server will not know which events to log, and without the log path, no audit logs will be written.

Exam trap

The trap here is that candidates often confuse `--audit-policy-file` with `--audit-webhook-config-file` or assume that providing only the log path or only the policy file is sufficient, when both are required for local audit logging to function.

How to eliminate wrong answers

Option B is wrong because it includes `--audit-log-maxage=30` but omits `--audit-log-path`, so no audit log file is created; the policy file alone cannot enable logging. Option C is wrong because it provides `--audit-log-path` and `--audit-log-maxbackup=10` but lacks `--audit-policy-file`, meaning the API server will not apply any audit policy and will not log events. Option D is wrong because `--audit-webhook-config-file` is used for sending audit events to an external webhook, not for specifying a local policy file; the correct flag for a local policy is `--audit-policy-file`.

Practice this question →

MCQhard

You need to run kube-bench on a control plane node. Which command should you use?

A.kube-bench run --targets=controlplane

B.kube-bench run --targets=master

C.kube-bench run --targets=node

D.kube-bench run --targets=etcd

AnswerB

This runs checks for control plane components.

Why this answer

Option B is correct because `kube-bench` uses the `--targets` flag to specify which CIS benchmark targets to scan, and for control plane nodes, the correct target is `master` (not `controlplane`). This is because the CIS Kubernetes Benchmark historically refers to the control plane node as the 'master' node, and `kube-bench` follows that naming convention.

Exam trap

The trap here is that candidates assume the target name matches the modern Kubernetes terminology 'controlplane', but `kube-bench` still uses the legacy term 'master' for backward compatibility with the CIS Benchmark.

How to eliminate wrong answers

Option A is wrong because `--targets=controlplane` is not a valid target in `kube-bench`; the tool uses `master` for control plane nodes. Option C is wrong because `--targets=node` targets worker nodes, not the control plane. Option D is wrong because `--targets=etcd` only scans the etcd component, not the full control plane node.

Practice this question →

MCQmedium

A cluster administrator wants to encrypt secrets at rest in etcd. Which resource must be created to configure encryption?

A.KMSProvider

B.EncryptionConfiguration

C.SecretEncryptionConfig

D.EncryptionConfig

AnswerB

This is the correct resource for configuring encryption at rest.

Why this answer

The correct resource is an EncryptionConfiguration object, which is a Kubernetes API resource that defines how to encrypt secrets at rest in etcd. It specifies providers (such as aesgcm, secretbox, or kms) and their order of precedence for encrypting and decrypting data. This configuration is passed to the kube-apiserver via the --encryption-provider-config flag.

Exam trap

The trap here is that candidates confuse the generic term 'encryption config' with the exact Kubernetes API resource name 'EncryptionConfiguration', or they mistakenly think a KMS provider is a standalone resource rather than a provider type within the EncryptionConfiguration.

How to eliminate wrong answers

Option A is wrong because KMSProvider is not a Kubernetes resource; it is a type of encryption provider (e.g., using a Key Management Service) that can be referenced within an EncryptionConfiguration, not a standalone resource. Option C is wrong because SecretEncryptionConfig is not a valid Kubernetes API resource; the correct resource name is EncryptionConfiguration. Option D is wrong because EncryptionConfig is not a valid Kubernetes resource; the exact API resource name is EncryptionConfiguration (v1) in the apiserver.config.k8s.io group.

Practice this question →

Multi-Selectmedium

Which TWO actions are recommended by the CIS Kubernetes Benchmark for securing etcd?

Select 2 answers

A.Enable TLS client-to-server and peer communication

B.Disable anonymous authentication on etcd

C.Run etcd as a Service type LoadBalancer

D.Restrict access to etcd using RBAC

E.Use etcd's built-in encryption at rest

AnswersA, D

Enabling TLS encrypts communication and verifies identities.

Why this answer

Option A is correct because the CIS Kubernetes Benchmark recommends enabling TLS for both client-to-server and peer communication in etcd 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 all cluster state and secrets.

Exam trap

The trap here is that candidates often confuse etcd's built-in encryption at rest (which is not recommended by the CIS Benchmark) with the Kubernetes API server's encryption provider, leading them to select option E instead of focusing on TLS and RBAC as the benchmark's explicit recommendations.

Practice this question →

MCQhard

You need to restrict access to etcd so that only the API server can communicate with it. Which method should you use?

A.Configure etcd with TLS client certificates and require authentication

B.Set the etcd flag --peer-auto-tls=true

C.Configure etcd to use RBAC with a role that allows only the API server

D.Use a firewall rule to restrict access to etcd's port from the API server's IP

AnswerA

TLS client authentication ensures only authorized clients can connect.

Why this answer

Option A is correct because etcd supports mutual TLS (mTLS) authentication, which requires clients to present a valid TLS certificate signed by a trusted CA. By configuring etcd with `--client-cert-auth=true` and providing the API server's client certificate, you ensure that only the API server (or any client with a valid certificate) can communicate with etcd. This is the recommended Kubernetes approach to restrict access to etcd, as it cryptographically verifies the identity of the client.

Exam trap

The trap here is that candidates often confuse network-level restrictions (firewall rules) with identity-based authentication (mTLS), or mistakenly think etcd supports RBAC like Kubernetes, leading them to choose options D or C.

How to eliminate wrong answers

Option B is wrong because `--peer-auto-tls=true` enables automatic TLS for etcd peer-to-peer communication between etcd members, not for client-to-server communication; it does not restrict client access. Option C is wrong because etcd does not support RBAC natively; RBAC is a Kubernetes API server feature, not an etcd feature, and etcd uses certificate-based authentication, not role-based access control. Option D is wrong because a firewall rule only restricts network access at the IP/port level, but it does not authenticate the API server's identity; any process on the API server's node could potentially connect to etcd, and it does not protect against compromised nodes or spoofed IPs.

Practice this question →

MCQmedium

A security audit reveals that the etcd datastore is not encrypted at rest. Which resource should be created to enable encryption of secrets at rest?

A.EncryptionConfiguration

B.EtcdEncryption

C.EncryptionConfig

D.SecretEncryption

AnswerA

This resource defines providers and keys for encryption at rest.

Why this answer

To enable encryption of secrets at rest in Kubernetes, you must create an EncryptionConfiguration resource. This resource defines which encryption providers (e.g., AES-CBC, secretbox) to use and how to encrypt resources stored in etcd. The kube-apiserver reads this configuration via the --encryption-provider-config flag and applies it to all resources in the specified resource group, such as secrets.

Exam trap

CNCF often tests the exact API resource name, and candidates mistakenly pick 'EtcdEncryption' or 'EncryptionConfig' because they sound plausible, but only 'EncryptionConfiguration' is the correct Kubernetes resource defined in the apiserver configuration.

How to eliminate wrong answers

Option B is wrong because EtcdEncryption is not a valid Kubernetes API resource; the correct resource is EncryptionConfiguration. Option C is wrong because EncryptionConfig is not a Kubernetes resource name; it might be confused with the kube-apiserver configuration file but does not exist as an API object. Option D is wrong because SecretEncryption is not a Kubernetes resource; encryption at rest applies to multiple resource types, not just secrets, and the resource is named EncryptionConfiguration.

Practice this question →

MCQmedium

You run 'kube-bench' on a cluster node and get a failure for the test 'Ensure that the --anonymous-auth argument is set to false' (ID: 1.2.1). Which file do you need to modify to fix this issue?

A./etc/kubernetes/kubelet.conf

B./etc/kubernetes/manifests/kube-apiserver.yaml

C./etc/kubernetes/pki/

D./var/lib/kubelet/config.yaml

AnswerB

This is the static pod manifest for the API server in kubeadm clusters.

Why this answer

The kube-bench test ID 1.2.1 checks the kube-apiserver configuration for the `--anonymous-auth` flag. The API server is a static pod managed by the kubelet, and its configuration is defined in the manifest file `/etc/kubernetes/manifests/kube-apiserver.yaml`. To fix the failure, you must edit this file to set `--anonymous-auth=false`.

Exam trap

The trap here is that candidates often confuse the kubelet configuration file (`/var/lib/kubelet/config.yaml`) with the API server manifest, but the `--anonymous-auth` flag is specific to the API server, not the kubelet.

How to eliminate wrong answers

Option A is wrong because `/etc/kubernetes/kubelet.conf` is the kubelet's bootstrap configuration file, not the API server's manifest; it does not control the `--anonymous-auth` flag. Option C is wrong because `/etc/kubernetes/pki/` is a directory containing TLS certificates and keys, not configuration files for the API server. Option D is wrong because `/var/lib/kubelet/config.yaml` is the kubelet's own configuration file, which does not contain the `--anonymous-auth` argument for the API server.

Practice this question →

Multi-Selecteasy

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

Select 2 answers

A.Use firewall rules to restrict access to etcd port 2379

B.Use TLS client certificates for authentication

C.Enable etcd RBAC

D.Use etcd's built-in password authentication

E.Set the --etcd-certfile flag on kube-apiserver

AnswersB, C

TLS client certificates authenticate clients to etcd.

Why this answer

Option B is correct because etcd supports mutual TLS (mTLS) authentication, where the client (e.g., kube-apiserver) presents a client certificate signed by the etcd CA. This ensures that only authenticated clients can communicate with etcd, effectively restricting access. Option C is correct because etcd has its own Role-Based Access Control (RBAC) system, which can be enabled to restrict read/write operations to specific users or roles, providing fine-grained access control.

Exam trap

The trap here is that candidates often confuse network-level controls (firewall rules) or API server flags with actual etcd authentication/authorization mechanisms, or mistakenly believe etcd supports password authentication like traditional databases.

Practice this question →

MCQmedium

An administrator runs kube-bench on a node and sees a warning about the kubelet anonymous authentication being enabled. Which kubelet flag should be set to disable anonymous access?

A.--anonymous-auth=false

B.--anonymous-auth=true

C.--enable-anonymous=false

D.--disable-anonymous=true

AnswerA

Setting --anonymous-auth=false disables anonymous authentication for the kubelet, which is a CIS benchmark recommendation.

Why this answer

Option A is correct because the kubelet's `--anonymous-auth` flag controls whether requests to the kubelet API that are not rejected by other authentication modules are treated as anonymous requests. Setting `--anonymous-auth=false` disables anonymous access, requiring all requests to present valid credentials. This directly addresses the kube-bench warning about anonymous authentication being enabled, which is a security concern as it allows unauthenticated access to the kubelet's API.

Exam trap

The trap here is that candidates may confuse the kubelet's `--anonymous-auth` flag with similar-sounding but non-existent flags like `--enable-anonymous` or `--disable-anonymous`, or mistakenly think that setting the flag to `true` disables anonymous access.

How to eliminate wrong answers

Option B is wrong because `--anonymous-auth=true` enables anonymous access, which is the opposite of what is needed to disable it. Option C is wrong because `--enable-anonymous=false` is not a valid kubelet flag; the correct flag is `--anonymous-auth`. Option D is wrong because `--disable-anonymous=true` is not a valid kubelet flag; the kubelet uses `--anonymous-auth` with a boolean value to control anonymous access.

Practice this question →

MCQeasy

Which admission plugin enforces that kubelets cannot modify pods they do not own?

A.PodSecurity

B.AlwaysPullImages

C.NodeRestriction

D.ServiceAccount

AnswerC

This plugin restricts kubelet self-service APIs.

Why this answer

The NodeRestriction admission plugin ensures that kubelets can only modify Node and Pod objects that are bound to their own node. It enforces that a kubelet cannot update or delete pods it does not own, preventing a compromised or misconfigured kubelet from interfering with workloads on other nodes.

Exam trap

CNCF often tests the NodeRestriction plugin as a control for kubelet authorization, and the trap here is confusing it with PodSecurity (which handles pod security contexts) or AlwaysPullImages (which handles image pull policy), rather than recognizing that NodeRestriction specifically limits what a kubelet can modify.

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 pod creation, not kubelet authorization. Option B is wrong because AlwaysPullImages forces every pod to pull its container images from the registry with credentials, but does not restrict kubelet modifications to pods. Option D is wrong because ServiceAccount is an admission plugin that manages service account automounting and token projection, not kubelet node-level access control.

Practice this question →

Drag & Dropmedium

Arrange the steps to create and enforce a Pod Security Policy (PSP) in a Kubernetes cluster.

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

Steps

Order

Why this order

PSPs require enabling the admission controller, creating the policy, granting access via RBAC, and binding to subjects. Testing confirms enforcement.

Practice this question →

MCQmedium

You are configuring kubelet to protect kernel defaults. Which flag enables this?

A.--security-opt=protect-kernel

B.--protect-kernel-defaults

C.--enable-protect-kernel

D.--kernel-security

AnswerB

Correct flag to protect kernel settings.

Why this answer

The `--protect-kernel-defaults` flag is a kubelet option that, when set to `true`, enforces kernel tunable protections by checking that sysctl settings like `vm.overcommit_memory`, `vm.panic_on_oom`, and `kernel.panic` match the kubelet's expected safe defaults. This is a critical hardening measure to prevent container breakout scenarios where a compromised pod could weaken host kernel parameters.

Exam trap

The trap here is that candidates confuse Docker's `--security-opt` flags (which apply per-container) with kubelet's node-level hardening flags, or they invent plausible-sounding flag names like `--enable-protect-kernel` that do not exist in the kubelet reference.

How to eliminate wrong answers

Option A is wrong because `--security-opt=protect-kernel` is a Docker run flag, not a kubelet flag; it applies to individual containers, not the kubelet's global kernel protection. Option C is wrong because `--enable-protect-kernel` is not a valid kubelet flag; the correct syntax uses `--protect-kernel-defaults` without the 'enable' prefix. Option D is wrong because `--kernel-security` is not a recognized kubelet flag; it might be confused with AppArmor or SELinux profiles, but it does not enforce kernel default protections.

Practice this question →

MCQmedium

You are creating a ServiceAccount that should not automatically mount its token to pods. Which field should be set in the ServiceAccount manifest?

A.automountServiceAccountToken: false

B.disableAutomount: true

C.tokenMountDisabled: true

D.mountToken: false

AnswerA

This field in the ServiceAccount spec disables automatic mounting of the service account token.

Why this answer

Option A is correct because the `automountServiceAccountToken` field in a ServiceAccount manifest, when set to `false`, prevents pods using that ServiceAccount from automatically mounting the service account token as a volume. This is a security hardening measure to reduce the attack surface in case a pod is compromised, as the token could be used to authenticate to the Kubernetes API server.

Exam trap

The trap here is that candidates may confuse the ServiceAccount-level field with the Pod-level field of the same name, or invent non-existent field names like `disableAutomount` or `tokenMountDisabled`, instead of recalling the exact API field `automountServiceAccountToken`.

How to eliminate wrong answers

Option B is wrong because `disableAutomount: true` is not a valid field in the ServiceAccount API; the correct field name is `automountServiceAccountToken`. Option C is wrong because `tokenMountDisabled: true` does not exist in the Kubernetes API; it is a fabricated field name. Option D is wrong because `mountToken: false` is not a recognized field; the correct boolean field is `automountServiceAccountToken`, and setting it to `false` achieves the desired behavior.

Practice this question →

Multi-Selecthard

Which THREE of the following are recommended actions to secure the Kubernetes Dashboard? (Choose three.)

Select 3 answers

A.Use RBAC to create a dedicated service account with minimal permissions

B.Expose the Dashboard via an Ingress with a public domain

C.Enable HTTPS for Dashboard communications

D.Do not bind the Dashboard's service account to the cluster-admin role

E.Avoid exposing the Dashboard via a public LoadBalancer

AnswersA, D, E

Least privilege reduces risk.

Why this answer

Option A is correct because the Kubernetes Dashboard should be accessed using a dedicated service account with minimal permissions via RBAC. This follows the principle of least privilege, ensuring the dashboard only has the permissions necessary for its function, reducing the attack surface. By default, the dashboard's service account has minimal permissions, but binding it to a role with excessive privileges (like cluster-admin) would be a security risk.

Exam trap

CNCF often tests the distinction between actions that are recommended (like using RBAC with minimal permissions) versus actions that are explicitly discouraged (like binding to cluster-admin or exposing via public endpoints), and candidates may mistakenly think enabling HTTPS is a 'recommended action' in this context, but it is not listed among the three correct options here because the question focuses on access control and exposure, not encryption.

Practice this question →

MCQeasy

Which flag disables anonymous authentication on the API server?

A.--enable-admission-plugins=NodeRestriction

B.--authorization-mode=RBAC

C.--anonymous-auth=false

D.--client-ca-file=<path>

AnswerC

This flag disables anonymous authentication.

Why this answer

The `--anonymous-auth=false` flag explicitly disables anonymous authentication on the Kubernetes API server. When set to false, the API server will reject requests from unauthenticated users (those not presenting valid credentials), enforcing that all requests must be authenticated. This is a critical security hardening step to prevent anonymous access to the cluster's control plane.

Exam trap

The trap here is that candidates often confuse authentication with authorization, mistakenly selecting `--authorization-mode=RBAC` (Option B) thinking it controls who can access the API, when in fact RBAC only controls what authenticated users can do, not whether anonymous users are allowed.

How to eliminate wrong answers

Option A is wrong because `--enable-admission-plugins=NodeRestriction` enables the NodeRestriction admission controller, which limits the permissions of kubelet nodes but does not control anonymous authentication. Option B is wrong because `--authorization-mode=RBAC` sets the authorization mode to Role-Based Access Control, which governs what authenticated users can do, not whether unauthenticated users can connect. Option D is wrong because `--client-ca-file=<path>` specifies the CA certificate used to validate client certificates for TLS-based authentication, but it does not disable anonymous authentication; anonymous requests are still allowed unless explicitly denied.

Practice this question →

MCQmedium

You need to enable encryption at rest for secrets in the cluster. Which resource should you create to configure encryption providers?

A.EncryptionConfiguration

B.EncryptionProviderConfig

C.EncryptionPolicy

D.SecretEncryptionConfig

AnswerA

This is the correct resource to configure encryption providers such as aescbc or secretbox.

Why this answer

To enable encryption at rest for Kubernetes secrets, you must create an EncryptionConfiguration resource. This object defines which encryption providers (e.g., aesgcm, aescbc, secretbox, or identity) should be used to encrypt secrets stored in etcd. The API server reads this configuration from a file specified via the --encryption-provider-config flag, allowing you to control encryption at the provider level.

Exam trap

CNCF often tests the exact name of the Kubernetes resource, and candidates confuse EncryptionConfiguration with similar-sounding but nonexistent names like EncryptionProviderConfig or EncryptionPolicy, which are not part of the Kubernetes API.

How to eliminate wrong answers

Option B is wrong because EncryptionProviderConfig is not a valid Kubernetes resource; the correct resource name is EncryptionConfiguration. Option C is wrong because EncryptionPolicy is a generic term and not a specific Kubernetes API object used for configuring encryption providers. Option D is wrong because SecretEncryptionConfig does not exist as a Kubernetes resource; the configuration applies to all secrets cluster-wide via EncryptionConfiguration.

Practice this question →

MCQmedium

Which etcd encryption provider is considered strongest for encrypting secrets at rest?

A.secretbox

B.identity

C.aesgcm

D.aescbc

AnswerD

aescbc provides strong encryption with AES in CBC mode.

Why this answer

Option D (aescbc) is correct because AES-CBC with a 256-bit key is the recommended and strongest encryption provider for encrypting secrets at rest in etcd, as specified in the Kubernetes documentation. It provides robust encryption using the Advanced Encryption Standard in Cipher Block Chaining mode, which is widely accepted for data-at-rest encryption in production environments.

Exam trap

CNCF often tests the misconception that AES-GCM (aescbc's alternative) is stronger due to its authenticated encryption, but the trap here is that aescbc is the officially recommended provider for etcd encryption at rest in Kubernetes, while aesgcm is not supported for this purpose.

How to eliminate wrong answers

Option A (secretbox) is wrong because secretbox is not a valid encryption provider in Kubernetes; it is a reference to the NaCl library's secret-key encryption, but Kubernetes does not support it for etcd encryption. Option B (identity) is wrong because identity is the default provider that stores secrets in plaintext without any encryption, offering no protection at rest. Option C (aesgcm) is wrong because AES-GCM, while a strong authenticated encryption mode, is not recommended for etcd encryption due to its nonce reuse vulnerability and lack of support for key rotation in the Kubernetes encryption configuration.

Practice this question →

Multi-Selectmedium

Which TWO of the following are recommended practices for securing the Kubernetes Dashboard? (Select TWO)

Select 2 answers

A.Use HTTP instead of HTTPS for Dashboard traffic

B.Disable authentication for the Dashboard

C.Restrict Dashboard access using RBAC with minimal privileges

D.Use the default cluster-admin ServiceAccount for Dashboard access

E.Avoid exposing the Dashboard on a public IP address

AnswersC, E

RBAC ensures users have only necessary permissions.

Why this answer

Option C is correct because the Kubernetes Dashboard should be secured using Role-Based Access Control (RBAC) with minimal privileges. This follows the principle of least privilege, ensuring that users or service accounts accessing the Dashboard have only the permissions necessary for their tasks, reducing the attack surface and potential blast radius in case of compromise.

Exam trap

CNCF often tests the misconception that disabling authentication or using HTTP simplifies setup, but the trap here is that these practices completely bypass security controls, while candidates may overlook that RBAC with minimal privileges is the correct hardening step.

Practice this question →

MCQmedium

An administrator wants to secure etcd communication. Which of the following is required to enable TLS for client-to-etcd communication?

A.Set ETCD_TLS_ENABLE=true environment variable

B.--cert-file=<cert-file> and --key-file=<key-file>

C.--client-cert-auth=true and --trusted-ca-file=<CA-file>

D.--tls-cert-file and --tls-key-file

AnswerB

These flags enable TLS for client connections.

Why this answer

To enable TLS for client-to-etcd communication, the etcd server must present a certificate to clients. The `--cert-file` and `--key-file` flags specify the server's TLS certificate and private key, which are required for the TLS handshake. Without these, etcd cannot serve HTTPS to clients.

Exam trap

The trap here is that candidates confuse the flags for enabling TLS (`--cert-file`/`--key-file`) with the flags for enabling client certificate authentication (`--client-cert-auth`/`--trusted-ca-file`), or they misremember the exact flag names as `--tls-cert-file`/`--tls-key-file` which do not exist in etcd.

How to eliminate wrong answers

Option A is wrong because `ETCD_TLS_ENABLE` is not a valid environment variable; etcd uses command-line flags, not environment variables, for TLS configuration. Option C is wrong because `--client-cert-auth=true` and `--trusted-ca-file` enable mutual TLS (client certificate authentication), which is optional and not required for basic TLS encryption. Option D is wrong because the correct flag names are `--cert-file` and `--key-file`, not `--tls-cert-file` and `--tls-key-file`; the latter are not recognized by etcd.

Practice this question →

Multi-Selectmedium

Which TWO actions are recommended by the CIS Kubernetes Benchmark to secure the API server?

Select 2 answers

A.Set --authorization-mode=RBAC

B.Set --enable-admission-plugins=NodeRestriction

C.Set --authorization-mode=AlwaysAllow

D.Set --insecure-port=8080

E.Set --anonymous-auth=false

AnswersA, E

Enables RBAC authorization.

Why this answer

Option A is correct because the CIS Kubernetes Benchmark recommends setting `--authorization-mode=RBAC` to enforce role-based access control, which restricts API server access based on user roles and permissions. This ensures that only authorized users and service accounts can perform specific actions, aligning with the principle of least privilege.

Exam trap

CNCF often tests the distinction between recommended admission plugins (like NodeRestriction) and authorization/authentication settings, so candidates may mistakenly select NodeRestriction as a top-level security action when the question specifically targets authorization and authentication controls.

Practice this question →

MCQmedium

You run kube-bench on a node and it reports a failure for 'Ensure that the --anonymous-auth argument is set to false' for the kubelet service. Which file must you modify to fix this?

A./etc/kubernetes/manifests/kube-apiserver.yaml

B./etc/kubernetes/pki/ca.crt

C./etc/kubernetes/kubelet.conf

D./var/lib/kubelet/config.yaml

AnswerD

Kubelet configuration is often stored in this YAML file; setting authentication.anonymous.enabled: false fixes the issue.

Why this answer

Option D is correct because kube-bench checks the kubelet configuration for the `--anonymous-auth` flag, which is set in the kubelet's configuration file. By default, the kubelet reads its configuration from `/var/lib/kubelet/config.yaml` (or a path specified by `--config` in the kubelet service). Setting `anonymous-auth: false` in this file disables anonymous requests to the kubelet API, enforcing authentication.

Exam trap

The trap here is that candidates confuse the kubelet's configuration file with the kubelet's kubeconfig file (`kubelet.conf`) or the API server manifest, because all three are involved in authentication but serve different roles.

How to eliminate wrong answers

Option A is wrong because `/etc/kubernetes/manifests/kube-apiserver.yaml` is the static pod manifest for the API server, not the kubelet; the `--anonymous-auth` flag for the kubelet is not configured there. Option B is wrong because `/etc/kubernetes/pki/ca.crt` is the CA certificate file used for TLS verification, not a configuration file for kubelet authentication settings. Option C is wrong because `/etc/kubernetes/kubelet.conf` is a kubeconfig file used by the kubelet to authenticate to the API server, not the file where kubelet server-side authentication options like `--anonymous-auth` are set.

Practice this question →

MCQhard

A security auditor recommends enabling audit logging for the Kubernetes API server with a policy that logs all requests at the Metadata level. Which configuration ensures this requirement?

A.Enable the 'Audit' admission plugin

B.Set --audit-log-level=Metadata

C.Use --audit-log-maxage=30 to retain logs

D.Create an audit policy file with 'level: Metadata' for all resources and pass it via --audit-policy-file

AnswerD

The audit policy file defines the level of logging for different request types.

Why this answer

Option D is correct because Kubernetes audit logging requires an audit policy file that defines the log level for different request stages and resources. The requirement to log all requests at the Metadata level is achieved by creating a policy file with `level: Metadata` for all resources (or a catch-all rule) and passing it to the API server via the `--audit-policy-file` flag. The audit policy file is the only mechanism to specify the log level (None, Metadata, Request, RequestResponse) per resource or stage.

Exam trap

The trap here is that candidates confuse the audit policy file's `level` field with a command-line flag like `--audit-log-level`, which does not exist, leading them to select option B instead of understanding that the level is defined in the policy file.

How to eliminate wrong answers

Option A is wrong because the 'Audit' admission plugin does not exist; Kubernetes uses an audit backend (e.g., log backend) configured via flags, not an admission plugin. Option B is wrong because `--audit-log-level` is not a valid flag; the log level is defined inside the audit policy file, not as a command-line argument. Option C is wrong because `--audit-log-maxage` controls log rotation (days to retain old log files) but does not enable or configure the audit logging level or policy.

Practice this question →

MCQeasy

Which kubectl command can be used to check the CIS benchmark compliance of a Kubernetes cluster?

A.kube-bench run --targets=master,worker

B.kubectl security-check

C.kubectl cis-benchmark

D.kubectl audit cluster

AnswerA

kube-bench is designed to run CIS benchmark checks against Kubernetes clusters.

Why this answer

Option A is correct because `kube-bench` is the official open-source tool from Aqua Security that runs CIS Kubernetes Benchmark checks against a cluster. It scans nodes by targeting specific roles (master, worker) and compares the cluster configuration against the CIS Benchmark controls, reporting pass/fail for each check.

Exam trap

CNCF often tests the misconception that kubectl has built-in security or compliance subcommands, when in reality tools like kube-bench are separate executables that must be installed and run independently.

How to eliminate wrong answers

Option B is wrong because `kubectl security-check` is not a valid kubectl command; kubectl does not have a built-in subcommand for security benchmarking. Option C is wrong because `kubectl cis-benchmark` is not a valid kubectl command; the CIS benchmark is not executed via kubectl but via a separate tool like kube-bench. Option D is wrong because `kubectl audit cluster` is not a valid kubectl command; cluster auditing is typically done via API server audit logs or tools like kube-bench, not a kubectl subcommand.

Practice this question →

100

Multi-Selectmedium

Which TWO of the following are CIS Benchmark recommendations for securing the API server?

Select 2 answers

A.Enable the insecure port (--insecure-port)

B.Disable anonymous authentication

C.Enable audit logging

D.Use ABAC mode for authorization

E.Disable TLS

AnswersB, C

Anonymous auth should be disabled.

Why this answer

Option B is correct because the CIS Benchmark for Kubernetes recommends disabling anonymous authentication to ensure that all requests to the API server are authenticated. By setting the `--anonymous-auth=false` flag on the kube-apiserver, unauthenticated requests are rejected, which prevents anonymous users from accessing the cluster. This is a fundamental security hardening step to enforce identity verification for every API call.

Exam trap

CNCF often tests the distinction between deprecated/insecure features (like the insecure port or disabling TLS) and the actual CIS-recommended secure defaults, tempting candidates to select options that sound like hardening but are actually anti-patterns.

Practice this question →

101

MCQhard

A cluster has been hardened by setting --anonymous-auth=false and enabling RBAC. However, kube-bench still reports a failure for the kubelet check 'Ensure that the --anonymous-auth argument is set to false'. What could be the reason?

A.The kubelet configuration file does not set --anonymous-auth=false

B.The API server is running with --authorization-mode=AlwaysAllow

C.The kubelet is using a self-signed certificate

D.The NodeRestriction admission plugin is not enabled

AnswerA

kube-bench checks kubelet flags, which must be set independently.

Why this answer

The kubelet can have its authentication settings configured either via command-line arguments or via a KubeletConfiguration file. If the kubelet configuration file does not explicitly set `authentication.anonymous.enabled` to `false`, the kubelet may still allow anonymous access even if the `--anonymous-auth=false` argument is passed on the command line, because the configuration file takes precedence over command-line flags. kube-bench checks the effective configuration, so if the file overrides the flag, the check fails.

Exam trap

The trap here is that candidates assume command-line flags always override the kubelet configuration file, but in reality the configuration file takes precedence for kubelet settings, so both must be set consistently.

How to eliminate wrong answers

Option B is wrong because the API server's `--authorization-mode=AlwaysAllow` affects authorization for API server requests, not the kubelet's anonymous authentication setting; kube-bench's kubelet check is specific to the kubelet's own `--anonymous-auth` flag. Option C is wrong because using a self-signed certificate relates to TLS certificate validation and does not impact the anonymous authentication setting; kube-bench has separate checks for certificate validation. Option D is wrong because the NodeRestriction admission plugin controls what node identities can do via the API server, not the kubelet's own anonymous authentication configuration.

Practice this question →

102

MCQmedium

Which flag is used to restrict the kubelet's ability to modify node status and pods?

A.--authorization-mode=Webhook

B.--read-only-port=0

C.--protect-kernel-defaults=true

D.--authentication-token-webhook=true

AnswerA

This enables webhook authorization for the kubelet, which can restrict actions.

Why this answer

The `--authorization-mode=Webhook` flag configures the kubelet to use an external authorization webhook (e.g., via the SubjectAccessReview API) for all requests, including those to modify node status and pods. This restricts the kubelet's ability to autonomously update its own node status or pod resources, as every such request must be approved by the external authorizer, enforcing a least-privilege model.

Exam trap

The trap here is that candidates confuse authentication (verifying identity) with authorization (controlling actions), so they pick `--authentication-token-webhook=true` thinking it restricts the kubelet, when in fact it only validates tokens without limiting what the kubelet can do once authenticated.

How to eliminate wrong answers

Option B is wrong because `--read-only-port=0` disables the kubelet's read-only port (10255), which prevents unauthenticated read access to metrics and stats, but does not restrict the kubelet's ability to modify node status or pods. Option C is wrong because `--protect-kernel-defaults=true` ensures the kubelet checks and enforces kernel parameter settings (e.g., sysctl) for security, but it does not control authorization for node or pod modifications. Option D is wrong because `--authentication-token-webhook=true` enables token-based authentication via a webhook, verifying the identity of API requesters, but it does not restrict the kubelet's own ability to modify resources—that requires authorization, not authentication.

Practice this question →

103

MCQeasy

Which of the following flags should be set on the kube-apiserver to disable anonymous authentication?

A.--disable-anonymous-auth

B.--enable-anonymous-auth=false

C.--anonymous-auth=false

D.--anonymous-auth=off

AnswerC

This flag disables anonymous authentication.

Why this answer

Option C is correct because the kube-apiserver uses the `--anonymous-auth` flag to control anonymous requests. Setting `--anonymous-auth=false` explicitly disables anonymous authentication, meaning unauthenticated requests (those without a valid bearer token or client certificate) will be rejected with a 401 Unauthorized response. This is a critical hardening step to prevent unauthorized access to the Kubernetes API server.

Exam trap

The trap here is that candidates confuse the flag name with a 'disable' or 'enable' prefix pattern common in other tools, or assume a non-boolean value like 'off' or 'false' string works, when Kubernetes strictly requires the exact `--anonymous-auth=false` syntax.

How to eliminate wrong answers

Option A is wrong because `--disable-anonymous-auth` is not a valid kube-apiserver flag; the correct flag name is `--anonymous-auth`. Option B is wrong because `--enable-anonymous-auth=false` is not a recognized flag; Kubernetes does not use an `enable-` prefix for this setting, and the flag must be `--anonymous-auth` with a boolean value. Option D is wrong because `--anonymous-auth=off` uses a string value 'off' instead of the required boolean `false`; the kube-apiserver expects a boolean (true/false), and 'off' will be interpreted as true (since it is a non-empty string), leaving anonymous auth enabled.

Practice this question →

104

MCQmedium

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

A.The binding should be a RoleBinding instead of ClusterRoleBinding

B.It grants too broad permissions to the service account

C.The service account name must be changed

D.The binding is fine as long as the service account is used in the default namespace

AnswerB

Correct. cluster-admin gives superuser access, which should be avoided for service accounts.

Why this answer

The 'cluster-admin' ClusterRole grants super-user permissions across the entire cluster, including access to all namespaces and all resources. Binding this role to a service account via a ClusterRoleBinding gives that service account unrestricted cluster-wide privileges, which violates the principle of least privilege. This is a significant security concern because if the service account is compromised, an attacker gains full control over the cluster.

Exam trap

The trap here is that candidates may focus on the binding type (ClusterRoleBinding vs RoleBinding) or namespace usage, rather than recognizing that the core issue is the excessive privileges of the 'cluster-admin' role itself, regardless of how it is bound.

How to eliminate wrong answers

Option A is wrong because a ClusterRoleBinding is necessary to bind a ClusterRole; a RoleBinding can only bind a ClusterRole to subjects within a specific namespace, but the security issue here is the excessive permissions of the 'cluster-admin' role itself, not the binding type. Option C is wrong because the service account name is irrelevant to the security concern; the problem is the permissions granted, not the identity. Option D is wrong because the binding is not fine; even if the service account is used only in the default namespace, the ClusterRoleBinding grants cluster-wide permissions, allowing the service account to access resources in any namespace, which is a severe security risk.

Practice this question →

105

MCQhard

You are configuring kubelet security. Which flag prevents containers from modifying kernel parameters?

A.--read-only-port=0

B.--protect-kernel-defaults

C.--kernel-memcg-notification

D.--allow-privileged=false

AnswerB

This flag prevents containers from modifying kernel parameters.

Why this answer

The `--protect-kernel-defaults` flag ensures that the kubelet enforces kernel parameter protections, preventing containers from modifying sensitive kernel parameters (e.g., via sysctl). This is a critical security hardening measure to maintain node stability and prevent container breakout through kernel tuning.

Exam trap

The trap here is that candidates confuse `--protect-kernel-defaults` with `--allow-privileged=false`, assuming that preventing privileged containers is sufficient to block kernel parameter changes, but non-privileged containers can still modify kernel parameters via sysctl unless explicitly restricted.

How to eliminate wrong answers

Option A is wrong because `--read-only-port=0` disables the read-only kubelet API port (10255), which reduces attack surface but does not prevent kernel parameter modification. Option C is wrong because `--kernel-memcg-notification` is a kubelet flag for memory cgroup notifications, unrelated to restricting kernel parameter changes. Option D is wrong because `--allow-privileged=false` prevents privileged containers but does not block non-privileged containers from modifying kernel parameters via sysctl or other mechanisms.

Practice this question →

106

MCQmedium

A security policy requires that all ServiceAccounts in a namespace do not automatically mount their tokens. How can this be achieved at the namespace level?

A.Set automountServiceAccountToken: false in each pod spec

B.Use a PodSecurityPolicy to deny token mounting

C.Set automountServiceAccountToken: false in the ServiceAccount definition

D.Delete the default ServiceAccount

AnswerC

This applies to all pods using that ServiceAccount.

Why this answer

Setting `automountServiceAccountToken: false` in the ServiceAccount definition applies the setting to all pods that use that ServiceAccount, effectively enforcing the policy at the namespace level when the default or all ServiceAccounts are configured this way. This is the correct approach because the ServiceAccount's `automountServiceAccountToken` field controls token mounting for pods referencing it, overriding any pod-level setting unless explicitly set in the pod spec.

Exam trap

CNCF often tests the distinction between namespace-level and pod-level controls, and the trap here is that candidates mistakenly think PodSecurityPolicy can control token mounting or that deleting the default ServiceAccount is a viable solution, when in fact the ServiceAccount's `automountServiceAccountToken` field is the intended namespace-wide mechanism.

How to eliminate wrong answers

Option A is wrong because setting `automountServiceAccountToken: false` in each pod spec is a per-pod solution, not a namespace-level enforcement; it requires manual configuration for every pod and does not scale or guarantee compliance across the namespace. Option B is wrong because PodSecurityPolicy (PSP) does not have a field to control ServiceAccount token mounting; PSP controls pod security contexts, volumes, and capabilities, but token mounting is governed by the ServiceAccount or pod spec, not PSP. Option D is wrong because deleting the default ServiceAccount does not prevent token mounting; Kubernetes will still create a new default ServiceAccount automatically, and pods without an explicit ServiceAccount will use the new default, which still mounts tokens by default.

Practice this question →

107

Multi-Selecteasy

Which TWO of the following flags are used to secure the kubelet?

Select 2 answers

A.--protect-kernel-defaults

B.--anonymous-auth=false

C.--enable-admission-plugins

D.--audit-log-path

E.--authorization-mode=RBAC

AnswersA, B

Correct. This flag protects kernel defaults.

Why this answer

The `--protect-kernel-defaults` flag is used to secure the kubelet by ensuring that kernel tunable parameters (e.g., `vm.overcommit_memory`, `kernel.panic`) are set to safe values. If the kernel defaults are not properly configured, the kubelet will fail to start, preventing insecure kernel settings from being used. This flag is part of the kubelet's security hardening measures, as recommended by the CIS Kubernetes Benchmark.

Exam trap

CNCF often tests the distinction between kubelet flags and API server flags, so the trap here is that candidates may confuse `--authorization-mode=RBAC` or `--audit-log-path` as kubelet security settings when they are actually API server parameters.

Practice this question →

108

MCQmedium

A security auditor runs kube-bench and reports that the kubelet is not configured with --protect-kernel-defaults. What is the impact of this misconfiguration?

A.Container runtime will not be able to pull images

B.The node will be unable to schedule pods

C.The kubelet will refuse to start

D.Kernel parameters may be modified, potentially reducing node security

AnswerD

Without --protect-kernel-defaults, kubelet does not enforce recommended kernel security settings.

Why this answer

The `--protect-kernel-defaults` flag ensures that the kubelet enforces kernel parameter hardening, preventing modifications that could weaken node security. Without it, a compromised or misconfigured pod could alter kernel settings (e.g., `net.ipv4.ip_forward`, `vm.overcommit_memory`), reducing the overall security posture of the node. This does not affect image pulling, pod scheduling, or kubelet startup.

Exam trap

The trap here is that candidates assume a missing security flag will cause an immediate failure (like kubelet not starting), when in reality the kubelet runs but the node becomes vulnerable to kernel parameter tampering.

How to eliminate wrong answers

Option A is wrong because the container runtime's ability to pull images depends on network connectivity and registry access, not on kernel parameter protection. Option B is wrong because pod scheduling is controlled by the scheduler and node conditions, not by the `--protect-kernel-defaults` flag; the node will still schedule pods. Option C is wrong because the kubelet will start without this flag; it only logs a warning or fails if the kernel parameters are not set correctly, but the flag itself does not prevent startup.

Practice this question →

109

MCQeasy

Which admission plugin should be used to enforce Pod Security Standards at the namespace level?

A.PodSecurity

B.PodSecurityPolicy

C.NodeRestriction

D.SecurityContextDeny

AnswerA

This plugin enforces Pod Security Standards.

Why this answer

Option A is correct because the PodSecurity admission plugin is the successor to PodSecurityPolicy (PSP) and is designed specifically to enforce Pod Security Standards (PSS) at the namespace level. It evaluates pods against the three predefined PSS levels (privileged, baseline, restricted) based on labels set on the namespace, and can be configured in warn, audit, or enforce mode. This plugin is built into the kube-apiserver and is the recommended approach for pod security in Kubernetes v1.25 and later.

Exam trap

CNCF often tests the fact that PodSecurityPolicy is deprecated and removed, so candidates who studied older material may mistakenly choose PodSecurityPolicy, not realizing it has been replaced by the PodSecurity admission plugin.

How to eliminate wrong answers

Option B is wrong because PodSecurityPolicy (PSP) was deprecated in Kubernetes v1.21 and removed in v1.25, and it enforces security policies cluster-wide via a CRD, not at the namespace level using Pod Security Standards. Option C is wrong because NodeRestriction is an admission plugin that limits the Node API objects a kubelet can modify, and has nothing to do with pod security standards. Option D is wrong because SecurityContextDeny is an older admission plugin that rejects pods with certain security context settings, but it does not enforce the namespace-scoped Pod Security Standards and is not the recommended replacement for PSP.

Practice this question →

110

MCQmedium

An administrator wants to prevent the kubelet from serving anonymous requests. Which flag should be set on the kubelet?

A.--client-ca-file=/etc/kubernetes/pki/ca.crt

B.--authorization-mode=Webhook

C.--anonymous-auth=false

D.--authentication-token-webhook=true

AnswerC

This disables anonymous authentication on the kubelet.

Why this answer

The `--anonymous-auth=false` flag explicitly disables anonymous authentication on the kubelet, preventing unauthenticated requests from being processed. By default, anonymous authentication is enabled (`--anonymous-auth=true`), which allows any unauthenticated user to make requests to the kubelet API. Setting this flag to `false` ensures that only authenticated clients can interact with the kubelet, directly addressing the requirement to block anonymous requests.

Exam trap

The trap here is that candidates often confuse authentication with authorization—they think setting a client CA file or enabling webhook authorization will block anonymous requests, but those controls only affect already-authenticated users or authorization decisions, not the initial authentication step where anonymous access is allowed by default.

How to eliminate wrong answers

Option A is wrong because `--client-ca-file` configures the certificate authority used to validate client certificates for mutual TLS authentication, but it does not disable anonymous authentication—anonymous requests are still allowed unless explicitly blocked. Option B is wrong because `--authorization-mode=Webhook` sets the authorization mode to delegate authorization decisions to an external webhook, but it does not affect authentication; anonymous users can still be authenticated and then authorized. Option D is wrong because `--authentication-token-webhook=true` enables token-based authentication via a webhook, but it does not disable anonymous authentication—anonymous requests remain permitted unless `--anonymous-auth` is set to `false`.

Practice this question →

111

MCQmedium

An administrator runs kube-bench on a cluster node and receives failures for CIS benchmark checks related to kubelet configuration. Which kubelet flag should be set to ensure that kernel defaults are not used when they might be insecure?

A.--protect-kernel-defaults

B.--read-only-port=0

C.--anonymous-auth=false

D.--kubelet-extra-args

AnswerA

This flag is explicitly checked by kube-bench for CIS compliance.

Why this answer

The `--protect-kernel-defaults` kubelet flag ensures that the kubelet will not use insecure kernel defaults by enforcing that certain sysctl settings (e.g., `kernel.panic`, `vm.overcommit_memory`) are set to secure values. If these kernel parameters are not explicitly configured to safe values, the kubelet will fail to start, preventing the node from running with potentially insecure kernel defaults. This directly addresses CIS benchmark checks that require hardening of the kubelet's interaction with the host kernel.

Exam trap

The trap here is that candidates often confuse `--protect-kernel-defaults` with other kubelet security flags like `--read-only-port` or `--anonymous-auth`, or mistakenly think `--kubelet-extra-args` is a direct kubelet flag, when in fact it is a kubeadm configuration option and not a solution for kernel default protection.

How to eliminate wrong answers

Option B is wrong because `--read-only-port=0` disables the read-only port (10255) on the kubelet, which prevents unauthenticated access to kubelet metrics, but it does not address kernel default security. Option C is wrong because `--anonymous-auth=false` disables anonymous authentication to the kubelet API, which is a separate CIS check for authentication hardening, not for kernel defaults. Option D is wrong because `--kubelet-extra-args` is a kubeadm configuration field used to pass additional flags to the kubelet, not a kubelet flag itself, and it does not specifically enforce kernel default protection.

Practice this question →

112

MCQeasy

What is the purpose of the --audit-log-path flag on the kube-apiserver?

A.It sets the maximum number of audit log files to retain.

B.It disables audit logging.

C.It enables audit logging and sets the output file path.

D.It specifies the path to the audit policy file.

AnswerC

This flag enables audit logging and specifies the log file location.

Why this answer

The `--audit-log-path` flag on the kube-apiserver enables audit logging and specifies the file path where audit events are written. Without this flag, audit logging is disabled by default. Setting this flag is the first step to capturing API request logs for security monitoring and compliance.

Exam trap

CNCF often tests the distinction between `--audit-log-path` (enables logging and sets output path) and `--audit-policy-file` (defines what to log), causing candidates to confuse the two flags.

How to eliminate wrong answers

Option A is wrong because the `--audit-log-maxbackup` flag, not `--audit-log-path`, controls the maximum number of audit log files to retain. Option B is wrong because the `--audit-log-path` flag enables audit logging, not disables it; disabling audit logging is the default behavior when the flag is omitted. Option D is wrong because the path to the audit policy file is set by the `--audit-policy-file` flag, not `--audit-log-path`.

Practice this question →

113

MCQeasy

What is the purpose of the CIS Kubernetes Benchmark?

A.To provide a set of security best practices for Kubernetes

B.To benchmark performance of Kubernetes clusters

C.To test network policies

D.To automate deployment of Kubernetes clusters

AnswerA

The CIS Benchmark outlines security recommendations.

Why this answer

The CIS Kubernetes Benchmark is a set of security best practices developed by the Center for Internet Security (CIS) specifically for hardening Kubernetes clusters. It provides prescriptive guidance on configuring cluster components (e.g., kube-apiserver, kubelet, etcd) to reduce the attack surface and meet compliance standards. Option A correctly identifies this purpose, as the benchmark is not about performance, networking, or automation.

Exam trap

The trap here is that candidates confuse the CIS Benchmark with a performance or automation tool, because 'benchmark' often implies performance testing in other contexts, but in Kubernetes security, it strictly refers to a compliance and hardening standard.

How to eliminate wrong answers

Option B is wrong because the CIS Kubernetes Benchmark focuses on security configuration, not performance benchmarking; performance metrics are measured by tools like the Kubernetes Performance and Scalability Working Group's benchmarks. Option C is wrong because while the benchmark includes recommendations for network policies, its scope is far broader, covering all aspects of cluster security (e.g., RBAC, secrets, pod security). Option D is wrong because the benchmark is a set of guidelines, not a deployment tool; automation of cluster deployment is handled by tools like kubeadm, Terraform, or Cluster API.

Practice this question →

114

MCQmedium

An admin runs 'kubectl auth reconcile -f rbac.yaml' and gets an error that the user does not have permission to create ClusterRoleBindings. What is the most likely cause?

A.The ClusterRoleBinding already exists.

B.The YAML file has a syntax error.

C.The Kubernetes API server is not reachable.

D.The user's kubeconfig context does not have RBAC permissions to create ClusterRoleBindings.

AnswerD

The error indicates insufficient permissions; the user needs a ClusterRoleBinding that grants the necessary permissions.

Why this answer

The error indicates that the user's current kubeconfig context lacks RBAC permissions to create ClusterRoleBindings. The `kubectl auth reconcile` command attempts to apply the RBAC resources defined in the YAML file, and if the user's credentials (typically from a certificate or token) do not include the `create` verb on `clusterrolebindings` in the RBAC authorization layer, the API server will reject the request with a 403 Forbidden error. This is a direct permission issue, not a connectivity or syntax problem.

Exam trap

The trap here is that candidates may confuse a permission error with a resource conflict (Option A) or a connectivity issue (Option C), but the specific error message 'does not have permission to create ClusterRoleBindings' directly points to insufficient RBAC privileges in the current kubeconfig context.

How to eliminate wrong answers

Option A is wrong because if the ClusterRoleBinding already exists, `kubectl auth reconcile` would attempt to update it (which requires `update` permission), but the error specifically mentions lack of permission to `create`, not a conflict error like 'AlreadyExists'. Option B is wrong because a syntax error in the YAML file would produce a parsing error from kubectl (e.g., 'error converting YAML to JSON'), not an RBAC permission error. Option C is wrong because if the API server were unreachable, the error would be a connection timeout or 'Unable to connect to the server', not a permission-denied message.

Practice this question →

115

Multi-Selectmedium

Which TWO actions should be taken to secure etcd in a Kubernetes cluster?

Select 2 answers

A.Enable TLS authentication for etcd peer and client communication

B.Run etcd as a DaemonSet to ensure high availability

C.Disable client certificate authentication for etcd

D.Enable the NodeRestriction admission plugin on etcd

E.Restrict access to etcd using network policies or firewall rules

AnswersA, E

TLS ensures encrypted and authenticated communication.

Why this answer

Enabling TLS authentication for etcd peer and client communication ensures that all data in transit between etcd members and between etcd and the Kubernetes API server is encrypted and mutually authenticated. This prevents man-in-the-middle attacks and unauthorized access to the cluster's state store, which is a critical requirement for securing etcd as per the CIS Kubernetes Benchmark.

Exam trap

CNCF often tests the misconception that admission plugins like NodeRestriction apply to etcd, when in fact they are exclusively API server components and have no role in securing the etcd datastore itself.

Practice this question →

116

MCQmedium

You are tasked with enabling audit logging for the Kubernetes API server. Which API server flag must be used to specify the audit log file path?

A.--audit-log-path

B.--audit-log-dir

C.--audit-policy-file

D.--audit-log-file

AnswerA

This flag sets the path for the audit log file.

Why this answer

The `--audit-log-path` flag is the correct API server flag to specify the file path where audit logs are written. This flag defines the absolute or relative path to the audit log file, and the kube-apiserver will create or append to that file. Without this flag, no audit log file is generated, even if an audit policy is configured.

Exam trap

CNCF often tests the exact flag name `--audit-log-path` versus the plausible but incorrect `--audit-log-file`, exploiting the common assumption that the flag would be named after the file rather than the path.

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 the directory is `--audit-log-path`, which can include a directory path as part of the filename. Option C is wrong because `--audit-policy-file` specifies the path to the audit policy YAML file that defines which events to log, not the log file path itself. Option D is wrong because `--audit-log-file` is not a valid flag; the correct flag name is `--audit-log-path`.

Practice this question →

117

MCQeasy

What is the default authorization mode for a new Kubernetes cluster?

A.ABAC

B.Node

C.AlwaysDeny

D.RBAC

AnswerD

RBAC is the default in most modern distributions.

Why this answer

Option D is correct because RBAC (Role-Based Access Control) is the default authorization mode for new Kubernetes clusters since version 1.8. When you initialize a cluster with kubeadm, the API server is automatically configured with the `--authorization-mode=RBAC` flag, enabling fine-grained access control based on roles and bindings.

Exam trap

CNCF often tests the misconception that ABAC is the default because it was the original authorization mode in early Kubernetes versions, but RBAC has been the default since v1.8 and is the recommended standard for security.

How to eliminate wrong answers

Option A is wrong because ABAC (Attribute-Based Access Control) is not the default; it requires manual configuration with `--authorization-mode=ABAC` and a policy file, and it is less secure and harder to manage than RBAC. Option B is wrong because Node authorization is a special-purpose mode used to authorize kubelet API requests, not the default for the entire cluster; it is typically combined with other modes like RBAC. Option C is wrong because AlwaysDeny is a legacy mode that denies all requests and is not used in production; it was removed in Kubernetes 1.10 and is never the default.

Practice this question →

118

MCQmedium

After a security incident, you need to restrict which pods can communicate with each other in the 'finance' namespace. You want to allow only pods with label 'app: api' to connect to pods with label 'app: db' on TCP port 5432, and deny all other traffic. Which NetworkPolicy should you create?

A.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db namespace: finance spec: podSelector: matchLabels: app: api ingress: - from: - podSelector: matchLabels: app: db ports: - port: 5432

B.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db namespace: finance spec: podSelector: matchLabels: app: api egress: - to: - podSelector: matchLabels: app: db ports: - port: 5432

C.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db namespace: finance spec: podSelector: matchLabels: app: db ingress: - from: - podSelector: matchLabels: app: api

D.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db namespace: finance spec: podSelector: matchLabels: app: db ingress: - from: - podSelector: matchLabels: app: api ports: - port: 5432

AnswerD

Correctly targets db pods, allows ingress from api pods on port 5432, and implicitly denies all other ingress.

Why this answer

Option D is correct because it defines a NetworkPolicy that selects pods with label 'app: db' as the target and allows ingress traffic only from pods with label 'app: api' on TCP port 5432. By default, if no NetworkPolicy exists, all traffic is allowed; once a NetworkPolicy selects a pod, all traffic not explicitly allowed is denied. This policy therefore restricts communication to only the intended api-to-db flow on the specified port.

Exam trap

CNCF often tests the direction of traffic flow: candidates mistakenly apply the policy to the source pod (app: api) with an ingress rule, which would control traffic coming into the api pod rather than traffic going to the db pod, or they forget to specify the port, allowing all ports from the allowed source.

How to eliminate wrong answers

Option A is wrong because it selects pods with label 'app: api' and defines an ingress rule from pods with label 'app: db', which would allow db pods to connect to api pods, the reverse of the required direction. Option B is wrong because it defines an egress rule from api pods to db pods, but the question requires restricting which pods can communicate with each other, and egress policies control outbound traffic from the selected pods, not inbound traffic to the db pods; additionally, it does not deny all other traffic because it only affects egress from api pods, leaving ingress to db pods unrestricted. Option C is wrong because it selects db pods and allows ingress from api pods but does not specify the port (5432), thus allowing all ports from api pods, which is too permissive and does not meet the requirement to restrict to TCP port 5432.

Practice this question →

119

MCQeasy

Which admission plugin is recommended by the CIS Kubernetes Benchmark to restrict the kubelet's ability to modify nodes?

A.NodeRestriction

B.PodNodeSelector

C.SecurityContextDeny

D.AlwaysPullImages

AnswerA

NodeRestriction ensures kubelets can only modify their own node objects.

Why this answer

The NodeRestriction admission plugin is recommended by the CIS Kubernetes Benchmark to restrict the kubelet's ability to modify nodes. It limits the kubelet's permissions to only modify its own node and its own pods, preventing it from altering other nodes or performing unauthorized operations. This plugin enforces a security boundary by rejecting requests that attempt to modify node labels, taints, or status outside the kubelet's assigned scope.

Exam trap

The trap here is that candidates often confuse admission plugins that control pod security (like SecurityContextDeny or PodNodeSelector) with the specific plugin that restricts kubelet node modification, leading them to pick a security-focused option that does not address the kubelet's API access.

How to eliminate wrong answers

Option B (PodNodeSelector) is wrong because it enforces namespace-level pod node selector constraints, not kubelet node modification restrictions. Option C (SecurityContextDeny) is wrong because it rejects pods with certain security context settings, such as privileged containers, but does not limit kubelet actions on nodes. Option D (AlwaysPullImages) is wrong because it forces image pull policy to Always for every pod, addressing image freshness and security, not kubelet node modification control.

Practice this question →

120

MCQhard

A cluster uses Kubernetes v1.24 with Pod Security Admission enabled. The cluster administrator wants to enforce that all pods in the 'production' namespace run with the 'restricted' policy level, but some existing deployments use privileged containers. Which approach ensures that only new pods violating the policy are rejected, while existing pods continue to run?

A.Patch existing deployments to remove privileged containers, then add the label 'pod-security.kubernetes.io/enforce=restricted' to the namespace.

B.Add the namespace label 'pod-security.kubernetes.io/enforce=restricted' and leave existing pods unchanged; new pods violating the policy will be rejected.

C.Create a PodSecurityPolicy that restricts privileged containers and bind it to all service accounts in the namespace.

D.Set the namespace label 'pod-security.kubernetes.io/enforce=restricted' and use the 'inform' mode to allow existing pods.

AnswerB

Correctly enforces the policy on new pods without affecting existing ones.

Why this answer

Option B is correct because Pod Security Admission (PSA) in Kubernetes v1.24 enforces policies via namespace labels. Setting `pod-security.kubernetes.io/enforce=restricted` on the 'production' namespace will reject any new pod that violates the restricted policy, but existing pods are not re-evaluated and continue running. This behavior is by design: PSA evaluates pods at creation or update time, not retroactively, so existing workloads are unaffected.

Exam trap

The trap here is that candidates confuse Pod Security Admission with the deprecated PodSecurityPolicy, or assume that setting an enforce label will retroactively terminate existing pods, when in fact PSA only applies to new or updated pods.

How to eliminate wrong answers

Option A is wrong because patching existing deployments to remove privileged containers is unnecessary and contradicts the requirement to let existing pods continue running; PSA does not require modifying existing workloads. Option C is wrong because PodSecurityPolicy (PSP) was deprecated in Kubernetes v1.21 and removed in v1.25, and the question specifies v1.24 with Pod Security Admission enabled, making PSP irrelevant and non-functional. Option D is wrong because setting the label to 'enforce=restricted' already enforces the policy; 'inform' mode would only log violations without rejecting pods, which does not meet the requirement to reject new violating pods.

Practice this question →

121

MCQmedium

An administrator runs kube-bench and receives a failing result for CIS control 1.1.1. What does this control typically check?

A.That the API server pod specification file permissions are set to 644 or more restrictive

B.That etcd is using TLS

C.That the API server audit log path is configured

D.That anonymous authentication is disabled on the API server

AnswerA

This is the check for control 1.1.1.

Why this answer

CIS control 1.1.1 specifically checks that the API server pod specification file (typically /etc/kubernetes/manifests/kube-apiserver.yaml) has permissions set to 644 or more restrictive (e.g., 600 or 640). This ensures that only authorized users (root or the kube-apiserver process) can read or modify the file, preventing unauthorized changes to critical API server configuration.

Exam trap

CNCF often tests candidates' ability to map CIS control numbers to their exact checks, so the trap here is that candidates confuse control 1.1.1 (file permissions) with other common API server hardening controls like TLS, audit logging, or authentication settings.

How to eliminate wrong answers

Option B is wrong because etcd TLS configuration is covered under a different CIS control (e.g., 2.1 or 2.2), not 1.1.1. Option C is wrong because API server audit log path configuration is checked under CIS control 1.2.1 or similar audit-related controls, not 1.1.1. Option D is wrong because disabling anonymous authentication on the API server is a separate control (e.g., 1.2.3 or 1.2.4), not part of control 1.1.1 which focuses on file permissions.

Practice this question →

122

Multi-Selecteasy

Which TWO of the following are recommended practices for securing the Kubernetes API server? (Select TWO)

Select 2 answers

A.Set --cors-allowed-origins=* for easy access.

B.Disable TLS to improve performance.

C.Enable audit logging.

D.Set --insecure-port=8080 to allow non-TLS access.

E.Set --anonymous-auth=false.

AnswersC, E

Audit logs help detect and investigate suspicious activities.

Why this answer

Option C is correct because enabling audit logging on the API server records all requests to the cluster, providing an immutable record for security monitoring, incident response, and compliance. Audit logs are essential for detecting unauthorized access attempts, misconfigurations, and policy violations, and are a core requirement for Kubernetes security hardening.

Exam trap

CNCF often tests the misconception that disabling security features (like TLS or authentication) improves performance or simplifies access, when in fact these actions directly violate the principle of defense in depth and are explicitly discouraged in Kubernetes security best practices.

Practice this question →

123

MCQmedium

An administrator wants to ensure that a service account used by a deployment cannot automatically mount its token. Which field should be set to `false` in the Pod spec?

A.mountServiceAccountToken

B.disableTokenMount

C.automountServiceAccountToken

D.automountToken

AnswerC

This field controls whether the service account token is automatically mounted.

Why this answer

Option C is correct because the `automountServiceAccountToken` field in the Pod spec controls whether the service account token is automatically mounted into the container. Setting this field to `false` prevents the automatic mounting of the token, which is a security best practice to reduce the attack surface for compromised pods. This field can be set at the Pod level or overridden at the ServiceAccount level.

Exam trap

The trap here is that candidates often confuse the field name with similar-sounding but incorrect options like `automountToken` or `disableTokenMount`, or they mistakenly think `mountServiceAccountToken` is the correct field, when the exact API field is `automountServiceAccountToken`.

How to eliminate wrong answers

Option A is wrong because `mountServiceAccountToken` is not a valid field in the Pod spec; the correct field name is `automountServiceAccountToken`. Option B is wrong because `disableTokenMount` is not a recognized Kubernetes field; no such field exists in the Pod or ServiceAccount API. Option D is wrong because `automountToken` is an incorrect abbreviation; the actual field name is `automountServiceAccountToken`, which must be spelled out exactly as defined in the Kubernetes API.

Practice this question →

124

MCQmedium

Which flag must be set on the API server to enable audit logging?

A.--audit-log-maxage=30

B.--audit-log-format=json

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

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

AnswerC

This flag enables audit logging by specifying the log file path.

Why this answer

Option C is correct because the `--audit-log-path` flag is the mandatory parameter that enables audit logging in the kube-apiserver. Without specifying a file path for the audit log, the API server will not write any audit events, even if other audit-related flags are set. This flag tells the API server where to persist the audit log entries, effectively activating the audit logging feature.

Exam trap

The trap here is that candidates often assume setting the audit policy file (`--audit-policy-file`) alone enables auditing, but without `--audit-log-path` the API server does not write any audit logs, making the policy effectively useless.

How to eliminate wrong answers

Option A is wrong because `--audit-log-maxage=30` only controls the maximum number of days to retain old audit log files; it does not enable audit logging itself. Option B is wrong because `--audit-log-format=json` specifies the output format of the audit log (e.g., JSON or legacy format) but does not turn on audit logging. Option D is wrong because `--audit-policy-file` defines the rules for which events to audit, but without `--audit-log-path` the API server will not write any audit log output, making the policy file ineffective.

Practice this question →

125

MCQmedium

An administrator runs 'kubectl auth can-i --list --as=system:serviceaccount:ns1:my-sa' and sees that the service account has 'create pods' permission via a RoleBinding. Which command can be used to delete that RoleBinding?

A.kubectl delete serviceaccount my-sa -n ns1

B.kubectl delete role <role-name> -n ns1

C.kubectl delete rolebinding <binding-name> -n ns1

D.kubectl delete clusterrolebinding <binding-name>

AnswerC

This deletes the RoleBinding in the specified namespace.

Why this answer

The `kubectl auth can-i --list` output shows that the service account `my-sa` has `create pods` permission via a RoleBinding. To remove that permission, you must delete the RoleBinding object itself, not the service account or the role (unless the role is exclusively used by this binding). Option C correctly uses `kubectl delete rolebinding` with the specific binding name and namespace to revoke the RBAC grant.

Exam trap

CNCF often tests the misconception that deleting the role or the service account is equivalent to removing the permission, but the correct action is to delete the RoleBinding that grants the permission.

How to eliminate wrong answers

Option A is wrong because deleting the service account removes the identity but does not directly delete the RoleBinding; the binding would become orphaned, and the permission would still exist in the cluster (though unusable). Option B is wrong because deleting the role removes the permission definition, but the RoleBinding would still reference a non-existent role, potentially causing errors or leaving the binding in an invalid state; the correct approach is to delete the binding itself. Option D is wrong because the permission was granted via a RoleBinding (namespaced), not a ClusterRoleBinding; deleting a ClusterRoleBinding would not affect a namespaced RoleBinding.

Practice this question →

126

MCQeasy

Which admission plugin should be enabled on the API server to enforce that kubelet cannot modify nodes other than its own?

A.NodeSelector

B.PodSecurity

C.NodeRestriction

D.AlwaysPullImages

AnswerC

Correct. NodeRestriction ensures kubelet can only modify its own node.

Why this answer

The NodeRestriction admission plugin ensures that a kubelet can only modify its own Node object and Pods bound to it. This prevents a compromised or misconfigured kubelet from tampering with other nodes, enforcing the principle of least privilege. Without this plugin, a kubelet could potentially update labels, taints, or status on any node, leading to cluster instability or privilege escalation.

Exam trap

CNCF often tests the distinction between admission plugins that control Pod behavior (like PodSecurity or AlwaysPullImages) versus those that control kubelet authorization (NodeRestriction), leading candidates to confuse Pod-level security with node-level access control.

How to eliminate wrong answers

Option A is wrong because NodeSelector is not an admission plugin; it is a field in Pod specs used to constrain which nodes a Pod can be scheduled on, not a kubelet authorization control. Option B is wrong because PodSecurity is an admission plugin that enforces Pod Security Standards (e.g., privileged, baseline, restricted) on Pods, but it does not restrict kubelet actions on node objects. Option D is wrong because AlwaysPullImages is an admission plugin that forces image pull policy to Always, ensuring images are always pulled from the registry, but it has no effect on kubelet node modification permissions.

Practice this question →

127

Multi-Selectmedium

Which two of the following are correct ways to enforce least privilege for service accounts? (Choose two.)

Select 2 answers

A.Set automountServiceAccountToken: false in Pod spec for pods that do not need API access

B.Add multiple ClusterRoleBindings to a single service account to ensure it has access to all resources

C.Use the default service account for all workloads

D.Create a dedicated service account with only the required RBAC permissions

E.Grant cluster-admin ClusterRole to the service account for simplicity

AnswersA, D

This prevents unnecessary token mounting.

Why this answer

Setting `automountServiceAccountToken: false` in the Pod spec prevents the automatic mounting of the service account token into the container. This enforces least privilege by ensuring that pods which do not require API access cannot inadvertently use the token to authenticate to the Kubernetes API server, reducing the attack surface.

Exam trap

CNCF often tests the misconception that the default service account is safe to use for all workloads, when in fact it should be replaced with dedicated service accounts that have minimal, scoped RBAC permissions.

Practice this question →

128

Multi-Selectmedium

Which TWO of the following are recommended practices for securing the Kubernetes dashboard?

Select 2 answers

A.Avoid exposing the dashboard to the public internet

B.Expose the dashboard via a NodePort service for easy access

C.Enable anonymous access to the dashboard

D.Use RBAC to restrict dashboard permissions

E.Run the dashboard as a DaemonSet

AnswersA, D

Public exposure increases attack surface.

Why this answer

Option A is correct because exposing the Kubernetes dashboard to the public internet significantly increases the attack surface, making it a prime target for credential theft, API abuse, and cluster compromise. The dashboard should only be accessible via internal networks, VPNs, or using kubectl proxy with authentication, never directly over the internet.

Exam trap

CNCF often tests the misconception that NodePort or anonymous access are acceptable for convenience in a lab environment, but the CKS exam strictly requires production-hardened configurations where any public exposure or unauthenticated access is automatically incorrect.

Practice this question →

129

MCQmedium

A security audit reveals that a ServiceAccount named 'monitor' has a ClusterRoleBinding to the cluster-admin role. What is the best remediation?

A.Set automountServiceAccountToken to false on the pods

B.Add a second ClusterRoleBinding to a more restrictive role

C.Delete the ServiceAccount

D.Create a new ClusterRoleBinding with a limited role

AnswerD

This reduces privileges while maintaining functionality.

Why this answer

Option D is correct because the best practice is to replace an overly permissive ClusterRoleBinding (like cluster-admin) with a new binding that grants only the specific permissions the 'monitor' ServiceAccount needs, following the principle of least privilege. Deleting the ServiceAccount (C) might break dependent workloads, while merely adding a second binding (B) doesn't remove the dangerous cluster-admin binding. Setting automountServiceAccountToken to false (A) prevents token mounting but doesn't revoke the existing RBAC permissions, leaving the account still capable of escalating privileges if the token is obtained elsewhere.

Exam trap

CNCF often tests the misconception that simply adding a restrictive binding or disabling token mounting is sufficient to limit permissions, when in reality RBAC permissions are cumulative and the original dangerous binding must be explicitly removed.

How to eliminate wrong answers

Option A is wrong because setting automountServiceAccountToken to false only prevents automatic mounting of the service account token into pods; it does not revoke the existing ClusterRoleBinding, so the 'monitor' ServiceAccount still has cluster-admin privileges if the token is accessed via other means (e.g., manually mounted or leaked). Option B is wrong because adding a second ClusterRoleBinding to a more restrictive role does not remove the existing cluster-admin binding; the user or service account will still have the union of all permissions, including the overly permissive cluster-admin role. Option C is wrong because deleting the ServiceAccount may break applications or controllers that depend on it, and it does not address the underlying misconfiguration of the ClusterRoleBinding; a better approach is to replace the binding with a least-privilege role.

Practice this question →

130

MCQmedium

You need to encrypt etcd data at rest using AES-CBC. Which encryption provider should you specify in the EncryptionConfiguration?

A.aesgcm

B.aescbc

C.aes-256-cbc

D.secretbox

AnswerB

aescbc is the supported provider for AES-CBC encryption at rest.

Why this answer

Option B (aescbc) is correct because Kubernetes supports AES-CBC encryption via the 'aescbc' provider in the EncryptionConfiguration. This provider uses AES in Cipher Block Chaining mode with a 32-byte key for encryption at rest, as specified in the Kubernetes documentation for encrypting etcd data.

Exam trap

The trap here is that candidates confuse the Kubernetes provider name 'aescbc' with the generic algorithm name 'aes-256-cbc' or other encryption modes like 'aesgcm', but the exam expects exact knowledge of the Kubernetes-specific provider identifiers as defined in the official documentation.

How to eliminate wrong answers

Option A (aesgcm) is wrong because AES-GCM is an authenticated encryption mode that requires a unique nonce per key and is not recommended for encrypting etcd data at rest due to nonce reuse risks and lack of support as a standalone provider in Kubernetes EncryptionConfiguration. Option C (aes-256-cbc) is wrong because Kubernetes does not recognize 'aes-256-cbc' as a valid provider name; the correct identifier is 'aescbc', and the key length is determined by the key file, not the provider string. Option D (secretbox) is wrong because Secretbox is a NaCl-based encryption scheme using XSalsa20-Poly1305, which is not a built-in provider in Kubernetes; it would require a custom implementation or is used in other contexts like libsodium.

Practice this question →

131

Multi-Selecthard

Which THREE of the following are recommended practices for securing Kubernetes Dashboard?

Select 3 answers

A.Disable anonymous access to Dashboard

B.Expose Dashboard via NodePort service on all nodes

C.Use RBAC to grant Dashboard service account only necessary permissions

D.Avoid exposing Dashboard over the public internet

E.Create a ClusterRole with full cluster admin access for Dashboard

AnswersA, C, D

Correct. Anonymous access should be disabled.

Why this answer

Option A is correct because the Kubernetes Dashboard, by default, may allow unauthenticated access if not explicitly configured. Disabling anonymous access ensures that all requests to the Dashboard are authenticated, preventing unauthorized users from viewing or manipulating cluster resources. This is typically done by setting the `--enable-skip-login` flag to false or configuring the Dashboard deployment to require authentication tokens.

Exam trap

CNCF often tests the principle of least privilege by presenting options that seem convenient (like full admin access or NodePort exposure) but violate security best practices, and the trap here is that candidates may think exposing the Dashboard via NodePort is acceptable for internal access, ignoring that it bypasses authentication layers and network segmentation.

Practice this question →

132

Multi-Selectmedium

Which TWO of the following are best practices for hardening Kubernetes Dashboard?

Select 2 answers

A.Grant minimal RBAC permissions to Dashboard service account

B.Do not expose Dashboard via a public LoadBalancer Service

C.Use HTTP to avoid certificate management

D.Use the default service account with cluster-admin binding

E.Enable anonymous access for simplicity

AnswersA, B

Follow least privilege principle.

Why this answer

Option A is correct because the Kubernetes Dashboard should run with the least privilege necessary. Granting minimal RBAC permissions to the Dashboard's service account follows the principle of least privilege, reducing the attack surface if the Dashboard is compromised. The default installation often creates a service account with excessive permissions, which should be scoped down to only what the Dashboard needs to function.

Exam trap

CNCF often tests the misconception that 'more permissions make the Dashboard work better' or that 'HTTP is simpler and acceptable for internal use,' but the correct approach is to always enforce TLS and minimal RBAC, as the exam expects you to prioritize security over convenience.

Practice this question →

133

MCQmedium

To protect kernel defaults on a node, which flag should be set on the kubelet?

A.--hardening=true

B.--protect-kernel-defaults=true

C.--protect-kernel-parameters=true

D.--kernel-security=true

AnswerB

This flag prevents the kubelet from modifying kernel parameters that could affect security.

Why this answer

The `--protect-kernel-defaults=true` flag on the kubelet ensures that the kubelet will not start if any kernel tunables (e.g., `vm.overcommit_memory`, `kernel.panic`) differ from their default values. This is a security hardening measure to prevent misconfigured nodes from running with weakened kernel settings, as required by the CIS Kubernetes Benchmark.

Exam trap

The trap here is that candidates confuse the exact flag name with plausible-sounding alternatives like 'protect-kernel-parameters' or 'kernel-security', but the CKS exam expects precise recall of the actual kubelet flag `--protect-kernel-defaults=true` as defined in the CIS Benchmark.

How to eliminate wrong answers

Option A is wrong because `--hardening=true` is not a valid kubelet flag; there is no such flag in the kubelet configuration. Option C is wrong because `--protect-kernel-parameters=true` is not a real kubelet flag; the correct flag uses the term 'defaults' not 'parameters'. Option D is wrong because `--kernel-security=true` is not a valid kubelet flag; kernel security is enforced through other mechanisms like AppArmor or seccomp, not a dedicated kubelet flag.

Practice this question →

134

MCQeasy

An administrator runs 'kubectl get pods' and sees that a pod is in 'Pending' state. What is the most likely reason for this state?

A.The pod has been deleted

B.The container inside the pod is crashing

C.The pod is waiting to be scheduled to a node

D.The pod has completed its execution

AnswerC

Pending indicates the pod has not been scheduled yet.

Why this answer

A pod enters the 'Pending' state when it has been accepted by the API server but is not yet running. The most common reason is that the scheduler has not yet assigned the pod to a node, often due to insufficient resources (CPU/memory), node selector mismatches, taints/tolerations, or a failed scheduler itself. This is the initial phase before the pod transitions to 'Running' or 'ContainerCreating'.

Exam trap

CNCF often tests the distinction between 'Pending' (scheduling issue) and 'ContainerCreating' (image pull or container start delay), so the trap here is confusing a pending scheduling state with a container runtime issue.

How to eliminate wrong answers

Option A is wrong because a deleted pod would not appear in 'kubectl get pods' output at all, or would show as 'Terminating' briefly before removal. Option B is wrong because a crashing container inside the pod would result in a 'CrashLoopBackOff' or 'Error' state, not 'Pending'. Option D is wrong because a pod that has completed its execution (e.g., a Job) would show as 'Completed' or 'Succeeded', not 'Pending'.

Practice this question →

135

MCQhard

You need to create a ClusterRole that allows listing secrets, but only in namespaces that have a specific label 'security-level=high'. Which approach should you use?

A.Create a ClusterRole and bind it with RoleBindings in each labeled namespace

B.Create a Role in each namespace, then aggregate them into a ClusterRole

C.Create a ClusterRole and bind it with a ClusterRoleBinding; add a namespace condition in the role

D.Create a ClusterRole with a namespaceSelector: matchLabels: security-level: high

AnswerA

ClusterRole can be used with RoleBindings to grant permissions only in selected namespaces.

Why this answer

Option A is correct because ClusterRoleBindings grant permissions cluster-wide, but RoleBindings can bind a ClusterRole to subjects within specific namespaces. By creating a ClusterRole with the necessary rules (e.g., 'list secrets') and then creating RoleBindings only in namespaces that have the label 'security-level=high', you effectively restrict the permission to those namespaces. This approach leverages the fact that a ClusterRole can be used with RoleBindings to scope permissions to individual namespaces.

Exam trap

The trap here is that candidates often confuse ClusterRoleBindings with RoleBindings, assuming a ClusterRole must always be bound with a ClusterRoleBinding, or they mistakenly think that a ClusterRole can include a namespace selector to limit its scope, which is not supported in Kubernetes RBAC.

How to eliminate wrong answers

Option B is wrong because aggregating Roles into a ClusterRole does not solve the namespace-scoping requirement; the aggregated ClusterRole would still apply cluster-wide if bound with a ClusterRoleBinding, and if bound with RoleBindings, you would still need to create RoleBindings per namespace, making the aggregation unnecessary. Option C is wrong because a ClusterRoleBinding grants permissions across all namespaces, and Kubernetes RBAC does not support adding a namespace condition inside a ClusterRole; namespace restrictions are enforced only via RoleBindings or by using a Role. Option D is wrong because ClusterRoles do not support a 'namespaceSelector' field; that field is only available in NetworkPolicy and certain admission webhooks, not in RBAC resources.

Practice this question →

136

MCQmedium

An administrator wants to disable anonymous authentication to the Kubernetes API server. Which flag should be added to the kube-apiserver configuration?

A.--disable-anonymous

B.--authorization-mode=RBAC

C.--anonymous-auth=false

D.--enable-admission-plugins=DenyAnonymous

AnswerC

This flag disables anonymous authentication.

Why this answer

Option C is correct because the `--anonymous-auth=false` flag explicitly disables anonymous authentication to the Kubernetes API server. When set to false, requests without valid authentication credentials are rejected with a 401 Unauthorized error, preventing unauthenticated access. This is the standard Kubernetes mechanism to disable anonymous authentication as documented in the kube-apiserver reference.

Exam trap

The trap here is that candidates confuse authentication flags with authorization modes or admission plugins, and may invent non-existent flags like `--disable-anonymous` or assume `DenyAnonymous` is a valid admission plugin name.

How to eliminate wrong answers

Option A is wrong because `--disable-anonymous` is not a valid kube-apiserver flag; Kubernetes uses `--anonymous-auth` (boolean) to control anonymous access. Option B is wrong because `--authorization-mode=RBAC` controls authorization (what authenticated users can do), not authentication (who can access); anonymous users can still be authorized via RBAC if anonymous authentication is enabled. Option D is wrong because `DenyAnonymous` is not a valid admission plugin name; the correct admission plugin for denying anonymous requests is `DenyServiceExternalIPs` or similar, and anonymous authentication is controlled at the authentication layer, not via admission plugins.

Practice this question →

137

MCQmedium

An administrator wants to enable audit logging for the Kubernetes API server. Which of the following is required?

A.Enable the AuditLogging feature gate

B.Set --audit-log-path and --audit-policy-file flags on the kube-apiserver

C.Create a ClusterRoleBinding with audit permissions

D.Set --audit-log-path flag on the kubelet

AnswerB

Enabling audit logging requires specifying the log path via --audit-log-path and a policy file via --audit-policy-file.

Why this answer

Audit logging in Kubernetes is configured directly on the kube-apiserver component. The `--audit-log-path` flag specifies the file path where audit logs are written, and the `--audit-policy-file` flag points to a YAML file that defines which events (e.g., requests, responses, metadata) should be logged and at what level (e.g., Metadata, Request, RequestResponse). These flags are required to enable and control audit logging; no feature gate is needed because audit logging is built-in since Kubernetes 1.8.

Exam trap

The trap here is that candidates may think audit logging requires a feature gate (Option A) or confuse the kube-apiserver's audit flags with kubelet flags (Option D), or mistakenly believe RBAC permissions are needed to enable audit logging (Option C).

How to eliminate wrong answers

Option A is wrong because the AuditLogging feature gate was removed as a beta feature in Kubernetes 1.8 and is now always enabled; no feature gate is required to activate audit logging. Option C is wrong because a ClusterRoleBinding grants RBAC permissions to users or service accounts, but it does not enable or configure audit logging on the API server; audit logging is a server-side configuration, not a permission. Option D is wrong because the kubelet does not serve the Kubernetes API and does not handle audit logging; the `--audit-log-path` flag is only valid for the kube-apiserver, not the kubelet.

Practice this question →

138

MCQmedium

An administrator wants to secure etcd communication. Which of the following is required?

A.Set --etcd-servers to use HTTPS

B.Use SSH tunneling between etcd members

C.Enable TLS with client certificate authentication

D.Enable etcd RBAC

AnswerC

etcd can be configured to require TLS client certificates for all connections.

Why this answer

Option C is correct because etcd, as a distributed key-value store, requires TLS encryption with mutual authentication (client certificates) to secure communication between the API server and etcd, as well as between etcd peers. The `--etcd-servers` flag in kube-apiserver must point to HTTPS endpoints, and `--etcd-certfile` and `--etcd-keyfile` enable client certificate authentication, ensuring that only authenticated clients can access etcd data.

Exam trap

The trap here is that candidates often assume HTTPS alone (Option A) is sufficient for securing etcd, overlooking the requirement for mutual TLS authentication with client certificates to prevent unauthorized clients from connecting to etcd.

How to eliminate wrong answers

Option A is wrong because simply setting `--etcd-servers` to use HTTPS without enabling TLS with client certificate authentication does not secure etcd communication; HTTPS alone only encrypts the channel but does not authenticate the client, leaving etcd vulnerable to unauthorized access. Option B is wrong because SSH tunneling between etcd members is not a standard or recommended practice for securing etcd in Kubernetes; etcd natively supports TLS encryption and mutual authentication, and SSH tunnels add unnecessary complexity and are not part of the Kubernetes security model. Option D is wrong because etcd RBAC controls authorization for etcd operations (e.g., read/write access to keys) but does not encrypt or authenticate the communication channel; TLS with client certificates is required to secure the transport layer.

Practice this question →

139

MCQeasy

Which of the following is the correct flag to enable audit logging on the kube-apiserver?

A.--audit-file

B.--audit-log-path

C.--audit-policy-file

D.--audit-log-file

AnswerB

This flag specifies the path for audit log output.

Why this answer

Option B is correct because `--audit-log-path` is the flag used to specify the file path where the kube-apiserver writes audit log entries. This flag is defined in the Kubernetes API server component and is required to enable audit logging; without it, no audit logs are written.

Exam trap

The trap here is that candidates confuse `--audit-policy-file` (which defines what to log) with the flag that actually enables logging, or misremember the exact flag name as `--audit-log-file` instead of the correct `--audit-log-path`.

How to eliminate wrong answers

Option A is wrong because `--audit-file` is not a valid kube-apiserver flag; the correct flag for specifying the audit log file path is `--audit-log-path`. Option C is wrong because `--audit-policy-file` specifies the path to the audit policy YAML file that defines which events to log, but it does not enable audit logging by itself—it must be used together with `--audit-log-path`. Option D is wrong because `--audit-log-file` is not a recognized flag; the correct flag name uses `--audit-log-path` as per the Kubernetes API server command-line options.

Practice this question →

140

Multi-Selectmedium

Which TWO admission plugins are recommended to be enabled for security hardening?

Select 2 answers

A.AlwaysPullImages

B.NodeRestriction

C.NamespaceLifecycle

D.PodSecurity

E.DefaultStorageClass

AnswersB, D

Limits node modifications.

Why this answer

NodeRestriction is correct because it limits the Node object modifications a kubelet can make, preventing compromised nodes from modifying other nodes or escalating privileges. PodSecurity is correct because it enforces Pod Security Standards (baseline, restricted) via admission, replacing the deprecated PodSecurityPolicy with a built-in, stable mechanism for controlling pod security contexts.

Exam trap

CNCF often tests the distinction between plugins that are 'enabled by default' (like NamespaceLifecycle) versus those that are specifically 'recommended for security hardening' (like NodeRestriction and PodSecurity), causing candidates to pick default plugins that are not security-focused.

Practice this question →

141

MCQhard

An administrator wants to restrict which nodes a pod can be scheduled on using the NodeRestriction admission plugin. Which flag must be set on the kube-apiserver to enable this plugin?

A.--admission-control=NodeRestriction

B.--enable-admission-plugins=PodNodeSelector

C.--authorization-mode=Node

D.--enable-admission-plugins=NodeRestriction

AnswerD

This flag enables the NodeRestriction admission plugin, which enforces node restrictions on pods.

Why this answer

The NodeRestriction admission plugin limits the labels and taints that a kubelet running on a node can modify on its own Node object. To enable it, the `--enable-admission-plugins=NodeRestriction` flag must be set on the kube-apiserver, as admission plugins are enabled via this flag. This plugin works in conjunction with the Node authorizer and the NodeRestriction admission controller to enforce node-level restrictions.

Exam trap

The trap here is that candidates confuse the deprecated `--admission-control` flag with the current `--enable-admission-plugins` flag, or they mix up the NodeRestriction plugin with the Node authorizer or the PodNodeSelector plugin.

How to eliminate wrong answers

Option A is wrong because `--admission-control` is a deprecated flag; the correct flag is `--enable-admission-plugins`. Option B is wrong because `PodNodeSelector` is a different admission plugin that enforces namespace-level node selector constraints, not the NodeRestriction plugin. Option C is wrong because `--authorization-mode=Node` enables the Node authorizer, which authorizes kubelet API requests, but does not enable the NodeRestriction admission plugin.

Practice this question →

142

MCQmedium

A pod runs with a service account that has a ClusterRoleBinding granting cluster-admin. What is the best practice to reduce the risk of privilege escalation?

A.Use a PodSecurityPolicy to restrict the service account

B.Delete the service account and create a new one without any roles

C.Create a more restrictive Role/ClusterRole with only required permissions and bind it to the service account, removing the cluster-admin binding

D.Add a NetworkPolicy to block outbound traffic from the pod

AnswerC

This follows the principle of least privilege.

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. By creating a more restrictive Role/ClusterRole with only required permissions and binding it to the service account, you remove the excessive cluster-admin privileges, directly reducing the risk of privilege escalation. This aligns with Kubernetes RBAC best practices for hardening cluster setup.

Exam trap

CNCF often tests the distinction between RBAC (who can do what) and other security controls like PodSecurityPolicy or NetworkPolicy, expecting candidates to recognize that only RBAC changes can directly reduce service account permissions.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (PSP) is a deprecated admission controller that controls pod security contexts (e.g., privileged containers, host namespaces), not RBAC permissions; it cannot restrict what a service account can do via ClusterRoleBindings. Option B is wrong because deleting the service account and creating a new one without any roles would break the pod's functionality entirely, as it would have no permissions to perform any API operations, which is not a practical security fix. Option D is wrong because NetworkPolicy controls network traffic at the pod level (e.g., ingress/egress rules), not RBAC permissions; it cannot prevent a service account from abusing its cluster-admin privileges to escalate privileges via the Kubernetes API.

Practice this question →

143

MCQmedium

You run 'kubectl auth can-i --list --as=admin' and see that the admin user has full cluster-admin access. Which command would create a ClusterRoleBinding for a user named 'viewer' with read-only access to all resources?

A.kubectl create rolebinding viewer-binding --clusterrole=view --user=viewer

B.kubectl create clusterrole viewer --verb=get,list,watch --resource=*

C.kubectl create clusterrolebinding viewer-binding --role=view --user=viewer

D.kubectl create clusterrolebinding viewer-binding --clusterrole=view --user=viewer

AnswerD

This binds the 'view' ClusterRole to user 'viewer'.

Why this answer

Option D is correct because it uses `kubectl create clusterrolebinding` to bind the built-in `view` ClusterRole (which grants read-only access: get, list, watch) to the user `viewer` at the cluster scope. A ClusterRoleBinding is required to grant permissions across all namespaces, and the `--clusterrole` flag correctly references the ClusterRole, not a Role.

Exam trap

The trap here is that candidates confuse `rolebinding` with `clusterrolebinding` and `--role` with `--clusterrole`, leading them to pick options that either limit permissions to a single namespace or use incorrect syntax for binding a ClusterRole.

How to eliminate wrong answers

Option A is wrong because `kubectl create rolebinding` creates a namespaced RoleBinding, which only grants permissions within a specific namespace (default if not specified), not across all resources cluster-wide. Option B is wrong because it creates a new ClusterRole with `*` as the resource, which is invalid syntax (resources must be specific, e.g., `'*'` is not a valid resource name) and it does not bind the role to the user. Option C is wrong because it uses `--role=view` instead of `--clusterrole=view`; `--role` expects a namespaced Role, not a ClusterRole, and a ClusterRoleBinding cannot reference a namespaced Role.

Practice this question →

144

MCQeasy

Which flag on the kubelet disables anonymous access?

A.--anonymous-auth=false

B.--disable-anonymous

C.--no-anonymous

D.--enable-anonymous-auth=false

AnswerA

This is the correct flag on kubelet.

Why this answer

The `--anonymous-auth` flag on the kubelet controls whether anonymous requests are allowed. Setting `--anonymous-auth=false` explicitly disables anonymous access, requiring all requests to present valid authentication credentials. This is a critical hardening measure to prevent unauthenticated users from interacting with the kubelet API.

Exam trap

CNCF often tests the exact flag name and syntax, so candidates may confuse `--anonymous-auth` with `--enable-anonymous-auth` or invent non-existent flags like `--disable-anonymous` or `--no-anonymous`.

How to eliminate wrong answers

Option B is wrong because `--disable-anonymous` is not a valid kubelet flag; the kubelet uses `--anonymous-auth` to control anonymous access. Option C is wrong because `--no-anonymous` is not a recognized flag; the kubelet does not support a `--no-` prefix for this setting. Option D is wrong because `--enable-anonymous-auth=false` is not a valid flag; the correct flag is `--anonymous-auth`, and setting it to `false` disables anonymous access, not `--enable-anonymous-auth`.

Practice this question →

145

MCQmedium

An administrator wants to restrict a service account to only be able to create pods in the 'development' namespace. Which RBAC configuration should be used?

A.Create a Role in the default namespace and a RoleBinding that binds the service account to that Role.

B.Create a Role in the 'development' namespace and a RoleBinding that binds the service account to that Role.

C.Create a ClusterRole and a ClusterRoleBinding that binds the service account to that ClusterRole.

D.Create a ClusterRole and a RoleBinding in the 'development' namespace.

AnswerB

Role and RoleBinding are namespaced and provide the correct scoping.

Why this answer

Option B is correct because a Role is namespace-scoped and can only grant permissions within the namespace where it is created. By creating a Role in the 'development' namespace and binding the service account to it via a RoleBinding, the service account is restricted to creating pods only in that namespace, as required.

Exam trap

CNCF often tests the distinction between Role and ClusterRole scoping, and the trap here is that candidates may incorrectly choose a ClusterRole with a RoleBinding (Option D) thinking it restricts to a namespace, but the ClusterRole itself may grant broader permissions or include cluster-scoped resources, violating the principle of least privilege.

How to eliminate wrong answers

Option A is wrong because creating a Role in the default namespace and binding it to the service account would grant permissions only in the default namespace, not in the 'development' namespace. Option C is wrong because a ClusterRole combined with a ClusterRoleBinding grants permissions cluster-wide, across all namespaces, which is too permissive and does not restrict the service account to the 'development' namespace. Option D is wrong because while a RoleBinding in the 'development' namespace scopes the binding to that namespace, a ClusterRole is not namespace-scoped; using a ClusterRole in a RoleBinding still grants permissions defined in the ClusterRole, which could include cluster-scoped resources or be overly broad, and the question specifically requires restricting to pod creation only, which a Role can handle more precisely.

Practice this question →

146

MCQmedium

A developer created a ClusterRoleBinding that grants cluster-admin to a service account. What is the security concern?

A.Service accounts must use RoleBindings only

B.ClusterRoleBindings are deprecated

C.Service accounts cannot use ClusterRoleBindings

D.It gives the service account full cluster-wide permissions, which is excessive

AnswerD

Cluster-admin grants unrestricted access to all resources.

Why this answer

Option D is correct because granting a service account cluster-admin via a ClusterRoleBinding provides unrestricted, cluster-wide permissions, violating the principle of least privilege. This is a significant security risk as it allows the service account to perform any action on any resource in any namespace, including modifying RBAC rules, secrets, or node configurations. In Kubernetes, service accounts should be bound only to the minimal roles required for their function, typically using RoleBindings scoped to a specific namespace.

Exam trap

CNCF often tests the misconception that service accounts are restricted to namespace-scoped bindings, leading candidates to incorrectly choose Option A or C, when in fact Kubernetes allows any subject to be bound to any ClusterRole.

How to eliminate wrong answers

Option A is wrong because service accounts can use both RoleBindings (namespace-scoped) and ClusterRoleBindings (cluster-scoped) depending on the required scope; there is no Kubernetes restriction limiting them to RoleBindings only. Option B is wrong because ClusterRoleBindings are not deprecated; they remain a core, actively supported RBAC resource for granting cluster-wide permissions. Option C is wrong because service accounts can absolutely use ClusterRoleBindings; the Kubernetes API allows binding any subject (user, group, or service account) to a ClusterRole via a ClusterRoleBinding.

Practice this question →

147

MCQmedium

A cluster administrator wants to ensure that pods cannot modify node objects. Which admission plugin should be enabled?

A.PodSecurityPolicy

B.NodeAffinity

C.PodNodeSelector

D.NodeRestriction

AnswerD

This plugin restricts node modifications.

Why this answer

The NodeRestriction admission plugin limits the kubelet's ability to modify node and pod objects to only those nodes it is authorized to manage. This prevents a compromised or misconfigured kubelet from modifying arbitrary node objects, enforcing the principle of least privilege. Option D is correct because it directly addresses the requirement to restrict node object modifications.

Exam trap

The trap here is that candidates often confuse admission plugins that affect pod scheduling (like NodeAffinity or PodNodeSelector) with those that enforce node-level security restrictions, leading them to overlook NodeRestriction as the correct answer.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) controls security-sensitive aspects of pod specs (e.g., privileged containers, host namespaces) but does not restrict modifications to node objects. Option B is wrong because NodeAffinity is a scheduling constraint that influences pod placement based on node labels, not an admission plugin that enforces node object modification restrictions. Option C is wrong because PodNodeSelector is an admission plugin that enforces namespace-level node selector constraints on pods, but it does not prevent pods or kubelets from modifying node objects.

Practice this question →

148

MCQeasy

A security engineer needs to ensure that all communication between nodes and the control plane is encrypted. Which component must be configured with a TLS certificate to achieve this?

A.kube-proxy

B.etcd

C.kube-scheduler

D.kube-apiserver

AnswerD

The API server serves HTTPS; configuring its TLS certificate encrypts all communication to/from it.

Why this answer

The kube-apiserver is the central gateway for all cluster operations, and it must be configured with a TLS certificate to encrypt communication between nodes (kubelets) and the control plane. The kube-apiserver presents this certificate to authenticate itself and establish encrypted HTTPS connections, ensuring that all traffic from node components (e.g., kubelets, kube-proxy) and other control plane components is secured in transit.

Exam trap

CNCF often tests the misconception that etcd is the primary component for encryption because it stores sensitive data, but the question specifically asks about encrypting communication between nodes and the control plane, which is handled by the kube-apiserver's TLS certificate, not etcd's internal encryption.

How to eliminate wrong answers

Option A is wrong because kube-proxy is a network proxy that runs on each node and handles service routing, but it does not terminate TLS for node-to-control-plane communication; it relies on the kube-apiserver's TLS for secure connections. Option B is wrong because etcd stores cluster data and can be configured with its own TLS certificates for peer and client communication, but it is not the component that encrypts node-to-control-plane traffic; it is a data store accessed by the kube-apiserver. Option C is wrong because kube-scheduler is a control plane component that assigns pods to nodes, but it communicates with the kube-apiserver via TLS (using the apiserver's certificate) and does not itself present a certificate for node-to-control-plane encryption.

Practice this question →

149

MCQhard

A security scan reports that the etcd data directory is not encrypted at rest. The cluster uses etcd v3.5. Which steps are required to enable encryption?

A.Use etcdctl to encrypt the data directory

B.Create an EncryptionConfiguration resource with aescbc, restart API server with --encryption-provider-config

C.Set --encryption-provider=secretbox on etcd

D.Set ETCD_ENABLE_ENCRYPTION=true environment variable

AnswerB

This is the correct procedure for enabling encryption at rest.

Why this answer

Option B is correct because etcd data encryption at rest in Kubernetes is implemented via an EncryptionConfiguration resource that specifies a provider (e.g., aescbc) and a key. The kube-apiserver must be restarted with the --encryption-provider-config flag pointing to that configuration file, which instructs the API server to encrypt resources before writing them to etcd. This is the only supported method for enabling encryption at rest in Kubernetes clusters using etcd v3.5.

Exam trap

The trap here is that candidates often assume encryption at rest is configured directly on etcd (via flags or environment variables), when in fact it is a kube-apiserver-level feature that uses an EncryptionConfiguration resource and the --encryption-provider-config flag.

How to eliminate wrong answers

Option A is wrong because etcdctl does not have a command to encrypt the entire data directory; encryption is handled at the Kubernetes API server level, not by directly manipulating etcd. Option C is wrong because --encryption-provider is not a valid flag for etcd; etcd itself does not natively support encryption at rest via a flag, and the encryption provider configuration is applied to the kube-apiserver, not etcd. Option D is wrong because ETCD_ENABLE_ENCRYPTION is not a recognized environment variable in etcd v3.5; encryption at rest is not enabled by setting an environment variable on etcd.

Practice this question →

150

MCQeasy

Which kubelet flag should be set to ensure the kubelet does not allow anonymous requests?

A.--authentication-token-webhook=true

B.--read-only-port=0

C.--anonymous-auth=false

D.--protect-kernel-defaults=true

AnswerC

Setting this flag to false on the kubelet disables anonymous requests to the kubelet.

Why this answer

Option C is correct because setting `--anonymous-auth=false` explicitly disables anonymous requests to the kubelet. By default, anonymous authentication is enabled, which allows unauthenticated users to access the kubelet API. Disabling this flag ensures that only authenticated requests are processed, aligning with the principle of least privilege and hardening the cluster.

Exam trap

The trap here is that candidates often confuse `--anonymous-auth=false` with `--authentication-token-webhook=true`, thinking token webhook alone blocks anonymous requests, but anonymous auth must be explicitly disabled as a separate step.

How to eliminate wrong answers

Option A is wrong because `--authentication-token-webhook=true` enables webhook-based token authentication (e.g., for service accounts), but it does not affect anonymous requests; anonymous auth is controlled by a separate flag. Option B is wrong because `--read-only-port=0` disables the read-only port (10255), which reduces exposure but does not prevent anonymous requests on the secure port (10250). Option D is wrong because `--protect-kernel-defaults=true` ensures kernel-level security settings (e.g., sysctl parameters) are enforced, but it has no impact on kubelet authentication or anonymous request handling.

Practice this question →