CCNA Kubernetes Cluster Component Security Questions

MCQhard

A Kubernetes administrator is hardening a cluster and wants to ensure that the kubelet only accepts certificates from clients that have been signed by the cluster's certificate authority. The administrator has already configured the kubelet with --client-ca-file pointing to the correct CA bundle. Which additional kubelet configuration parameter must be set to enforce certificate-based authentication and reject anonymous requests?

A.--tls-cert-file

B.--anonymous-auth=false

C.--authentication-token-webhook=true

D.--authorization-mode=Webhook

AnswerB

--anonymous-auth=false disables anonymous access to the kubelet API, forcing all requests to be authenticated. When combined with --client-ca-file, the kubelet will require clients to present a valid client certificate signed by the specified CA. This ensures that only authenticated clients can interact with the kubelet, which is a critical security hardening step. Without this, anonymous requests might still be allowed even if client certificates are configured.

Why this answer

To enforce certificate-based authentication and reject anonymous requests, the kubelet must have --anonymous-auth set to false. This setting ensures that any request without valid credentials is denied. When --client-ca-file is also configured, the kubelet will validate client certificates against the specified CA.

Together, these settings ensure that only clients with certificates signed by the cluster CA can access the kubelet API, significantly reducing the attack surface.

Exam trap

The trap here is assuming that configuring --client-ca-file alone is sufficient to require client certificates, when anonymous authentication must also be explicitly disabled.

Practice this question →

MCQmedium

An administrator wants to verify that etcd database defragmentation is performed periodically to reclaim storage space after large amounts of data churn. Which etcdctl command defragments an etcd member?

A.kubectl etcd-clean

B.etcdctl defrag

C.etcdctl compact

D.etcdctl cleanup storage

AnswerB

`etcdctl defrag` compacts the backend database file on a single etcd member, releasing free space left by deleted keys after heavy churn. It satisfies the stem's requirement to reclaim storage periodically. Run it against each member individually, since defragmentation is per-member and does not propagate across the cluster.

Why this answer

The etcdctl defrag command defragments an etcd member's database, reclaiming storage space after data churn (e.g., many writes and deletes). Defragmentation compacts the underlying BoltDB file, reducing its size and improving performance. It is typically run periodically on each etcd member, often after compaction.

Exam trap

KCSA often tests the confusion between compaction and defragmentation: candidates may pick 'compact' thinking it reclaims space, but only 'defrag' actually reduces the database file size.

How to eliminate wrong answers

Option A is wrong because 'kubectl etcd-clean' is not a valid command; kubectl does not manage etcd directly. Option C is wrong because 'etcdctl compact' discards old revisions but does not reclaim disk space; compaction only marks space as available for reuse, while defrag actually rewrites the database to free space. Option D is wrong because 'etcdctl cleanup storage' is not a valid etcdctl subcommand; the correct command is 'defrag'.

Practice this question →

MCQeasy

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

A.CoreDNS

B.etcd

C.kube-controller-manager

D.kube-proxy

AnswerC

The kube-controller-manager runs the node lifecycle controller, which monitors node heartbeats and health checks, then applies taints and evicts pods when a node becomes unreachable, satisfying the requirement to notice and respond to node failures.

Why this answer

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.

Exam trap

KCSA often tests the division of labor among control plane components, baiting candidates who attribute node health response to etcd (which stores state) or kube-proxy (which handles networking).

How to eliminate wrong answers

Option A is wrong because CoreDNS provides cluster DNS resolution for service discovery, not node health monitoring. Option B is wrong because etcd is the distributed key-value store backing the cluster state; it stores node status but does not react to node failures. Option D is wrong because kube-proxy manages iptables/IPVS rules for service networking on each node, not node lifecycle or health.

Practice this question →

MCQmedium

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?

A.Node

B.ABAC

C.AlwaysDeny

D.PodSecurity

AnswerA

The Node authorizer grants kubelets permission only for API operations relating to their own node, including their Node object and Pods scheduled there. Enabling it alongside RBAC enforces the node-scoped restriction the stem requires, rather than cluster-wide access.

Why this answer

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.

Exam trap

KCSA often tests the confusion between authorization modes and admission controllers, tricking candidates into choosing PodSecurity (an admission plugin) when the question asks which authorization mode scopes kubelets to their own node.

How to eliminate wrong answers

Option B is wrong because ABAC is a legacy attribute-based authorization mode using static policy files; it is not node-aware and does not scope kubelets to their own node's resources. Option C is wrong because AlwaysDeny is a testing-only authorizer that denies every request, which would break the kubelet entirely rather than restrict it appropriately. Option D is wrong because PodSecurity is an admission controller (enforcing Pod Security Standards like privileged/baseline/restricted), not an authorization mode, and it does not govern which API resources a kubelet may modify.

Practice this question →

MCQhard

You are auditing a multi-tenant Kubernetes cluster and notice that users can read ServiceAccount tokens belonging to other namespaces through improper RBAC configuration. Which ClusterRole permission should be strictly avoided or audited to prevent token theft via secret inspection?

A.Verbs like 'get' on resource 'pods/status'.

B.Verbs like 'list' on resource 'namespaces'.

C.Verbs like 'create' on resource 'deployments'.

D.Verbs like 'get', 'list', or 'watch' on resource 'secrets' across all namespaces.

AnswerD

Cluster-wide get, list, or watch on secrets lets any bound subject read every namespace's ServiceAccount tokens, enabling impersonation and lateral movement. Auditing and removing these verbs prevents cross-namespace token theft, directly addressing the improper RBAC configuration described in the stem.

Why this answer

To prevent token theft via secret inspection, you must avoid or audit ClusterRole permissions that allow 'get', 'list', or 'watch' on 'secrets' across all namespaces. ServiceAccount tokens are stored as Secrets, so broad read access to secrets enables attackers to steal tokens and escalate privileges. Option D correctly identifies this critical permission set.

Exam trap

KCSA often tests the misconception that other permissions like pod status or namespace listing are risky, but the real danger is broad secret read access, which directly enables token theft and privilege escalation.

How to eliminate wrong answers

Option A is wrong because 'get' on 'pods/status' only allows reading pod status subresources, which does not expose ServiceAccount tokens. Option B is wrong because 'list' on 'namespaces' only allows listing namespaces, not reading secrets within them. Option C is wrong because 'create' on 'deployments' allows creating deployments, which could be abused but does not directly grant access to secrets; it is not the primary permission for token theft.

Practice this question →

MCQhard

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?

A.kubectl cluster-info dump --etcd

B.etcd-backup-controller

C.kubeadm backup etcd

D.etcdctl snapshot save

AnswerD

etcdctl snapshot save creates a consistent, restorable backup of the etcd key-value store, capturing cluster state including Secrets. This directly addresses the unencrypted backup exposure by producing a snapshot the team can secure and encrypt.

Why this answer

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.

Exam trap

KCSA often tests the confusion between etcd backup and other backup methods, tricking candidates into selecting kubectl or kubeadm commands that do not actually back up etcd data.

How to eliminate wrong answers

Option A is wrong because 'kubectl cluster-info dump --etcd' is not a valid command; kubectl cluster-info dump outputs cluster information but does not back up etcd. Option B is wrong because 'etcd-backup-controller' is not a standard etcd utility; it may refer to a custom controller, but not the official tool. Option C is wrong because 'kubeadm backup etcd' is not a valid kubeadm command; kubeadm has 'kubeadm init' and 'kubeadm upgrade', but etcd backup is done via etcdctl.

Practice this question →

MCQhard

You are performing a security review of etcd cluster membership. You need to list all active members of the etcd cluster and check their health status using the command line. Which etcdctl command is correct?

A.etcdctl check membership

B.etcdctl member list and etcdctl endpoint health

C.etcdctl cluster status

D.kubectl get etcdmembers

AnswerB

'etcdctl member list' enumerates cluster membership with IDs, peer URLs and client URLs, while 'etcdctl endpoint health' probes each endpoint's responsiveness and reports whether it is healthy. Together they satisfy the review requirement to list active members and verify their health status.

Why this answer

etcdctl provides two distinct subcommands for this task: 'etcdctl member list' enumerates all cluster members with their IDs, peer URLs, and client URLs, while 'etcdctl endpoint health' queries each endpoint to verify it can serve requests and is not lagging. Together they satisfy the requirement to list active members and check their health.

Exam trap

KCSA often tests whether candidates confuse etcdctl subcommands with kubectl commands, or invent plausible-sounding subcommands like 'check membership' that do not exist.

How to eliminate wrong answers

Option A is wrong because 'etcdctl check membership' is not a valid etcdctl subcommand — etcdctl uses 'member list', 'member add', 'member remove', and 'member update'. Option C is wrong because 'etcdctl cluster status' does not exist; cluster-wide status is obtained via 'etcdctl endpoint status' (which reports raft term, leader, and DB size). Option D is wrong because 'kubectl get etcdmembers' is not a Kubernetes resource — etcd is not exposed as a native Kubernetes API object, and kubectl cannot query etcd membership directly.

Practice this question →

MCQeasy

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

A.kube-controller-manager

B.kube-scheduler

C.kube-apiserver

D.kubelet

AnswerC

The kube-apiserver is the sole control-plane component that reads from and writes to etcd, serving as the cluster's persistent state gateway. Controllers and schedulers never touch etcd directly; they watch the API server. This satisfies the stem's requirement for the component directly responsible for persisting and retrieving cluster state.

Why this answer

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.

Exam trap

KCSA often tests the misconception that other control plane components (scheduler, controller-manager) communicate with etcd, when in fact only the kube-apiserver does.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager watches the API server for resource changes and reconciles desired state; it does not connect to etcd. Option B is wrong because kube-scheduler only binds pods to nodes via the API server and has no etcd client. Option D is wrong because kubelet runs on nodes, receives pod specs from the API server, and manages containers; it never touches etcd.

Practice this question →

Multi-Selectmedium

Which THREE of the following criteria should be evaluated when reviewing Kubernetes RBAC policies to ensure least privilege? (Choose THREE)

Select 3 answers

A.Carefully audit permissions that allow impersonation or binding of roles.

B.Limit the use of cluster-scoped ClusterRoleBindings to cases where namespace-scoped Roles are insufficient.

C.Ensure anonymous users have write access to all namespaces.

