KCSA Kubernetes Cluster Component Security Practice Test 2 — 15 Questions

Question 1

You are auditing the Kubernetes control plane and notice that the API server is configured with an insecure port (--insecure-port=8080). What is the primary security implication of leaving this port enabled?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

It bypasses all authentication and authorization modules, granting full administrative access to anyone who reaches the port.. The --insecure-port flag on the kube-apiserver opens an unauthenticated, unencrypted HTTP endpoint that completely bypasses the normal authentication (x509 client certs, bearer tokens, OIDC) and authorization (RBAC, ABAC, Node authorizer) chain. Any client that can reach that port — including a compromised pod on the host network or a misconfigured firewall — is treated as an anonymous, fully privileged user and can perform any API action, including creating cluster-admin bindings. This is why the flag was deprecated in Kubernetes 1.20 and removed in 1.24.

Answer

It prevents the kubelet from communicating with the control plane nodes.

Answer

It restricts API access exclusively to read-only operations.

Answer

It forces all clients to downgrade their TLS encryption cipher suites to plaintext.

Question 2

A security auditor discovers that anonymous authentication is accidentally enabled on the Kubernetes API server, allowing unauthenticated read access to cluster health endpoints. Which API server flag must be modified to disable anonymous requests?

Accepted Answer

--anonymous-auth=false. The --anonymous-auth flag on kube-apiserver controls whether unauthenticated requests are treated as anonymous users (system:anonymous). Setting --anonymous-auth=false rejects requests without valid credentials with a 401 Unauthorized response, closing the exposure of health/version endpoints to unauthenticated clients. This is the documented, supported way to disable anonymous access and is enforced by CIS Kubernetes Benchmark control 1.2.1.

Answer

--secure-port=0

Answer

--authorization-mode=AlwaysAllow

Answer

--disable-anonymous=true

Question 3

An administrator needs to restrict kubelets so they can only modify resources associated with their own node (such as their own Node object and Pods bound to them). Which authorization mode must be enabled alongside RBAC?

Accepted Answer

Node. The Node authorizer is a special-purpose authorization mode designed specifically for kubelets. It restricts each kubelet's API requests to resources tied to its own node — its own Node object, Pods bound to that node, and related objects like Secrets, ConfigMaps, and PersistentVolumes referenced by those Pods. It must be enabled alongside RBAC (and typically NodeRestriction admission) so that kubelet credentials cannot read or modify cluster-wide resources.

Answer

ABAC

Answer

AlwaysDeny

Answer

PodSecurity

Question 4

An administrator needs to secure access to the Kubernetes API server from an external CI/CD pipeline. Which mechanism should be used to authenticate the pipeline using an existing external identity provider without embedding long-lived static tokens?

Accepted Answer

Configure the API server with --oidc-issuer-url and related flags to validate JSON Web Tokens issued by the IDP.. Configuring the API server with --oidc-issuer-url, --oidc-client-id, and related flags lets it validate JSON Web Tokens (ID tokens) issued by an external OIDC identity provider, enabling short-lived, federated authentication for the CI/CD pipeline without static credentials. The pipeline obtains a token from the IdP (e.g., via client credentials or workload identity federation) and presents it as a Bearer token; the API server verifies the signature against the issuer's JWKS and maps claims to a username and groups for RBAC.

Answer

Store the administrative kubeconfig file in a public ConfigMap.

Answer

Enable anonymous requests on the API server for the CI/CD CIDR block.

Answer

Create a shared static password file and pass it via --basic-auth-file.

Question 5

Which component in the Kubernetes control plane is directly responsible for interacting with etcd to persist and retrieve cluster state?

Accepted Answer

kube-apiserver. The kube-apiserver is the only control plane component that talks directly to etcd. It exposes the REST API, validates and mutates objects via admission controllers, and persists/retrieves all cluster state in etcd. Other components (scheduler, controller-manager, kubelet) interact with the API server, never with etcd directly.

Answer

kube-controller-manager

Answer

kube-scheduler

Answer

kubelet

Question 6

You are hardening etcd and want to ensure that sensitive data stored in Kubernetes secrets is encrypted at rest within etcd. Which API server configuration file parameter specifies how secrets should be encrypted?

Accepted Answer

--encryption-provider-config. The kube-apiserver flag --encryption-provider-config points to an EncryptionConfiguration YAML file that defines which resources (e.g., secrets) are encrypted and which providers (aescbc, aesgcm, kms, secretbox, identity) are used. This is the only supported mechanism for encrypting Kubernetes Secrets at rest in etcd. Without it, secrets are stored as base64-encoded plaintext in etcd.

Answer

--etcd-encryption-key

Answer

--secrets-encryption-enabled

Answer

--etcd-ca-file

Question 7

An incident response team suspects that an attacker has gained unauthorized access to the cluster via an unencrypted etcd backup file containing sensitive cluster state. Which etcd utility should be used to securely snapshot and backup etcd data?

Accepted Answer

etcdctl snapshot save. The etcdctl snapshot save command is used to create a secure, consistent backup of etcd data. It captures the entire etcd database, including cluster state and secrets, and can be encrypted or stored securely. This is the standard utility for backing up etcd in Kubernetes, especially for disaster recovery and security audits.

Answer

kubectl cluster-info dump --etcd

Answer

etcd-backup-controller

Answer

kubeadm backup etcd

Question 8

Where are static pods for a control plane node typically defined so that the kubelet can automatically create and manage them?

Accepted Answer