D.Avoid granting wildcard permissions (*) on sensitive resources like secrets or cluster roles.

E.Grant cluster-admin permissions to every service account by default.

AnswersA, B, D

Impersonation and role-binding permissions let a subject assume another identity or grant itself extra rights, bypassing namespace boundaries. Auditing these satisfies the least-privilege criterion by exposing privilege-escalation paths that ordinary permission reviews miss, since the granted verb is not the resource access itself.

Why this answer

Option A is correct because permissions such as impersonate and bind/escalate on users, groups, serviceaccounts, or roles let a subject assume other identities or grant themselves broader rights, directly undermining least privilege and requiring careful audit. Option B is correct because ClusterRoleBindings grant permissions across all namespaces and cluster-scoped resources, so they should be reserved for cases where a namespaced RoleBinding cannot provide the needed access. Option D is correct because wildcard (*) verbs or resources on sensitive objects like secrets, roles, and clusterroles can silently grant far more access than intended, violating least privilege.

Option C is incorrect because anonymous write access to all namespaces is a severe over-permission and the opposite of least privilege. Option E is incorrect because granting cluster-admin to every service account by default is excessive privilege and a well-known anti-pattern.

Exam trap

KCSA often tests least-privilege RBAC by mixing in obviously bad options (anonymous write, cluster-admin for all) with subtle good ones (auditing impersonation/bind, limiting ClusterRoleBindings, avoiding wildcards), so candidates must recognize the anti-patterns quickly.

Practice this question →

Multi-Selecthard

Which TWO of the following kubelet security configurations are critical for preventing container escape and unauthorized node API access? (Choose TWO)

Select 2 answers

A.Enable anonymous authentication on the kubelet secure port.

B.Run kubelet containers in privileged mode.

C.Configure kubelet authorization mode to Webhook.

D.Set authorization.mode to AlwaysAllow.

E.Disable the unauthenticated read-only port by setting readOnlyPort to 0.

AnswersC, E

Webhook authorisation delegates kubelet API access decisions to the API server, so it evaluates RBAC and enforces authentication. This satisfies the constraint against unauthorised node API access, replacing permissive AlwaysAllow with centrally governed, identity-based checks.

Why this answer

Option C is correct because setting the kubelet authorization mode to Webhook delegates authorization decisions to the API server's SubjectAccessReview, ensuring that only authenticated and properly authorized subjects (such as nodes and system components) can perform actions against the kubelet's API, which prevents unauthorized node API access. Option E is correct because the kubelet's read-only port (default 10255) serves unauthenticated and unencrypted data; setting readOnlyPort to 0 disables it entirely, closing an anonymous access vector that could leak node and pod information or be abused. Option A is wrong because enabling anonymous authentication on the secure port would allow unauthenticated requests, directly undermining access control rather than preventing it.

Option B is wrong because running kubelet containers in privileged mode grants broad host capabilities and increases container-escape risk instead of mitigating it. Option D is wrong because authorization.mode AlwaysAllow permits all requests without any authorization checks, which is the opposite of a secure configuration.

Exam trap

KCSA often tests the pairing of authentication and authorization hardening — candidates pick 'enable anonymous auth' or 'AlwaysAllow' thinking they simplify access, when both are exactly the misconfigurations the question is warning against.

Practice this question →

MCQhard

You are hardening etcd on a dedicated control plane host. You want to ensure that etcd database files on disk are protected against unauthorized physical or filesystem access. Which control mechanism is best suited for this?

A.Kubernetes NetworkPolicies applied to the etcd Pod.

B.API server RBAC ClusterRoleBinding.

C.Filesystem or block-level disk encryption (e.g., LUKS) on the host storage volume.

D.Kubelet read-only port disabling.

AnswerC

LUKS encrypts the underlying block device, so etcd's WAL and snapshot files are unreadable even if disks are stolen or the filesystem is mounted elsewhere. This directly satisfies the requirement to protect etcd database files against unauthorised physical or filesystem access.

Why this answer

Filesystem or block-level disk encryption (e.g., LUKS on Linux) is the correct control because it protects etcd data files at rest against physical theft or unauthorized filesystem access. If an attacker steals the disk or gains raw block-device access, LUKS-encrypted volumes are unreadable without the decryption key. This directly addresses the threat model of physical or offline filesystem compromise, which is what the question asks about.

Exam trap

The trap is picking a Kubernetes-native control (NetworkPolicy, RBAC, kubelet port) for a threat that is fundamentally about physical/offline disk access — candidates must recognize that only host-level disk encryption addresses the stated threat model.

How to eliminate wrong answers

Option A is wrong because NetworkPolicies only control Pod-to-Pod network traffic within the cluster — they do nothing to protect data files on disk from physical or filesystem-level access. Option B is wrong because API server RBAC governs who can make API calls to Kubernetes resources; it does not encrypt or protect etcd's on-disk database files from someone with host access. Option D is wrong because disabling the kubelet read-only port (10255) closes an unauthenticated information-disclosure endpoint, but it has no bearing on protecting etcd's data files on disk.

Practice this question →

MCQhard

You are troubleshooting a control plane failure where the Kubernetes API server cannot communicate with etcd because of expired client certificates. Which command-line flag on the kube-apiserver specifies the client TLS certificate used for authentication against etcd?

A.--etcd-private-key

B.--etcd-certfile

C.--client-cert-file

D.--etcd-ca-file

AnswerB

The `--etcd-certfile` flag supplies the client TLS certificate the kube-apiserver presents to etcd, directly resolving the expired-certificate failure described. Its counterpart, `--etcd-keyfile`, provides the matching private key, while `--tls-cert-file` covers serving clients rather than etcd authentication.

Why this answer

The kube-apiserver flag --etcd-certfile specifies the client TLS certificate that the API server presents to etcd for mutual TLS authentication. When the API server connects to etcd, it must authenticate itself using a client certificate; this flag points to the PEM-encoded certificate file. Without it, the API server cannot establish a secure connection to etcd, leading to control plane failures.

The correct flag is explicitly named for the etcd client certificate, not a generic client certificate.

Exam trap

The trap here is confusing the etcd client certificate flag (--etcd-certfile) with the API server's own serving certificate flag (--tls-cert-file) or the CA certificate flag (--etcd-ca-file), causing candidates to select a plausible but incorrect option.

How to eliminate wrong answers

Option A is wrong because --etcd-private-key specifies the private key corresponding to the client certificate, not the certificate itself; both are needed but the question asks for the certificate flag. Option C is wrong because --client-cert-file is not a valid kube-apiserver flag; the API server uses --tls-cert-file for its own serving certificate and --etcd-certfile for etcd client authentication. Option D is wrong because --etcd-ca-file specifies the CA certificate bundle used to verify the etcd server's certificate, not the client certificate presented by the API server.

Practice this question →

MCQmedium

An administrator wants to audit who created or modified specific resources in the cluster. Where are API server audit records sent if configured with the log backend?

A.Directly to the etcd key-value store under /audit/logs.

B.To the container stdout of kube-proxy.

C.To the kubelet systemd journal on worker nodes.

D.To the file path specified by --audit-log-path on the control plane host.

AnswerD

The log backend writes audit events as JSON lines to the file named by --audit-log-path on the control plane node, with rotation controlled by --audit-log-maxage, --audit-log-maxbackup and --audit-log-maxsize. No external service is required; records persist locally for later collection.

Why this answer

When the Kubernetes API server is configured with the log audit backend, audit records are written to the file path specified by the --audit-log-path flag on the control plane host. This is the default and most straightforward backend for audit logging, allowing administrators to review who did what and when. The log backend writes JSON-formatted audit events to that file, which can then be rotated and analyzed.

Exam trap

KCSA often tests the misconception that audit logs are stored in etcd or are part of normal container logs, when in fact they are written to a separate file when using the log backend.

How to eliminate wrong answers

Option A is wrong because etcd stores cluster state, not audit logs; audit records are not written to etcd under /audit/logs. Option B is wrong because kube-proxy is a network proxy component and does not handle API server audit logs; its container stdout is unrelated. Option C is wrong because the kubelet systemd journal on worker nodes contains kubelet logs, not API server audit records.

Practice this question →

MCQmedium

An administrator needs to ensure that the Kubernetes API server does not allow insecure cipher suites during TLS handshakes. Which API server flag allows specifying the exact cipher suites permitted?

A.--cipher-list

B.--tls-cipher-suites

C.--secure-ciphers

D.--etcd-cipher-suites

AnswerB

The --tls-cipher-suites flag accepts an explicit comma-separated list of permitted cipher suites, restricting TLS handshakes to approved algorithms. It directly satisfies the requirement to disallow insecure suites by overriding the API server's default cipher selection.

Why this answer

The --tls-cipher-suites flag on the kube-apiserver allows administrators to specify a comma-separated list of allowed cipher suites for TLS handshakes. This directly controls which cipher suites the API server will accept, enabling compliance with security policies that require strong ciphers and disallow insecure ones.

Exam trap

The trap is that candidates may confuse --etcd-cipher-suites with --tls-cipher-suites; the former is for etcd communication, while the latter is for the API server's own TLS endpoint.

How to eliminate wrong answers

Option A is wrong because --cipher-list is not a valid kube-apiserver flag; it does not exist. Option C is wrong because --secure-ciphers is not a valid kube-apiserver flag. Option D is wrong because --etcd-cipher-suites is used to configure cipher suites for the connection between the API server and etcd, not for the API server's own TLS handshakes with clients.

Practice this question →

MCQhard

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?

A.It bypasses all authentication and authorization modules, granting full administrative access to anyone who reaches the port.

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

C.It restricts API access exclusively to read-only operations.

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

AnswerA

The insecure port serves requests without passing them through authentication or authorization, so any client reaching port 8080 obtains full administrative API access. Disabling it removes this unauthenticated bypass of the control plane's access controls.

Why this answer

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.

Exam trap

KCSA often tests the misconception that the insecure port is merely 'unencrypted but still authenticated' — candidates pick options about TLS downgrade or read-only access, missing that the flag's real danger is total bypass of both authentication and authorization.

How to eliminate wrong answers

Option B is wrong because kubelet-to-apiserver communication uses the secure port (default 6443) with client certificates issued by the cluster CA; the insecure port has no bearing on kubelet connectivity. Option C is wrong because the insecure port does not restrict verbs — it grants the full API surface, including write and delete operations, to anonymous callers. Option D is wrong because the insecure port does not negotiate TLS at all; it serves plain HTTP, so there are no cipher suites to downgrade, and it does not affect the TLS configuration of the secure port.

Practice this question →

MCQhard

You are hardening a production Kubernetes control plane. You need to ensure that etcd client-to-server and peer communications are strictly encrypted in transit and require mutual TLS (mTLS). Which etcd configuration flag combination enforces this requirement?

A.--auto-tls=true for all endpoints.

B.--client-cert-auth=true and --peer-client-cert-auth=true along with valid CA and key pair paths.

C.--insecure-transport=false combined with HTTP proxy routing.

D.--cipher-suites=TLS_RSA_WITH_AES_128_CBC_SHA

AnswerB

Setting `--client-cert-auth=true` and `--peer-client-cert-auth=true` forces etcd to verify client and peer certificates against the configured CA, delivering the mutual TLS the stem demands. Supplying the CA and key pair paths enables that verification for both client-to-server and peer traffic, so all control plane communication is encrypted and mutually authenticated.

Why this answer

The flags --client-cert-auth=true and --peer-client-cert-auth=true force etcd to require and verify client certificates on both the client-facing listener (port 2379) and the peer listener (port 2380), which is exactly what mTLS demands. Combined with --cert-file, --key-file, --trusted-ca-file, --peer-cert-file, --peer-key-file, and --peer-trusted-ca-file, etcd will reject any connection that does not present a certificate signed by the trusted CA. This is the canonical CIS Kubernetes Benchmark configuration for a hardened etcd.

Exam trap

KCSA often tests the misconception that enabling TLS (via cert files or --auto-tls) automatically implies mTLS, when in fact mutual authentication requires the explicit --client-cert-auth and --peer-client-cert-auth flags.

How to eliminate wrong answers

Option A is wrong because --auto-tls=true only auto-generates a self-signed certificate for server-side TLS; it does not enable client certificate authentication, so clients are not mutually authenticated and mTLS is not enforced. Option C is wrong because --insecure-transport=false is not a real etcd flag (the actual flag is --insecure-transport, and disabling it only affects the client listener, not peer mTLS), and HTTP proxy routing has nothing to do with etcd's TLS handshake. Option D is wrong because --cipher-suites only restricts the negotiated TLS cipher suites and does nothing to require client certificates; additionally, TLS_RSA_WITH_AES_128_CBC_SHA is a legacy CBC cipher that is not even in etcd's default Go cipher list and provides no mutual authentication.

Practice this question →

Multi-Selecthard

Which TWO of the following API server configuration flags help enforce cryptographic and transport security? (Choose TWO)

Select 2 answers

A.--tls-cipher-suites to specify permitted strong cryptographic cipher suites.

B.--tls-min-version to enforce a minimum acceptable TLS protocol version.

C.--anonymous-auth to enable unauthenticated cluster access.

D.--insecure-port to allow unencrypted HTTP traffic.

E.--enable-http2=false to disable secure multiplexing.

AnswersA, B

The flag restricts the API server to an explicit allowlist of strong cipher suites, preventing negotiation of weak or deprecated algorithms during TLS handshakes. This directly enforces the cryptographic security constraint in the stem by hardening transport encryption for client and component connections.

Why this answer

Option A, --tls-cipher-suites, is correct because it lets you restrict the API server to a defined list of strong, permitted TLS cipher suites, preventing negotiation of weak or deprecated ciphers and thereby hardening cryptographic security. Option B, --tls-min-version, is correct because it sets the minimum acceptable TLS protocol version (for example VersionTLS12), ensuring clients cannot downgrade to older, vulnerable TLS versions. Together these flags directly enforce cryptographic strength and transport-layer security on the kube-apiserver.

Option C, --anonymous-auth, is wrong because enabling unauthenticated access weakens security rather than enforcing it. Option D, --insecure-port, is wrong because it permits unencrypted HTTP traffic, the opposite of transport security. Option E, --enable-http2=false, is wrong because disabling HTTP/2 does not enforce cryptographic or transport security and is not a security-hardening flag for this purpose.

Exam trap

KCSA often tests whether candidates confuse flags that weaken security (--anonymous-auth, --insecure-port) with flags that strengthen it (--tls-cipher-suites, --tls-min-version), so read each flag's effect carefully rather than pattern-matching on the word 'TLS'.

Practice this question →

Multi-Selecteasy

Which THREE of the following actions can compromise the security of the Kubernetes control plane if left unmitigated? (Choose THREE)

Select 3 answers

A.Granting wildcard cluster-admin permissions to untrusted service accounts.

B.Enabling anonymous authentication on the API server or kubelet.

C.Configuring kubelet authorization mode to Webhook.

D.Enabling etcd encryption at rest with a valid key.

E.Leaving the API server insecure port (--insecure-port) enabled.

AnswersA, B, E

Wildcard cluster-admin grants untrusted service accounts unrestricted access across every resource and namespace, letting compromised workloads read secrets, alter workloads, or disable controls. This directly satisfies the stem's control-plane compromise scenario by removing least-privilege boundaries.

Why this answer

Option A is correct because binding a service account to a ClusterRole with wildcard verbs/resources (e.g., via ClusterRoleBinding to cluster-admin) lets any pod using that account read secrets, create privileged workloads, and effectively take over the control plane. Option B is correct because enabling anonymous authentication (--anonymous-auth=true) on the API server or kubelet allows unauthenticated requests to reach endpoints, and combined with permissive authorization it exposes cluster data and node operations to anyone who can reach the port. Option E is correct because the API server's insecure port (--insecure-port) serves requests over plain HTTP with no authentication or authorization, so any network-reachable client can issue privileged API calls.

Option C is not a compromise: Webhook authorization mode delegates decisions to the API server's SubjectAccessReview, which is the recommended secure mode for kubelet. Option D is not a compromise: encrypting etcd at rest with a valid key protects secret data and is a security best practice, not a risk.

Exam trap

KCSA often tests whether candidates can distinguish security-hardening controls (Webhook authorization, etcd encryption) from actual misconfigurations — the trap is picking a best-practice option as if it were a risk.

Practice this question →

Multi-Selecteasy

Which THREE of the following are key components of the Kubernetes control plane? (Choose THREE)

Select 3 answers

A.kube-scheduler

B.container runtime (e.g., containerd)

C.kube-controller-manager

D.kube-proxy

E.kube-apiserver

AnswersA, C, E

kube-scheduler assigns unscheduled pods to nodes by evaluating resource requests, affinity rules and taints against available capacity. It runs as a control plane component alongside the API server and controller manager, satisfying the stem's requirement for a core control plane element rather than a worker-node agent such as kubelet.

Why this answer

The Kubernetes control plane is composed of the components that make global cluster decisions and expose the cluster API. Option E, kube-apiserver, is correct because it is the front end of the control plane, serving the REST API on port 6443 and acting as the central communication hub that all other components talk to. Option A, kube-scheduler, is correct because it watches for newly created Pods with no assigned node and selects a suitable node based on resource requirements, affinity, and taints/tolerations.

Option C, kube-controller-manager, is correct because it runs the core control loops (such as the node, replication, endpoints, and service account controllers) that reconcile desired state with observed state. Option B, the container runtime (e.g., containerd), is not a control plane component; it runs on every node (including workers) as part of the kubelet's container execution layer via the CRI. Option D, kube-proxy, is also not a control plane component; it runs on each node to implement Service networking rules via iptables or IPVS, making it a node-level networking component rather than part of the control plane.

Exam trap

KCSA often tests whether candidates can separate control-plane components from node components — the trap is selecting kube-proxy or the container runtime because they are essential to cluster operation, even though they run on worker nodes, not the control plane.

Practice this question →

MCQeasy

Which protocol and default secure port does the kubelet use to listen for incoming authenticated requests from the API server and metrics collectors?

A.HTTPS on port 10250

B.HTTPS on port 6443

C.TCP on port 2379

D.HTTP on port 10255

AnswerA

The kubelet serves its authenticated HTTPS endpoint on port 10250, used by the API server for logs, exec and metrics, and by metrics collectors. HTTPS on 10250 satisfies the stem's requirement for a secure, authenticated protocol and default port.

Why this answer