In the directory specified by staticPodPath in the kubelet configuration file (default /etc/kubernetes/manifests).. Static pods are defined as YAML manifest files placed in the directory specified by the 'staticPodPath' setting in the kubelet configuration (default /etc/kubernetes/manifests). The kubelet watches this directory and automatically creates, updates, and manages pods from any manifests it finds there, without involving the API server scheduler.

Answer

In the ~/.kube/config file of the root user.

Answer

In the etcd database under the /registry/staticpods prefix.

Answer

In the kube-system namespace as standard Deployment objects.

Question 9

A cluster administrator wants to implement admission control auditing to record all mutating and validating requests made to the API server. Which component configuration handles this requirement?

Accepted Answer

Configure an audit policy file and pass its path to the API server via --audit-policy-file.. The Kubernetes API server is the only component that processes admission control requests (mutating and validating webhooks, plus built-in admission plugins). To record these requests for auditing, you must configure the API server with an audit policy file using the --audit-policy-file flag, which defines what events to record and at what level (e.g., Metadata, Request, RequestResponse). This flag, along with --audit-log-path or --audit-webhook-config-file, enables audit logging of all API requests, including those that go through admission controllers.

Answer

Configure the kubelet audit webhook via /etc/kubernetes/audit.json.

Answer

Enable kube-proxy audit mode using --audit-proxy=true.

Answer

Set etcd logging level to DEBUG in the etcd configuration yaml.

Question 10

You are reviewing security logs on a control plane node and discover that an unauthenticated user accessed the kubelet's HTTPS port (10250) to execute commands inside containers. How should you restrict kubelet authentication and authorization to prevent this?

Accepted Answer

Set authentication.anonymous.enabled: false and authorization.mode: Webhook in the kubelet configuration file.. Setting authentication.anonymous.enabled to false disables unauthenticated access to the kubelet, and setting authorization.mode to Webhook delegates authorization decisions to the API server, which enforces RBAC. This combination ensures that only authenticated and authorized requests can execute commands via the kubelet, preventing the observed unauthenticated access.

Answer

Enable the kubelet insecure-port flag.

Answer

Set authorization.mode: AlwaysAllow in the kubelet configuration file.

Answer

Disable the API server proxy subresource.

Question 11

Which file on a Kubernetes control plane node contains the startup arguments and flags for the statically hosted API server?

Accepted Answer

/etc/kubernetes/manifests/kube-apiserver.yaml. On kubeadm-provisioned control plane nodes, the API server runs as a static Pod, and its manifest — including all command-line flags such as --advertise-address, --etcd-servers, and --authorization-mode — lives at /etc/kubernetes/manifests/kube-apiserver.yaml. The kubelet watches this directory and starts/restarts the static Pod whenever the file changes, so editing this YAML is how administrators modify API server startup arguments.

Answer

/etc/systemd/system/kube-apiserver.service

Answer

/etc/default/kube-apiserver

Answer

/var/lib/kubelet/config.yaml

Question 12

You need to audit the cryptographic algorithms and TLS versions permitted by the Kubernetes API server for incoming client connections. Which API server flag enforces a minimum TLS version of 1.3?

Accepted Answer

--tls-min-version=VersionTLS13. The kube-apiserver flag `--tls-min-version` sets the minimum TLS version accepted for incoming client connections. To enforce TLS 1.3, the value must be `VersionTLS13` (the Go constant used by the API server). This flag is part of the secure serving options and is critical for compliance with modern cryptographic standards.

Answer

--min-tls=1.3

Answer

--cipher-suites=TLS_AES_256_GCM_SHA384

Answer

--ssl-version=TLSv3

Question 13

Which Kubernetes control plane component is responsible for noticing and responding when nodes go down or fail health checks?

Accepted Answer

kube-controller-manager. The kube-controller-manager runs the node controller, which monitors node health via heartbeats and marks nodes NotReady or unreachable when they fail health checks, then triggers eviction of pods after the toleration period. It is the control plane component responsible for responding to node failures.

Answer

CoreDNS

Answer

etcd

Answer

kube-proxy

Question 14

An administrator suspects that someone is attempting brute-force attacks against the Kubernetes API server. Where should the administrator look to inspect authentication failures generated by the API server?

Accepted Answer

API server audit logs configured via --audit-log-path.. The kube-apiserver audit log, enabled with flags like --audit-log-path, --audit-policy-file, and --audit-log-maxage, records every request including authentication failures, the requesting user, source IP, and response status. Brute-force attempts appear as repeated 401 Unauthorized responses from the same source, making the audit log the authoritative source for this investigation.

Answer

The etcd WAL (Write-Ahead Log) files.

Answer

The kubelet container logs on worker nodes.

Answer

The kube-proxy packet capture logs.

Question 15

You are securing a highly regulated Kubernetes cluster and need to ensure that etcd data is encrypted at rest using a custom encryption key. After creating the EncryptionConfiguration file, which API server flag must be updated to point to this file?

Accepted Answer

--encryption-provider-config. The kube-apiserver flag --encryption-provider-config is the correct flag that points the API server to the EncryptionConfiguration YAML file defining the encryption providers (e.g., aescbc, kms) and their keys. Without this flag, the API server ignores the file entirely and etcd data remains unencrypted at rest. The flag was introduced with the EncryptionConfiguration API (stable since Kubernetes 1.13) and is required alongside the file itself for encryption to take effect.

Answer

--data-encryption-secret

Answer

--encryption-config-path

Answer

--etcd-key-file