The kubelet listens on HTTPS port 10250 by default for authenticated requests from the API server (e.g., kubectl logs, exec) and from metrics collectors like the metrics-server. This port requires authentication and authorization (via the kubelet's --authorization-mode and client CA), and it is the standard secure endpoint for kubelet API access. Port 10255 is the read-only, unauthenticated HTTP port that is disabled by default in modern Kubernetes due to security concerns.

Exam trap

KCSA often tests whether candidates confuse the API server port (6443) with the kubelet port (10250) or the deprecated read-only port (10255) — the trap is picking 6443 because it is the most familiar Kubernetes port, when the question specifically asks about the kubelet.

How to eliminate wrong answers

Option B is wrong because port 6443 is the default secure port for the Kubernetes API server (kube-apiserver), not the kubelet — confusing the two is a common mistake. Option C is wrong because port 2379 is the default client port for etcd, the cluster datastore, not the kubelet. Option D is wrong because port 10255 is the kubelet's read-only, unauthenticated HTTP port, which is deprecated and disabled by default in current Kubernetes versions due to the security risk of exposing node and pod information without authentication.

Practice this question →

MCQeasy

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

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

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

C./etc/default/kube-apiserver

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

AnswerB

Static pods are defined by manifest files in /etc/kubernetes/manifests, which the kubelet watches and reconciles. The kube-apiserver.yaml manifest there holds the API server's startup arguments and flags, making it the authoritative source for that component's configuration.

Why this answer

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.

Exam trap

The trap is assuming the API server is a systemd service (like kubelet) and therefore choosing a .service file, when in kubeadm clusters it is a static Pod defined in /etc/kubernetes/manifests/.

How to eliminate wrong answers

Option A is wrong because /etc/systemd/system/kube-apiserver.service is not the standard location for the API server unit in kubeadm clusters — the API server is a static Pod, not a systemd-managed service (though kubelet itself is a systemd service). Option C is wrong because /etc/default/kube-apiserver is not a standard Kubernetes path; /etc/default is used for environment files of some systemd services, not for the API server's flags. Option D is wrong because /var/lib/kubelet/config.yaml is the kubelet's own configuration file (KubeletConfiguration), which governs kubelet behavior, not API server startup flags.

Practice this question →

MCQeasy

Which Kubernetes component manages the assignment of pending pods to healthy worker nodes based on resource availability and constraints?

A.kube-proxy

B.kube-scheduler

C.kube-apiserver

D.etcd

AnswerB

kube-scheduler watches for unscheduled pods and binds each to a node that satisfies resource requests, affinity and taints. This satisfies the stem's requirement for the component assigning pending pods to healthy workers based on availability and constraints.

Why this answer

kube-scheduler watches for newly created Pods that have no node assigned and selects a node for them to run on. It filters nodes through predicates (resource requests, taints/tolerations, node affinity, topology spread) and then scores the remaining candidates to pick the best fit. The result is written back to the API server as a binding.

Exam trap

The trap here is confusing the control-plane components' responsibilities — candidates often pick kube-apiserver because it 'handles everything', but scheduling is exclusively kube-scheduler's job.

How to eliminate wrong answers

Option A is wrong because kube-proxy programs iptables/IPVS rules for Service traffic on each node — it does not place Pods. Option C is wrong because kube-apiserver is the REST front end that persists objects to etcd and validates requests; it does not choose nodes. Option D is wrong because etcd is the distributed key-value store backing the cluster state, not a scheduling component.

Practice this question →

MCQmedium

An auditor notices that the kubelet on worker nodes is configured with --protect-kernel-defaults=true. What is the security purpose of this flag?

A.It ensures that critical kernel parameters match expected secure baseline settings and prevents unauthorized modification.

B.It encrypts all kernel log (kmsg) outputs.

C.It prevents the Linux kernel from running container workloads as root.

D.It forces the kubelet to run inside an isolated kernel container.

AnswerA

With --protect-kernel-defaults=true, the kubelet refuses to start if sysctl values differ from its expected secure baseline, and it will not modify them itself. This enforces consistent kernel hardening across nodes and blocks drift that could weaken container isolation.

Why this answer

The --protect-kernel-defaults flag in the kubelet enforces that certain kernel parameters (sysctls) and kernel module settings match the kubelet's expected secure defaults. When enabled, the kubelet will fail to start or will refuse to run pods if it detects that critical kernel tunables—such as those related to IP forwarding, memory overcommit, or panic settings—have been changed from the kubelet's built-in safe values. This prevents accidental or malicious modification of kernel settings that could weaken container isolation or destabilize the node.

Exam trap

KCSA often tests confusing security flags with similar-sounding purposes; candidates may mistakenly think --protect-kernel-defaults encrypts logs or enforces rootless containers, when it actually validates kernel parameters against secure defaults.

How to eliminate wrong answers

Option B is wrong because --protect-kernel-defaults does not encrypt kernel log outputs; kernel log encryption is not a kubelet feature and would typically involve other mechanisms like auditd or secure logging. Option C is wrong because the flag does not prevent containers from running as root; rootless containers are enforced by other means such as user namespaces or Pod Security Standards. Option D is wrong because the kubelet always runs as a host process, not inside a kernel container; the flag concerns kernel parameter validation, not kubelet isolation.

Practice this question →

MCQeasy

Which service account permission model is used by default when a pod is created without specifying a service account name?

A.The 'default' service account in the pod's namespace.

B.No service account is assigned.

C.The 'cluster-admin' service account.

D.The 'kube-system' privileged service account.

AnswerA

Kubernetes automatically mounts the namespace's 'default' ServiceAccount token into every pod lacking an explicit serviceAccountName. That identity, not a cluster-wide or admin account, is what the API server authenticates, so permissions are limited to whatever RBAC grants that default account.

Why this answer

When a pod is created without specifying a serviceAccountName, Kubernetes automatically assigns the 'default' service account from the pod's namespace. This is a built-in behavior: every namespace has a 'default' ServiceAccount created automatically, and the admission controller injects it if none is specified. This default account typically has no extra permissions beyond basic API discovery, but it still exists and can be used for identity.

Exam trap

KCSA often tests the misconception that pods run without any service account or that they get a privileged one by default; the trap is forgetting that the 'default' ServiceAccount is automatically assigned and can be a security risk if not audited.

How to eliminate wrong answers

Option B is wrong because Kubernetes always assigns a service account (the 'default' one) if none is specified; a pod cannot run without a service account identity in modern Kubernetes. Option C is wrong because 'cluster-admin' is a highly privileged ClusterRole binding, not a service account, and it is never assigned by default. Option D is wrong because 'kube-system' is a namespace, not a service account, and pods in other namespaces do not get a privileged service account from kube-system by default.

Practice this question →

MCQeasy

Which component is responsible for executing probes (liveness, readiness, startup) against containers running on a worker node?

A.kube-scheduler

B.kube-controller-manager

C.kubelet

D.kube-apiserver

AnswerC

The kubelet runs on each worker node as the node agent and directly manages pod containers. It executes liveness, readiness and startup probes locally against those containers, reporting results to the API server, so probe execution never depends on the control plane.

Why this answer

The kubelet is the node agent that runs on every worker node and is responsible for managing Pod lifecycle on that node. It receives PodSpecs from the API server and executes the actual container runtime operations, including running liveness, readiness, and startup probes against containers via the container runtime interface (CRI). The kubelet interprets probe definitions (httpGet, tcpSocket, exec, grpc) and periodically executes them, taking action such as restarting containers on liveness failure or removing Pods from Service endpoints on readiness failure.

Exam trap

The trap here is confusing control-plane components with the node agent — candidates often assume the kube-controller-manager or kube-apiserver runs probes because they 'manage' Pods, but probe execution is strictly a kubelet responsibility on the worker node.

How to eliminate wrong answers

Option A is wrong because the kube-scheduler only decides which node a Pod should be placed on based on resource requests, affinity, taints, and other scheduling constraints — it never interacts with running containers. Option B is wrong because the kube-controller-manager runs control-plane reconciliation loops (Deployment, ReplicaSet, Node, Endpoint controllers) and does not execute probes against containers. Option D is wrong because the kube-apiserver is the REST front-end for the cluster — it stores and serves object state but does not run probes; it merely persists probe configuration in the PodSpec.

Practice this question →

MCQmedium

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?

A.--secure-port=0

B.--authorization-mode=AlwaysAllow

C.--anonymous-auth=false

D.--disable-anonymous=true

AnswerC

Setting `--anonymous-auth=false` on the kube-apiserver forces every request to present valid credentials, rejecting unauthenticated calls to health endpoints such as `/healthz` and `/livez`. This directly satisfies the auditor's requirement to disable anonymous access, since the flag governs whether requests lacking authentication are treated as the `system:anonymous` user.

Why this answer

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.

Exam trap

The trap here is confusing the kube-apiserver flag --anonymous-auth with the kubelet's authentication.anonymous.enabled setting, or inventing plausible-sounding flags like --disable-anonymous that don't exist.

How to eliminate wrong answers

Option A is wrong because --secure-port=0 disables the HTTPS serving port entirely, which would break all API access rather than just anonymous requests. Option B is wrong because --authorization-mode=AlwaysAllow is the opposite of what's needed — it permits every authenticated (and anonymous) request, worsening the exposure. Option D is wrong because --disable-anonymous is not a real kube-apiserver flag; the correct flag is --anonymous-auth.

Practice this question →

Multi-Selectmedium

Which TWO of the following methods can be used to authenticate users or systems against the Kubernetes API server? (Choose TWO)

Select 2 answers

A.X.509 client certificates validated by the API server CA.

B.Unencrypted HTTP basic auth files with default passwords.

C.Anonymous packet sniffing via kube-proxy.

D.OpenID Connect (OIDC) tokens issued by an external identity provider.

E.Direct root SSH access to etcd nodes.

AnswersA, D

X.509 client certificates satisfy the stem's requirement for a native API server authentication method. The API server validates the certificate against its configured certificate authority, then maps the subject's common name to a user and organisation fields to groups. This operates without external identity providers, unlike OpenID Connect or webhook token authentication.

Why this answer

Option A is correct because the Kubernetes API server natively supports X.509 client certificate authentication: when a client presents a certificate signed by the cluster CA (configured via --client-ca-file), the API server validates it and maps the certificate's CN to a user and O to groups. Option D is correct because the API server can be configured with OIDC flags (--oidc-issuer-url, --oidc-client-id, --oidc-username-claim) to accept ID tokens issued by an external identity provider, authenticating users via the id_token JWT. Option B is wrong because basic auth with static password files is deprecated, disabled by default, and insecure, not a recommended authentication method.

Option C is wrong because kube-proxy handles service traffic routing, not authentication, and packet sniffing is not an authentication mechanism. Option E is wrong because SSH access to etcd nodes is infrastructure access, not an authentication method against the Kubernetes API server.

Exam trap

KCSA often tests whether candidates confuse authentication (who you are) with authorization (what you can do) or with infrastructure access — options like SSH to etcd or kube-proxy sniffing are distractors that sound security-related but have no role in API server authentication.

Practice this question →

MCQeasy

Which Kubernetes control plane component runs controllers that handle routine tasks such as replicating pods and managing service accounts?

A.CoreDNS

B.kube-controller-manager

C.etcd

D.kube-proxy

AnswerB

kube-controller-manager runs the built-in controllers, including the ReplicaSet controller that maintains desired pod counts and the service account controller that creates default tokens. It satisfies the stem's requirement for routine replication and service account management.

Why this answer

The kube-controller-manager is the control plane component that runs the built-in controllers — including the ReplicaSet controller (which maintains desired pod replica counts), the ServiceAccount controller (which creates default service accounts and tokens), and the Node, Endpoint, and Namespace controllers. It continuously reconciles observed cluster state with the desired state declared in the API server.

Exam trap

KCSA often tests component-role confusion — candidates mix up etcd (storage), kube-proxy (networking), and kube-controller-manager (reconciliation), picking the component that 'sounds' like it manages things.

How to eliminate wrong answers

Option A is wrong because CoreDNS is a cluster DNS add-on that resolves service names to ClusterIPs; it performs no controller reconciliation. Option C is wrong because etcd is the distributed key-value store that persists all cluster state — it stores data but does not run controllers. Option D is wrong because kube-proxy is a per-node network component that implements Service load balancing via iptables/IPVS rules, not a control plane controller.

Practice this question →

Multi-Selectmedium

Which THREE of the following tasks are performed by the Kubernetes control plane's kube-controller-manager? (Choose THREE)

Select 3 answers

A.Managing node lifecycle status and detecting node failures.

B.Maintaining desired pod replica counts via ReplicaSets.

C.Running container workloads directly on worker node operating systems.

D.Generating and managing ServiceAccount tokens and default namespace tokens.

E.Configuring iptables and IPVS rules for Kubernetes Services on nodes.

AnswersA, B, D

The node controller within kube-controller-manager monitors node health, applies taints and evicts Pods when nodes become unreachable. This node lifecycle and failure detection duty is one of its core responsibilities, matching the stem's requested control plane task.

Why this answer

The kube-controller-manager runs a set of control loops, and among them the node lifecycle controller (A) monitors node health, applies taints like node.kubernetes.io/not-ready, and detects node failures, which is exactly the node lifecycle status management described. The ReplicaSet controller (B) is a core controller inside kube-controller-manager that continuously reconciles the actual number of pod replicas with the desired count specified in a ReplicaSet, so it maintains desired pod replica counts. The ServiceAccount and token controllers (D) are also part of kube-controller-manager; they create default ServiceAccounts and generate/manage ServiceAccount tokens (and the default namespace token) for pods to authenticate to the API server.

Option C is wrong because running container workloads on worker nodes is the job of the kubelet and container runtime (e.g., containerd/CRI-O), not the control plane. Option E is wrong because iptables/IPVS rules for Services are programmed by kube-proxy on each node, not by kube-controller-manager.

Exam trap

KCSA often tests the division of responsibilities between control plane components, and candidates may incorrectly attribute node-level networking (kube-proxy) or container execution (kubelet/CRI) to the kube-controller-manager.

Practice this question →

Multi-Selecteasy

Which TWO of the following are core security hardening best practices for the Kubernetes API server? (Choose TWO)

Select 2 answers

A.Ensure the insecure port (--insecure-port) is disabled or set to 0.

B.Configure the API server to use HTTP instead of HTTPS for performance.

C.Store all kubeconfig credentials in public ConfigMaps.

D.Grant cluster-admin permissions to all authenticated users by default.

E.Disable anonymous authentication by setting --anonymous-auth=false.

AnswersA, E

Disabling `--insecure-port` closes the unauthenticated, unencrypted HTTP listener that otherwise bypasses TLS and authentication entirely, exposing the API server to anonymous requests. Setting it to 0 satisfies the hardening requirement by forcing all traffic through the secure port, where authentication and authorisation controls apply.

Why this answer

Option A is correct because the API server's insecure port (--insecure-port) serves unauthenticated, unencrypted HTTP traffic, so setting it to 0 (or disabling it) is a fundamental CIS Kubernetes Benchmark hardening step that forces all communication through the authenticated, TLS-protected secure port (default 6443). Option E is correct because anonymous authentication allows unauthenticated requests to reach the API server and be evaluated as the system:anonymous user; setting --anonymous-auth=false ensures every request must present valid credentials, preventing unauthenticated access and information disclosure. Option B is wrong because HTTP would remove TLS encryption and client authentication, weakening rather than hardening the API server.

Option C is wrong because kubeconfig files contain credentials and certificates, and storing them in public ConfigMaps would expose cluster access to anyone who can read the ConfigMap. Option D is wrong because granting cluster-admin to all authenticated users violates least privilege and would give every account full control of the cluster.

Exam trap

KCSA often tests whether candidates know that anonymous auth and the insecure port are separate controls — the trap is picking only one or confusing them with authorization settings like RBAC, when both authentication-layer flags must be disabled for a hardened API server.

Practice this question →

MCQhard

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?

A.--min-tls=1.3

B.--tls-min-version=VersionTLS13

C.--cipher-suites=TLS_AES_256_GCM_SHA384

D.--ssl-version=TLSv3

AnswerB

The --tls-min-version flag directly sets the floor for negotiated TLS versions on the API server's secure port. Specifying VersionTLS13 rejects any client offering TLS 1.2 or lower, satisfying the audit requirement to enforce TLS 1.3 as the minimum permitted version.

Why this answer

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.

Exam trap

KCSA often tests the exact flag name and value syntax for TLS version enforcement, with distractors using plausible but invalid flags like `--min-tls` or `--ssl-version`.

How to eliminate wrong answers

Option A is wrong because `--min-tls` is not a valid kube-apiserver flag; the correct flag is `--tls-min-version`. Option C is wrong because `--cipher-suites` specifies allowed cipher suites, not the TLS version; also, TLS 1.3 cipher suites are not configurable via this flag in Go. Option D is wrong because `--ssl-version` is not a valid flag, and 'TLSv3' is not a real TLS version (TLS 1.3 is the latest).

Practice this question →

MCQhard

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?

A.Enable the kubelet insecure-port flag.

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

C.Disable the API server proxy subresource.

D.Set authentication.anonymous.enabled: false and authorization.mode: Webhook in the kubelet configuration file.

AnswerD

Disabling anonymous authentication forces credentials on port 10250, and Webhook authorization delegates each request to the API server's RBAC evaluation. Together they eliminate unauthenticated command execution, satisfying the stem's requirement to restrict both kubelet authentication and authorization.

Why this answer

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.

Exam trap

The trap is that candidates may think disabling the API server proxy subresource (option C) secures the kubelet, but the kubelet's HTTPS port is directly accessible and must be secured independently.

How to eliminate wrong answers

Option A is wrong because enabling the kubelet insecure-port flag (or leaving it enabled) exposes an unauthenticated HTTP endpoint, which is the opposite of restricting access. Option B is wrong because authorization.mode: AlwaysAllow permits all requests without any authorization checks, which would allow the unauthenticated access to continue. Option C is wrong because disabling the API server proxy subresource does not affect direct access to the kubelet's HTTPS port; it only blocks the API server's proxy functionality, leaving the kubelet exposed.

Practice this question →

Multi-Selectmedium

Which THREE of the following practices should be implemented to secure etcd in a production Kubernetes deployment? (Choose THREE)

Select 3 answers

A.Disable TLS verification to simplify certificate rotation.

B.Enable client certificate authentication using --client-cert-auth=true.

C.Expose etcd on a public internet IP address without authentication for easy monitoring.

D.Encrypt data at rest in etcd using an EncryptionConfiguration file.

E.Enable peer-to-peer encryption and mutual TLS using peer certificate flags.

AnswersB, D, E

Enabling `--client-cert-auth=true` forces every etcd client to present a certificate signed by the trusted CA, blocking unauthenticated access to the datastore. This satisfies the stem's requirement to secure etcd by ensuring only verified API server and operator identities can read or write cluster state.

Why this answer

Option B is correct because enabling client certificate authentication with --client-cert-auth=true forces every etcd client (kube-apiserver, etcdctl, etc.) to present a valid TLS client certificate signed by the trusted CA, preventing unauthenticated access to the etcd API. Option D is correct because encrypting data at rest via an EncryptionConfiguration file (referenced with --encryption-provider-config) protects Secrets and other sensitive objects stored in etcd from being read in plaintext if the disk or backup is compromised. Option E is correct because etcd peer traffic carries cluster state and raft data, so enabling peer-to-peer encryption with mutual TLS using flags such as --peer-cert-file, --peer-key-file, --peer-trusted-ca-file, and --peer-client-cert-auth=true ensures only authenticated cluster members can exchange data.

Option A is not acceptable because disabling TLS verification (e.g., --insecure-skip-tls-verify) removes server identity validation and exposes etcd to man-in-the-middle attacks, and option C is not acceptable because exposing etcd on a public IP without authentication allows anyone to read or modify the entire cluster's state.

Exam trap

KCSA often tests whether candidates recognize that 'disable TLS verification' and 'expose etcd publicly' are always wrong, while the correct trio combines client cert auth, encryption at rest, and peer mTLS — a classic 'choose three' pattern.

Practice this question →

Multi-Selectmedium

Which THREE of the following practices should be followed when configuring Kubernetes audit logging? (Choose THREE)

Select 3 answers

A.Store audit logs in unencrypted public ConfigMaps.

B.Disable audit logging entirely to maximize API server performance.

C.Monitor audit logs regularly for suspicious authentication failures or privilege escalations.

D.Store audit logs in a secure location with restricted file permissions on the host or ship them to a SIEM.

E.Define an explicit audit policy file detailing which log levels and events to capture.

AnswersC, D, E

Regular monitoring of audit logs detects suspicious authentication failures and privilege escalations, turning recorded events into actionable security signal. This satisfies the practice requirement because collecting audit data without review provides no detection value; anomalies must be identified and investigated promptly.

Why this answer

Option C is correct because Kubernetes audit logs record authentication attempts, RBAC authorization decisions, and privileged operations, so regularly monitoring them is essential to detect brute-force authentication failures, unauthorized privilege escalations, and anomalous API activity. Option D is correct because audit logs can contain sensitive data such as request bodies, tokens, and Secret contents, so they must be written to a protected location with restricted file permissions (for example, a log file readable only by root) or forwarded to a centralized SIEM with appropriate access controls and retention. Option E is correct because audit logging is driven by an audit policy file passed to the kube-apiserver via --audit-policy-file, which explicitly defines rules with levels such as None, Metadata, Request, and RequestResponse and specifies which resources, verbs, and namespaces are captured.

Option A is not appropriate because ConfigMaps are not a secure or intended storage mechanism for audit logs and exposing them unencrypted publicly would leak sensitive cluster data. Option B is not appropriate because disabling audit logging removes the accountability and forensic trail needed for security monitoring and compliance, and audit logging can be tuned via policy levels rather than turned off entirely.

Exam trap

KCSA often tests the trade-off between performance and security — candidates pick 'disable logging' for speed or 'store in ConfigMaps' for convenience, missing that audit logs are sensitive and mandatory for compliance.

Practice this question →

Multi-Selecteasy

Which TWO of the following tasks are handled by the kube-scheduler? (Choose TWO)

Select 2 answers

A.Generating X.509 client certificates for cluster bootstrapping.

B.Evaluating pending pods and selecting suitable worker nodes for placement.

C.Respecting node taints, tolerations, and affinity rules during scheduling.

D.Managing encryption keys inside the etcd database.

E.Executing container liveness probes inside running pods.

AnswersB, C

Evaluating pending pods and selecting suitable worker nodes is precisely the kube-scheduler's binding decision: it filters nodes via predicates, then ranks feasible ones by priority to satisfy resource requests, affinity and taints. This directly fulfils the stem's scheduling constraint, unlike controllers that merely create pods or kubelets that run them.

Why this answer

Option B is correct because the kube-scheduler's core function is to watch for newly created Pods that have no node assigned (Pending) and select a suitable node for them via its scheduling cycle. Option C is correct because during that scheduling cycle the kube-scheduler applies filtering and scoring predicates that include node taints/tolerations and node/pod affinity and anti-affinity rules to pick the best fit. Option A is not a scheduler task: X.509 client certificates for bootstrapping are issued by the kubelet's TLS bootstrap process via the CSR API and controller-manager signers.

Option D is not a scheduler task: etcd encryption keys are managed through the kube-apiserver's EncryptionConfiguration and kube-controller-manager, not the scheduler. Option E is not a scheduler task: liveness probes are executed by the kubelet on each node, not by the scheduler.

Exam trap

KCSA often tests the confusion between kube-scheduler and kubelet responsibilities, tricking candidates into selecting tasks like probe execution or certificate generation that belong to other components.

Practice this question →

Multi-Selecthard

Which TWO of the following scenarios represent severe security misconfigurations in a Kubernetes cluster control plane? (Choose TWO)

Select 2 answers

A.Etcd is configured with client certificate authentication and mTLS enabled.

B.Kubelet authorization mode is set to Webhook.

C.The API server is configured with --insecure-port pointing to an active HTTP listener.

D.The API server or kubelet has anonymous authentication enabled (--anonymous-auth=true).

E.Secrets are encrypted at rest using an EncryptionConfiguration file.

AnswersC, D

Enabling the insecure port exposes the API server over unauthenticated, unencrypted HTTP, letting anyone reach it bypass the TLS and authentication controls that secure port 6443 enforces. This directly satisfies the stem's control-plane misconfiguration criterion, since anonymous requests could read or modify cluster state without credentials.

Why this answer

Option C is correct because configuring the API server with --insecure-port to an active HTTP listener exposes an unauthenticated, unencrypted endpoint that bypasses TLS and normal authentication/authorization, which is a severe control-plane misconfiguration. Option D is correct because enabling anonymous authentication (--anonymous-auth=true) on the API server or kubelet allows unauthenticated requests to be treated as the system:anonymous user, potentially granting access to sensitive endpoints or cluster resources. Option A is not a misconfiguration because client certificate authentication with mTLS is a recommended secure configuration for etcd.

Option B is not a misconfiguration because Webhook authorization mode is a valid and secure kubelet authorization setting. Option E is not a misconfiguration because encrypting Secrets at rest with an EncryptionConfiguration file is a security best practice.

Exam trap

The trap is misidentifying secure configurations (like mTLS, Webhook, encryption at rest) as misconfigurations, or not recognizing that anonymous auth and insecure port are dangerous.

Practice this question →

MCQhard

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?

A.--data-encryption-secret

B.--encryption-config-path

C.--encryption-provider-config

D.--etcd-key-file

AnswerC

The `--encryption-provider-config` flag on the kube-apiserver accepts the path to the EncryptionConfiguration file, enabling envelope encryption of etcd data at rest. Without it, the API server ignores your custom key configuration entirely, so secrets persist unencrypted on disk — failing the regulated cluster's at-rest encryption requirement.

Why this answer

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.

Exam trap

KCSA often tests the exact spelling of the kube-apiserver encryption flag, luring candidates toward plausible-sounding but nonexistent names like --encryption-config-path or --data-encryption-secret.

How to eliminate wrong answers

Option A is wrong because --data-encryption-secret is not a real kube-apiserver flag; it conflates the concept of a secret key with a nonexistent CLI option. Option B is wrong because --encryption-config-path is a fabricated flag name; the actual flag uses 'provider' not 'path' in its name. Option D is wrong because --etcd-key-file is not a valid kube-apiserver flag — etcd TLS client key flags are named --etcd-certfile/--etcd-keyfile (no hyphen between key and file), and even those control TLS to etcd, not at-rest encryption of stored objects.

Practice this question →

Multi-Selecthard

Which TWO of the following are valid ways to harden etcd against unauthorized access and data corruption? (Choose TWO)

Select 2 answers

A.Expose etcd directly over unencrypted HTTP on port 2379.

B.Disable client certificate verification to allow unrestricted access.

C.Require mutual TLS (mTLS) for all client and peer connections.

D.Take regular encrypted snapshots using etcdctl snapshot save.

E.Grant public anonymous write access to the etcd raft log.

AnswersC, D

Mutual TLS requires both client and peer connections to present valid certificates, so only authenticated etcd members and authorised clients can read or write data. This satisfies the hardening requirement by preventing unauthorised access and tampering with cluster state.

Why this answer

Option C is correct because requiring mutual TLS (mTLS) for all client and peer connections ensures that both ends of every etcd connection present valid certificates, so only authenticated clients and peers can read or write keys and participate in raft consensus, preventing unauthorized access. Option D is correct because taking regular encrypted snapshots with etcdctl snapshot save (typically combined with encryption at rest or encrypting the snapshot file) preserves a recoverable copy of the datastore, allowing restoration after data corruption or compromise. Option A is wrong because exposing etcd over unencrypted HTTP on port 2379 sends credentials and data in cleartext and is exactly the insecure default that hardening must avoid.

Option B is wrong because disabling client certificate verification removes authentication entirely, allowing unrestricted access. Option E is wrong because granting public anonymous write access to the raft log lets anyone corrupt cluster state and violates the principle of least privilege.

Exam trap

KCSA often tests whether candidates recognize insecure etcd configurations; the trap is choosing options that sound like convenience features but actually weaken security, such as disabling certificate verification.

Practice this question →

Multi-Selecteasy

Which TWO of the following actions are risks associated with leaving the Kubernetes API server's insecure port enabled? (Choose TWO)

Select 2 answers

A.Enforcement of strict TLS 1.3 encryption on all connections.

B.Complete bypass of all authentication mechanisms.

C.Mandatory mutual TLS client certificate verification.

D.Automatic activation of etcd encryption at rest.

E.Complete bypass of all authorization checks (RBAC).

AnswersB, E

The insecure port serves requests over plain HTTP with no authentication or authorisation checks applied, so any client reaching it acts as an anonymous, fully privileged user. This directly satisfies the stem's constraint: it grants complete bypass of all authentication mechanisms, exposing the cluster to unauthenticated API operations.

Why this answer

The insecure port (historically --insecure-port, default 8080) on the Kubernetes API server serves requests over plain HTTP with no TLS, and by design it does not perform any authentication, so option B is correct: any client that can reach that port is treated as an anonymous, unauthenticated user. Because requests arriving on the insecure port are also not subjected to authorization checks, option E is correct: the usual RBAC evaluation is skipped, effectively granting the caller full access to the API as if they were an administrator. Options A and C are wrong because TLS 1.3 enforcement and mutual TLS client certificate verification are properties of the secure port (6443), not the insecure one, which uses no encryption or client certs at all.

Option D is wrong because etcd encryption at rest is configured separately via EncryptionConfiguration on the kube-apiserver and is never automatically activated by the insecure port.

Exam trap

The trap is picking TLS-related options (A or C) because the word 'insecure' suggests weak encryption; in reality the insecure port has no TLS and no authN/authZ, so the correct risks are complete bypass of both.

Practice this question →

Multi-Selecteasy

Which TWO of the following files or directories on a control plane node contain critical static pod manifests for core components? (Choose TWO)

Select 2 answers

A./etc/kubernetes/manifests/etcd.yaml

B./var/lib/kubelet/config.yaml

C./etc/default/kube-proxy

D.~/.kube/config

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

AnswersA, E

Static pod manifests for control plane components live in /etc/kubernetes/manifests, and etcd.yaml defines the etcd static pod. This file contains the arguments and configuration for the cluster datastore, making it a critical manifest on control plane nodes.

Why this answer

Option A is correct because /etc/kubernetes/manifests/etcd.yaml is the static pod manifest that the kubelet on a control plane node watches and instantiates to run the etcd datastore as a static pod. Option E is correct because /etc/kubernetes/manifests/kube-apiserver.yaml is likewise a static pod manifest in the kubelet's configured staticPodPath, used to launch the kube-apiserver as a static pod. Option B is incorrect because /var/lib/kubelet/config.yaml is the kubelet's own configuration file (KubeletConfiguration), not a pod manifest.

Option C is incorrect because /etc/default/kube-proxy is a service environment/defaults file for kube-proxy, not a static pod manifest. Option D is incorrect because ~/.kube/config is the client kubeconfig file used by kubectl to authenticate to the cluster, not a static pod manifest.

Exam trap

KCSA often tests the confusion between kubelet configuration files (like /var/lib/kubelet/config.yaml) and the static pod manifest directory (/etc/kubernetes/manifests), or between client-side kubeconfig (~/.kube/config) and server-side static pod definitions.

Practice this question →

Multi-Selectmedium

Which TWO of the following metrics or health endpoints should be protected against unauthenticated access on control plane nodes? (Choose TWO)

Select 2 answers

A.Container runtime image download caches.

B.Etcd metrics and health endpoints (typically port 2379/2380).

C.Public load balancer health check probe targets configured for external routing.

D.CoreDNS internal DNS query forwarding ports.

E.Kubelet metrics and operational endpoints (port 10250).

AnswersB, E

Etcd's 2379 client and 2380 peer ports expose the full keyspace, including Secrets, and permit writes. Protecting them satisfies the stem's constraint because unauthenticated access to these metrics and health endpoints on control plane nodes yields direct cluster takeover, far exceeding mere information disclosure.

Why this answer

Option B is correct because etcd exposes sensitive metrics and health endpoints on ports 2379 (client) and 2380 (peer), and unauthenticated access to these can leak cluster state, keys, and allow disruptive operations, so they must be protected on control plane nodes. Option E is correct because the kubelet serves metrics and operational endpoints on port 10250, and unauthenticated access there can expose pod specs, logs, and even permit command execution via the kubelet API, making authentication and authorization essential. Option A is not a control plane health or metrics endpoint; container image caches are local storage artifacts, not network services requiring this protection.

Option C refers to external load balancer probe targets, which are typically intentionally reachable and are not control plane node metrics/health endpoints. Option D concerns CoreDNS internal DNS forwarding ports, which are part of cluster DNS service traffic rather than control plane node metrics or health endpoints.

Exam trap

KCSA often tests the specific ports and endpoints that are sensitive, and candidates may overlook kubelet (10250) or etcd (2379/2380) in favor of less critical components.

Practice this question →

MCQmedium

A security engineer is reviewing a Kubernetes cluster and finds that the API server is using the default admission control chain without any webhook-based admission plugins enabled. The engineer wants to ensure that all pod creation requests are validated against a custom policy that prevents privileged containers. Which admission plugin should be enabled and configured to achieve this?

A.NodeRestriction

B.MutatingAdmissionWebhook

C.ValidatingAdmissionWebhook

D.PodSecurityPolicy

AnswerC

ValidatingAdmissionWebhook allows the API server to send admission requests to an external HTTP callback that can validate objects against custom policies, such as blocking privileged containers. It is configured via a ValidatingWebhookConfiguration resource, and it can reject requests that violate the policy. This is the correct mechanism for enforcing custom validation logic without modifying Kubernetes source code.

Why this answer

To enforce custom validation policies such as blocking privileged containers, the API server must be able to call an external webhook that evaluates the request. ValidatingAdmissionWebhook enables this by forwarding admission requests to a configured HTTP endpoint, which can then allow or deny based on arbitrary logic. This is the standard extension point for policy enforcement in Kubernetes, often used by tools like Open Policy Agent Gatekeeper.

Exam trap

The trap here is assuming that PodSecurityPolicy is still available and can be used for pod security enforcement, when it has been removed in recent Kubernetes versions.

Practice this question →

MCQmedium

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?

A.--etcd-encryption-key

B.--secrets-encryption-enabled

C.--encryption-provider-config

D.--etcd-ca-file

AnswerC

The `--encryption-provider-config` flag points the API server to an EncryptionConfiguration file, which defines the providers (such as `aescbc` or KMS v2) used to encrypt Secret resources before they are written to etcd. This directly satisfies the requirement for encryption at rest within etcd, unlike flags governing transport or authorisation.

Why this answer

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.

Exam trap

KCSA often tests whether candidates invent plausible-sounding flag names, so the trap is choosing a boolean-sounding flag like --secrets-encryption-enabled instead of the actual file-path flag --encryption-provider-config.

How to eliminate wrong answers

Option A is wrong because --etcd-encryption-key is not a real kube-apiserver flag; encryption keys are defined inside the EncryptionConfiguration file referenced by --encryption-provider-config. Option B is wrong because --secrets-encryption-enabled does not exist — there is no boolean toggle for secret encryption; you must supply a provider config. Option D is wrong because --etcd-ca-file configures the CA certificate used to verify the etcd server's TLS identity, which is unrelated to at-rest encryption of secret data.

Practice this question →

Multi-Selecthard

Which THREE of the following mechanisms are used by the Kubernetes API server to authorize requests after authentication succeeds? (Choose THREE)

Select 3 answers

A.RBAC (Role-Based Access Control) authorizer.

B.Node authorizer for restricting kubelet operations.

C.Etcd consensus authorizer.

D.Kube-proxy IPVS routing authorizer.

E.Webhook authorizer for external authorization evaluation.

AnswersA, B, E

The RBAC authorizer evaluates RoleBindings and ClusterRoleBindings to decide whether an authenticated identity may perform a requested verb on a resource. It is one of the API server's built-in authorisation modes, satisfying the requirement for post-authentication access control.

Why this answer

The Kubernetes API server supports multiple authorization modes that are evaluated in order after authentication: RBAC (A) grants or denies access based on Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings, making it the standard mechanism for user and service account permissions. The Node authorizer (B) is a specialized authorizer that restricts what kubelets can do, allowing each node to access only the resources (such as its own Pods, Secrets, and ConfigMaps) needed to run its workloads. The Webhook authorizer (E) sends SubjectAccessReview requests to an external HTTP service for authorization decisions, enabling integration with third-party policy engines like OPA/Gatekeeper.

Etcd consensus authorizer (C) does not exist; etcd is the backing datastore and has no role in authorizing API requests. Kube-proxy IPVS routing authorizer (D) is fictitious; kube-proxy implements Service load balancing via iptables or IPVS but is not an authorization mechanism.

Exam trap

KCSA often tests the distinction between authentication, authorization, and admission control, and candidates may mistakenly include etcd or kube-proxy as authorizers because they are core components, but they do not perform authorization.

Practice this question →

Multi-Selecthard

Which TWO of the following mechanisms help secure the kubelet API from unauthorized access and container inspection? (Choose TWO)

Select 2 answers

A.Enabling Webhook authorization mode so kubelet requests are validated against API server RBAC.

B.Removing all TLS certificates from the kubelet configuration.

C.Setting kubelet authorization mode to AlwaysAllow.

D.Disabling anonymous authentication on the kubelet.

E.Enabling the kubelet read-only port 10255.

AnswersA, D

Webhook authorization makes the kubelet call the API server's SubjectAccessReview endpoint for each request, so cluster RBAC policies govern who may query the kubelet API. This centralises access control, preventing unauthorised container inspection via direct kubelet connections.

Why this answer

Option A is correct because setting the kubelet's authorization mode to Webhook makes the kubelet send SubjectAccessReview requests to the API server, so access decisions are evaluated against API server RBAC policies rather than being granted blindly. Option D is correct because disabling anonymous authentication (--anonymous-auth=false) forces unauthenticated requests to the kubelet's HTTPS endpoint to be rejected with 401, preventing anonymous users from querying endpoints like /pods that could expose container details. Option B is wrong because removing TLS certificates would break kubelet authentication and encryption, making the API less secure, not more.

Option C is wrong because AlwaysAllow authorizes every request without any check, which is the opposite of securing the kubelet. Option E is wrong because the read-only port 10255 serves unauthenticated, unencrypted data and should be disabled, not enabled.

Exam trap

The trap is confusing authentication and authorization mechanisms, or thinking that AlwaysAllow or the read-only port improve security, when they actually weaken it.

Practice this question →

MCQeasy

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

A.In the directory specified by staticPodPath in the kubelet configuration file (default /etc/kubernetes/manifests).

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

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

D.In the kube-system namespace as standard Deployment objects.

AnswerA

The kubelet watches the directory named by staticPodPath in its configuration file, by default /etc/kubernetes/manifests, and creates pods from any manifests placed there. This satisfies the stem's requirement for automatic creation and management without the API server, since the kubelet reads local files directly rather than relying on control plane scheduling.

Why this answer

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.

Exam trap

KCSA often tests whether candidates confuse static pods with standard Deployments or DaemonSets, or assume static pod definitions live in etcd rather than on the node's filesystem.

How to eliminate wrong answers

Option B is wrong because ~/.kube/config is a kubeconfig file containing cluster connection details and credentials, not pod manifests. Option C is wrong because static pods are not stored in etcd under a '/registry/staticpods' prefix — the kubelet creates a mirror pod in the API server for visibility, but the source of truth is the local manifest file. Option D is wrong because static pods are not Deployment objects and do not live in the kube-system namespace as Deployments; they are managed directly by the kubelet on the node.

Practice this question →

MCQhard

You are performing a security assessment on an existing Kubernetes cluster. You discover that the kubelet API permits users with valid service account tokens to read sensitive container environment variables and logs. How should you configure the kubelet authorization mode to prevent unauthorized token holders from reading arbitrary pod data?

A.Set kubelet authorization mode to Webhook so the API server evaluates RBAC permissions for kubelet requests.

B.Set kubelet authorization mode to AlwaysAllow.

C.Enable anonymous access on port 10250.

D.Disable the kubelet authentication certificate.

AnswerA

Webhook authorization makes the Kubelet delegate each request to the API server, which evaluates RBAC permissions for the requesting identity. Token holders then only read pod data their roles permit, rather than any pod on the node.

Why this answer

Setting the kubelet authorization mode to Webhook delegates authorization decisions to the API server, which evaluates RBAC policies for the requesting user or service account. This ensures that only identities with explicit RBAC permissions can access kubelet endpoints like /pods, /logs, or /exec. By default, kubelet may use AlwaysAllow, which grants full access to any authenticated user, including service account tokens, leading to the vulnerability described.

Exam trap

KCSA often tests the misconception that authentication alone is sufficient, but the trap is that authorization mode must be Webhook to enforce RBAC; AlwaysAllow is a dangerous default that many candidates overlook.

How to eliminate wrong answers

Option B is wrong because AlwaysAllow grants unrestricted access to all authenticated requests, which is the opposite of what is needed and would worsen the security issue. Option C is wrong because enabling anonymous access on port 10250 would allow unauthenticated users to access sensitive data, directly contradicting the goal. Option D is wrong because disabling kubelet authentication certificates would break the authentication mechanism entirely, potentially allowing unauthorized access or disrupting cluster operations.

Practice this question →

MCQeasy

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?

A.Store the administrative kubeconfig file in a public ConfigMap.

B.Configure the API server with --oidc-issuer-url and related flags to validate JSON Web Tokens issued by the IDP.

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

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

AnswerB

Configuring the API server with `--oidc-issuer-url` lets it validate JSON Web Tokens issued by the external identity provider, so the CI/CD pipeline authenticates with short-lived, federated credentials rather than embedded static tokens. This directly satisfies the requirement to use an existing external IDP without long-lived secrets.

Why this answer

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.

Exam trap

The trap is that candidates see 'external identity provider' and reach for basic auth or anonymous access as 'simple' options, missing that OIDC flags are the only mechanism that federates with an external IdP using short-lived JWTs.

How to eliminate wrong answers

Option A is wrong because storing an admin kubeconfig in a public ConfigMap exposes cluster-admin credentials to anyone who can read the ConfigMap, and ConfigMaps are not secret stores — this is a severe security anti-pattern. Option C is wrong because enabling anonymous requests (--anonymous-auth=true) grants unauthenticated access to the API server, and CIDR-based trust is spoofable and far too broad; anonymous requests should be disabled in production. Option D is wrong because --basic-auth-file uses static username/password credentials stored in a file, which are long-lived, not tied to an external IdP, and the basic auth mechanism is deprecated and disabled by default in modern Kubernetes.

Practice this question →

MCQhard

You are troubleshooting a secure etcd cluster where a new control plane node cannot join the cluster. The logs indicate a TLS handshake failure between etcd peers. Which etcd configuration flag specifies the trusted CA certificate used to verify peer certificates?

A.--trusted-ca-file

B.--peer-client-cert-auth

C.--peer-trusted-ca-file

D.--etcd-ca-file

AnswerC

The `--peer-trusted-ca-file` flag loads the CA bundle that etcd uses to validate certificates presented by peer nodes during mutual TLS. Since the stem describes a peer-to-peer TLS handshake failure, this flag directly satisfies the requirement for verifying peer certificates, unlike client-facing or server certificate flags.

Why this answer

etcd uses separate TLS configurations for client-facing and peer-to-peer traffic. The --peer-trusted-ca-file flag specifies the CA bundle that etcd uses to verify the certificates presented by its peer etcd members during mutual TLS handshakes. Since the failure is a peer TLS handshake, the peer-specific CA flag is the correct one to check and configure.

Exam trap

KCSA often tests the distinction between etcd's client TLS flags and peer TLS flags, so candidates must not confuse --trusted-ca-file (client) with --peer-trusted-ca-file (peer) when the symptom is a peer handshake failure.

How to eliminate wrong answers

Option A is wrong because --trusted-ca-file applies to client-facing TLS (verifying clients connecting to etcd's client port), not to peer-to-peer member communication. Option B is wrong because --peer-client-cert-auth is a boolean that enables requiring and verifying peer client certificates; it does not itself specify which CA to trust. Option D is wrong because --etcd-ca-file is not a standard etcd flag (it resembles kube-apiserver's --etcd-cafile, which is used by the API server, not by etcd itself).

Practice this question →

MCQeasy

When configuring the Kubernetes API server authorization modes, which mode evaluates requests against Kubernetes RBAC policies?

A.RBAC

B.Webhook

C.Node

D.AlwaysAllow

AnswerA

RBAC authorises requests by evaluating them against Role and ClusterRole bindings defined in Kubernetes RBAC policies, satisfying the stem's requirement for the mode that checks RBAC rules. Enabled via the API server's authorization-mode flag, it grants permissions based on subjects, verbs, resources and namespaces.

Why this answer

The RBAC authorization mode in the Kubernetes API server evaluates requests against Role-Based Access Control policies defined via Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. When enabled, the API server checks whether the requesting user or service account has a binding that grants the required verb on the target resource. RBAC is the standard, fine-grained authorization mechanism in modern Kubernetes clusters.

Exam trap

KCSA often tests the confusion between authentication and authorization modes, or between RBAC and external policy engines like Webhook, causing candidates to select Webhook when the question specifically asks about built-in Kubernetes RBAC evaluation.

How to eliminate wrong answers

Option B (Webhook) is wrong because Webhook mode delegates authorization decisions to an external HTTP service (e.g., OPA Gatekeeper), not to Kubernetes RBAC policies. Option C (Node) is wrong because Node mode is a special-purpose authorizer for kubelet requests, granting permissions based on the node's identity — it does not evaluate RBAC policies. Option D (AlwaysAllow) is wrong because AlwaysAllow permits all requests unconditionally, bypassing any policy evaluation entirely and is only suitable for testing.

Practice this question →

MCQeasy

Which component provides network routing and iptables/IPVS rule management across worker nodes for Kubernetes Services?

A.kube-scheduler

B.kube-apiserver

C.etcd

D.kube-proxy

AnswerD

kube-proxy runs on every worker node and programs iptables or IPVS rules to implement Service virtual IPs and load balancing. This satisfies the stem's routing and rule-management requirement, since kube-proxy is the component translating Service definitions into node-level packet-forwarding rules.

Why this answer

kube-proxy runs on every node and is responsible for programming iptables (or IPVS, or nftables in newer versions) rules that implement Kubernetes Service virtual IPs and load balancing to backend pods. It watches the API server for Service and EndpointSlice objects and translates them into node-local dataplane rules. Without kube-proxy (or a replacement like Cilium's kube-proxy replacement), ClusterIP and NodePort services would not function.

Exam trap

The trap is assuming the control plane (kube-apiserver, scheduler, etcd) handles Service networking; candidates must remember kube-proxy is a per-node dataplane agent, not a control-plane service.

How to eliminate wrong answers

Option A is wrong because kube-scheduler only decides which node a pod should run on; it does not touch network dataplane rules. Option B is wrong because kube-apiserver is the control-plane REST endpoint that stores and serves object state, not a dataplane component. Option C is wrong because etcd is the distributed key-value store backing the cluster state; it has no role in routing or iptables/IPVS programming.

Practice this question →

Multi-Selectmedium

Which THREE of the following steps are part of proper Kubernetes control plane certificate management? (Choose THREE)

Select 3 answers

A.Using a trusted Certificate Authority (CA) rather than self-signed certificates where possible.

B.Implementing regular certificate rotation before expiration.

C.Disabling TLS verification for all internal cluster components.

D.Securing private keys with strict file permissions (e.g., 600) on control plane nodes.

E.Storing all private keys in unencrypted public ConfigMaps.

AnswersA, B, D

Using a trusted Certificate Authority ensures control plane components validate each other through a shared trust anchor, rather than relying on self-signed certificates that complicate rotation and revocation. This satisfies the stem's requirement for proper certificate management by establishing verifiable identity across the API server, controller manager, and scheduler, reducing the risk of impersonation within the cluster.

Why this answer

Option A is correct because using a trusted Certificate Authority (CA) instead of self-signed certificates provides a verifiable chain of trust for control plane components such as kube-apiserver, kube-controller-manager, and kube-scheduler, reducing the risk of man-in-the-middle attacks. Option B is correct because Kubernetes control plane certificates have finite validity periods (commonly one year for kubeadm-managed clusters), and regular rotation before expiration—via commands like kubeadm certs renew or automated rotation—prevents cluster outages and API server unavailability. Option D is correct because private keys for control plane components must be protected with strict file permissions such as 600 (read/write only by owner) to prevent unauthorized access, which is a standard hardening practice for files like /etc/kubernetes/pki/apiserver.key.

Option C is not correct because disabling TLS verification for internal cluster components removes authentication and encryption guarantees, exposing the control plane to interception and spoofing rather than being a proper certificate management step. Option E is not correct because storing private keys in unencrypted public ConfigMaps exposes them to any user or process with read access to the API, violating key confidentiality and Kubernetes security best practices.

Exam trap

KCSA often tests whether candidates can spot security anti-patterns disguised as 'management' steps — the trap is selecting options that sound like certificate handling but actually weaken TLS or expose keys.

Practice this question →

MCQmedium

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?

A.The etcd WAL (Write-Ahead Log) files.

B.The kubelet container logs on worker nodes.

C.The kube-proxy packet capture logs.

D.API server audit logs configured via --audit-log-path.

AnswerD

Audit logging records every request to the API server, including authentication failures with source IP, user and response status. Configuring --audit-log-path writes these events to disk, giving the administrator the forensic trail needed to identify brute-force attempts against the API server.

Why this answer

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.

Exam trap

KCSA often tests the misconception that etcd logs or kubelet logs contain API authentication events, when only the API server audit log records them.

How to eliminate wrong answers

Option A is wrong because etcd WAL files contain the Raft log of key-value operations, not API authentication events; they are for etcd recovery, not security auditing. Option B is wrong because kubelet logs on worker nodes record container runtime and pod lifecycle events, not API server authentication attempts. Option C is wrong because kube-proxy does not produce packet capture logs; it manages iptables/IPVS rules for service routing.

Practice this question →

Multi-Selecthard

Which THREE of the following auditing or logging mechanisms should be configured on a secure Kubernetes control plane? (Choose THREE)

Select 3 answers

A.Kubernetes API server audit logging configured with an audit policy file.

B.Routing all cluster traffic through an unencrypted proxy log.

C.Kubelet system and container execution logs on worker nodes.

D.Disabling all log outputs to prevent disk space exhaustion.

E.Etcd audit and operational logging for database transactions and peer health.

AnswersA, C, E

The API server is the single entry point for all cluster requests, so audit logging with a policy file records who did what, when and from where. This satisfies the control-plane auditing requirement by capturing authentication, authorisation and resource-modification events for later forensic review.

Why this answer

Option A is correct because the Kubernetes API server audit logging, driven by an audit policy file (--audit-policy-file), records who did what, when, and where against the API server, which is essential for detecting unauthorized or anomalous control-plane actions. Option C is correct because kubelet system and container execution logs on worker nodes capture pod lifecycle events, container runtime activity, and node-level failures, providing the workload-side visibility needed to correlate with control-plane audit events. Option E is correct because etcd audit and operational logging records database transactions and peer health, which is critical since etcd stores all cluster state and secrets, and its integrity and quorum health directly determine control-plane security and availability.

Option B is not appropriate because routing all cluster traffic through an unencrypted proxy log exposes sensitive data and violates the requirement for encrypted, integrity-protected control-plane communications. Option D is not appropriate because disabling all log outputs destroys the audit trail and violates compliance and forensic requirements; disk exhaustion should instead be managed with log rotation, retention policies, and monitoring.

Exam trap

KCSA often tests whether candidates understand that security logging must be enabled across all control-plane components, so distractors that suggest disabling logs or using unencrypted proxies tempt candidates who prioritize performance over security.

Practice this question →

MCQhard

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?

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

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

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

D.Configure an audit policy file and pass its path to the API server via --audit-policy-file.

AnswerD

The API server records mutating and validating requests only when given an audit policy defining rules and levels, supplied through the --audit-policy-file flag. This satisfies the requirement to audit all such requests, since no policy means no audit events are generated.

Why this answer

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.

Exam trap

KCSA often tests the misconception that audit logging can be configured on kubelet or etcd, but only the API server handles admission control and audit policy.

How to eliminate wrong answers

Option A is wrong because the kubelet does not handle admission control or API server audit logging; its audit configuration is unrelated and would not capture API server admission requests. Option B is wrong because kube-proxy is a network proxy for service routing and has no audit mode or --audit-proxy flag; it cannot record API server requests. Option C is wrong because etcd logging only records etcd's internal operations, not the admission control requests made to the API server, and DEBUG level would not provide the required audit trail.

Practice this question →