Cluster Setup practice questions

During a cluster upgrade, the kubelet on a worker node fails to start after updating the kubelet binary. The kubelet logs show: 'failed to load bootstrap client certificate: open /var/lib/kubelet/pki/kubelet-client-current.pem: no such file or directory'. What is the most likely cause?

Trap 1: The kubelet's node IP has changed

A changed node IP does not cause a missing-file error. It typically surfaces as TLS certificate validation failure because the kubelet's client certificate contains the old IP in its SANs, or the API server cannot reach the new IP. The bootstrap kubeconfig file would still exist and load correctly, so the failure would be at the authentication/TLS layer, not during file reading.

Trap 2: The kubelet's certificate has expired

An expired client certificate produces an x509 verification error such as 'certificate has expired or is not yet valid' when the kubelet tries to authenticate to the API server. This error occurs after the kubelet has already read the kubeconfig and loaded the certificate, whereas the reported failure is about the bootstrap kubeconfig file being absent. Certificate expiration would not prevent the file loader from finding the bootstrap kubeconfig.

Trap 3: The kubelet is using an outdated kubeconfig

An outdated kubeconfig points to an old API server address or old certificate authority, causing connection refused, unknown authority, or Unauthorized responses. The kubeconfig file itself is present, so the kubelet would not emit a 'missing file' error; instead it would fail during connection setup or credential validation. This is a configuration mismatch, not a file absence.

A
The kubelet's node IP has changed
Why it fails: A changed node IP does not cause a missing-file error. It typically surfaces as TLS certificate validation failure because the kubelet's client certificate contains the old IP in its SANs, or the API server cannot reach the new IP. The bootstrap kubeconfig file would still exist and load correctly, so the failure would be at the authentication/TLS layer, not during file reading.
B
The kubelet's certificate has expired
Why it fails: An expired client certificate produces an x509 verification error such as 'certificate has expired or is not yet valid' when the kubelet tries to authenticate to the API server. This error occurs after the kubelet has already read the kubeconfig and loaded the certificate, whereas the reported failure is about the bootstrap kubeconfig file being absent. Certificate expiration would not prevent the file loader from finding the bootstrap kubeconfig.
C
The kubelet is using an outdated kubeconfig
Why it fails: An outdated kubeconfig points to an old API server address or old certificate authority, causing connection refused, unknown authority, or Unauthorized responses. The kubeconfig file itself is present, so the kubelet would not emit a 'missing file' error; instead it would fail during connection setup or credential validation. This is a configuration mismatch, not a file absence.
D
The bootstrap kubeconfig file is missing or misconfigured
The bootstrap kubeconfig is the initial credential file the kubelet uses to create a CertificateSigningRequest and obtain a client certificate. If this file is missing or misconfigured (e.g., wrong server URL or incorrect CA data), the kubelet cannot even start the bootstrap flow and reports that it cannot load the bootstrap kubeconfig. During cluster upgrades, this file is often regenerated or expected to be at a specific path like /etc/kubernetes/bootstrap-kubelet.conf; if not present, the kubelet fails immediately.

Question 2mediummulti select

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

Trap 1: Enable encryption at rest for etcd data

Encryption at rest for etcd protects the confidentiality of stored Kubernetes secrets and state by encrypting data on disk, but it does not authenticate or encrypt any network traffic between etcd peers or between the API server and etcd. The question asks about securing the etcd cluster's communication channels, not data persistence. While valuable, encrypting data at rest is unrelated to certifying the identities of etcd members and clients, which is what the two correct TLS-based options accomplish.

Trap 2: Configure RBAC on etcd

Kubernetes RBAC is an authorization layer for API objects and cannot be applied to etcd, which lives outside the Kubernetes API model; etcd uses its own authentication/authorization mechanisms, primarily mutual TLS certificate verification of clients and peers. Enabling 'RBAC on etcd' is not a valid control-plane hardening step, and even if etcd's internal user/role feature is enabled, it does not replace the requirement for TLS to encrypt and authenticate communication. The correct security layer for etcd is certificate-based mutual TLS, not a role-based access-control configuration.

Trap 3: Apply NetworkPolicies to etcd pods

NetworkPolicies are a Kubernetes resource that filters pod-to-pod traffic at the CNI layer, but etcd in a typical kubeadm or on-prem deployment runs as a static pod or a host process on the same control-plane node, not as a ReplicaSet-managed pod. Static pods are only represented by a mirror pod, and NetworkPolicies don't reliably govern traffic to host-network or host-based processes, making this ineffective. The de facto method to secure etcd network communication is mutual TLS at the application layer, independent of the pod network and policy enforcement.

A
Enable encryption at rest for etcd data
Why it fails: Encryption at rest for etcd protects the confidentiality of stored Kubernetes secrets and state by encrypting data on disk, but it does not authenticate or encrypt any network traffic between etcd peers or between the API server and etcd. The question asks about securing the etcd cluster's communication channels, not data persistence. While valuable, encrypting data at rest is unrelated to certifying the identities of etcd members and clients, which is what the two correct TLS-based options accomplish.
B
Configure RBAC on etcd
Why it fails: Kubernetes RBAC is an authorization layer for API objects and cannot be applied to etcd, which lives outside the Kubernetes API model; etcd uses its own authentication/authorization mechanisms, primarily mutual TLS certificate verification of clients and peers. Enabling 'RBAC on etcd' is not a valid control-plane hardening step, and even if etcd's internal user/role feature is enabled, it does not replace the requirement for TLS to encrypt and authenticate communication. The correct security layer for etcd is certificate-based mutual TLS, not a role-based access-control configuration.
C
Enable TLS with peer certificates for etcd member communication
Enabling TLS with peer certificates ensures that each etcd member presents a certificate signed by a trusted CA when communicating with other members, preventing unauthorized nodes from joining the cluster and protecting the Raft consensus data from eavesdropping. Peer certificates authenticate the member-to-member traffic used for leader election, log replication, and heartbeat, so an attacker cannot inject or alter cluster state. Together with client certificates, this creates a zero-trust network for the control plane's datastore.
D
Enable TLS with client certificates for etcd client communication
Enabling TLS with client certificates forces the API server to present a valid certificate and verify the etcd server's certificate, encrypting both requests and responses over HTTPS and preventing impersonation or man-in-the-middle attacks between the control plane and the data store. The kube-apiserver must be configured with --etcd-certfile and --etcd-keyfile, while etcd requires --cert-file and --key-file plus a CA to validate client certs. This is the standard requirement for securing the only direct path from the API server to etcd.
E
Apply NetworkPolicies to etcd pods
Why it fails: NetworkPolicies are a Kubernetes resource that filters pod-to-pod traffic at the CNI layer, but etcd in a typical kubeadm or on-prem deployment runs as a static pod or a host process on the same control-plane node, not as a ReplicaSet-managed pod. Static pods are only represented by a mirror pod, and NetworkPolicies don't reliably govern traffic to host-network or host-based processes, making this ineffective. The de facto method to secure etcd network communication is mutual TLS at the application layer, independent of the pod network and policy enforcement.

Question 3hardmulti select

Which THREE of the following are required when setting up a Kubernetes control plane with kubeadm for a production environment?

Trap 1: Specify --apiserver-advertise-address

The --apiserver-advertise-address is optional because kubeadm automatically detects the IP address of the default network interface on the node and uses it as the API server's advertised address. This flag is only required when the node has multiple network interfaces, or when you need to force a specific IP that differs from the auto-detected one — for example, to advertise a virtual IP or a secondary interface. Since the question asks about required settings for setup, this is not required and can be safely omitted in most standard single-interface environments.

Trap 2: Generate a bootstrap token with kubeadm token create

Generating a bootstrap token with `kubeadm token create` is not needed for `kubeadm init` because the init process automatically creates its own temporary token to use during certificate upload and for subsequent joins. Tokens are primarily used to authenticate additional nodes (workers or other control planes) during the `kubeadm join` step, not for initializing the first control plane component. Pre-creating a token is an optional step for automating join flows, but it is not a prerequisite for setting up the control plane itself.

A
Ensure the Kubernetes version is not downgraded
kubeadm enforces a minimum Kubernetes version and explicitly forbids downgrading the control plane. If you attempt to initialize, upgrade, or restore a cluster to an older version, kubeadm aborts because the API server, controller-manager, and scheduler must stay within the supported version skew. Downgrading a single control plane component can cause API server and kubelet version mismatches, breaking cluster compatibility and causing nodes to fail registration.
B
Specify --pod-network-cidr to define the pod network range
The --pod-network-cidr flag defines the IP address range from which pod subnets are allocated to each node, and it must be provided during kubeadm init because kube-controller-manager uses it to assign CIDRs to nodes. CNI plugins such as Calico or Flannel typically expect this range to match their own configuration; omitting it leaves the cluster without a valid pod network, so pods cannot communicate across nodes. Without an explicit CIDR, kubeadm may default to a range that conflicts with your existing infrastructure or the CNI's assumptions.
C
Specify --control-plane-endpoint for high availability
The --control-plane-endpoint argument is mandatory for a highly available (HA) control plane because it supplies a stable network address or DNS name that load balancers use to distribute traffic among multiple API server instances. During kubeadm init, kubeadm generates certificates and kubeconfig files that embed this endpoint, ensuring all nodes — including workers — reach the API server through that single address. Omitting it makes kubeadm initialize a single control plane node, so you cannot later add additional control plane nodes without breaking the initial configuration.
D
Specify --apiserver-advertise-address
Why it fails: The --apiserver-advertise-address is optional because kubeadm automatically detects the IP address of the default network interface on the node and uses it as the API server's advertised address. This flag is only required when the node has multiple network interfaces, or when you need to force a specific IP that differs from the auto-detected one — for example, to advertise a virtual IP or a secondary interface. Since the question asks about required settings for setup, this is not required and can be safely omitted in most standard single-interface environments.
E
Generate a bootstrap token with kubeadm token create
Why it fails: Generating a bootstrap token with `kubeadm token create` is not needed for `kubeadm init` because the init process automatically creates its own temporary token to use during certificate upload and for subsequent joins. Tokens are primarily used to authenticate additional nodes (workers or other control planes) during the `kubeadm join` step, not for initializing the first control plane component. Pre-creating a token is an optional step for automating join flows, but it is not a prerequisite for setting up the control plane itself.

Question 4hardmultiple choice

You are responsible for securing a multi-tenant Kubernetes cluster that uses kubeadm for bootstrapping. The cluster has three control plane nodes and five worker nodes, all running Ubuntu 22.04. A recent security scan discovered that the etcd data directory is not encrypted at rest. The cluster stores sensitive customer data in secrets. You plan to enable encryption at rest for etcd. You have already created an encryption configuration file and placed it at /etc/kubernetes/encryption-config.yaml. The cluster is currently running Kubernetes v1.28.0 with etcd v3.5.9. You need to ensure that all existing and new secrets are encrypted. You also want to minimize downtime. Which of the following steps should you take?

Trap 1: Edit the etcd configuration to use the encryption config file…

The etcd server does not consume or understand the Kubernetes encryption configuration file; that file is read only by the kube-apiserver. The API server encrypts objects before sending them to etcd and decrypts them on reads, so etcd itself never receives plaintext or a configuration for encryption. Modifying etcd's configuration to 'use' this file would change nothing because the encryption provider logic lives in the API server, not the datastore.

Trap 2: Add --experimental-encryption-provider-config=/etc/kubernetes/encryp…

The flag --experimental-encryption-provider-config was renamed to --encryption-provider-config in Kubernetes 1.13 and the experimental prefix is deprecated; the current API server will either ignore a legacy flag or fail to start depending on version. Also, a manual restart of the kubelet is unnecessary because the kubelet continuously watches the static pod manifests and automatically restarts the API server pod when the manifest changes. The correct action is to edit the kube-apiserver manifest and let the kubelet converge.

Trap 3: Move the etcd data directory to an encrypted filesystem using LUKS

Moving the etcd data directory onto a LUKS-encrypted filesystem encrypts the underlying block device, but it is a filesystem-level solution completely separate from Kubernetes' native encryption-at-rest mechanism. The EncryptionConfiguration object controls per-resource encryption using strong AES keys managed by the API server, integrates with key management systems, and provides auditability and key rotation. Filesystem encryption also leaves the API server sending plaintext over the network to etcd unless TLS is also used, whereas the API-server approach encrypts before the data leaves the process.

A
Edit the etcd configuration to use the encryption config file directly
Why it fails: The etcd server does not consume or understand the Kubernetes encryption configuration file; that file is read only by the kube-apiserver. The API server encrypts objects before sending them to etcd and decrypts them on reads, so etcd itself never receives plaintext or a configuration for encryption. Modifying etcd's configuration to 'use' this file would change nothing because the encryption provider logic lives in the API server, not the datastore.
B
Add --experimental-encryption-provider-config=/etc/kubernetes/encryption-config.yaml to the kube-apiserver manifest and restart the kubelet
Why it fails: The flag --experimental-encryption-provider-config was renamed to --encryption-provider-config in Kubernetes 1.13 and the experimental prefix is deprecated; the current API server will either ignore a legacy flag or fail to start depending on version. Also, a manual restart of the kubelet is unnecessary because the kubelet continuously watches the static pod manifests and automatically restarts the API server pod when the manifest changes. The correct action is to edit the kube-apiserver manifest and let the kubelet converge.
C
Move the etcd data directory to an encrypted filesystem using LUKS
Why it fails: Moving the etcd data directory onto a LUKS-encrypted filesystem encrypts the underlying block device, but it is a filesystem-level solution completely separate from Kubernetes' native encryption-at-rest mechanism. The EncryptionConfiguration object controls per-resource encryption using strong AES keys managed by the API server, integrates with key management systems, and provides auditability and key rotation. Filesystem encryption also leaves the API server sending plaintext over the network to etcd unless TLS is also used, whereas the API-server approach encrypts before the data leaves the process.
D
Add --encryption-provider-config=/etc/kubernetes/encryption-config.yaml to the kube-apiserver manifest, then kubelet will automatically restart the static pod
The --encryption-provider-config flag tells the kube-apiserver to load an EncryptionConfiguration file that defines how to encrypt resources (e.g., with aescbc or aesgcm providers) before writing to etcd and how to decrypt on read. Once the flag is added to the kube-apiserver's static pod manifest under /etc/kubernetes/manifests, the kubelet detects the changed manifest and automatically restarts the API server container, so no manual restart of the kubelet or systemctl command is needed.

Question 5mediummultiple choice

A CKS candidate is asked to verify that the kube-apiserver on a production cluster does not expose any insecure endpoints. The candidate runs 'kubectl get pods -n kube-system -l component=kube-apiserver -o yaml' and inspects the container command. Which flag value should the candidate confirm is NOT present in the kube-apiserver command line to ensure the insecure port is disabled?

Trap 1: --authorization-mode=Node,RBAC

The --authorization-mode flag controls which authorization modules are active; Node and RBAC are recommended settings for production. This flag has nothing to do with exposing an insecure HTTP port. Treating it as an insecure-port indicator confuses authorization configuration with transport security, so it is not the correct value to flag.

Trap 2: --insecure-port=0

Setting --insecure-port=0 actually disables the insecure port entirely, which is the desired secure state on modern Kubernetes clusters. Seeing this value in the command line is not a security problem; it confirms hardening. A candidate looking for something to flag would be mistaken to treat this as the insecure configuration, since zero means the port is off.

Trap 3: --secure-port=6443

The --secure-port flag defines the TLS-protected port that clients use for authenticated API access. A value of 6443 is the standard secure port and does not represent an insecure endpoint. Its presence is expected and required, so it should not be mistaken for the insecure configuration the candidate is trying to rule out.

A
--authorization-mode=Node,RBAC
Why it fails: The --authorization-mode flag controls which authorization modules are active; Node and RBAC are recommended settings for production. This flag has nothing to do with exposing an insecure HTTP port. Treating it as an insecure-port indicator confuses authorization configuration with transport security, so it is not the correct value to flag.
B
--insecure-port=0
Why it fails: Setting --insecure-port=0 actually disables the insecure port entirely, which is the desired secure state on modern Kubernetes clusters. Seeing this value in the command line is not a security problem; it confirms hardening. A candidate looking for something to flag would be mistaken to treat this as the insecure configuration, since zero means the port is off.
C
--secure-port=6443
Why it fails: The --secure-port flag defines the TLS-protected port that clients use for authenticated API access. A value of 6443 is the standard secure port and does not represent an insecure endpoint. Its presence is expected and required, so it should not be mistaken for the insecure configuration the candidate is trying to rule out.
D
--insecure-port=8080
The flag --insecure-port, when set to a nonzero value such as 8080, causes the kube-apiserver to serve unauthenticated and unencrypted requests on that port. That is the classic insecure endpoint. To confirm the insecure port is disabled, the candidate must verify this flag is absent or set to 0, never to 8080.

Question 6mediummulti select

A security engineer is reviewing a cluster's NetworkPolicy configuration to reduce lateral movement. The engineer wants to confirm that a default-deny posture is in place for a namespace called 'backend'. Which TWO actions should the engineer take to establish a default-deny for both ingress and egress traffic in that namespace? (Choose two.)

Trap 1: Create a NetworkPolicy with podSelector matching all Pods and…

An ingress rule allowing traffic from all namespaces explicitly permits inbound connections, which contradicts the default-deny goal. It also omits Egress from policyTypes, so outbound traffic remains unrestricted. This configuration increases exposure rather than reducing lateral movement, making it the opposite of what the engineer needs to implement.

Trap 2: Apply a podSelector that matches the label 'tier=backend' and set…

This policy only denies egress for Pods carrying the tier=backend label and says nothing about ingress. Pods without that label are unaffected, and inbound traffic is still allowed. It therefore fails to establish the required default-deny for both directions across the namespace, leaving the cluster exposed to lateral movement from other namespaces.

Trap 3: Set the namespace annotation…

There is no such namespace annotation in Kubernetes for enabling default-deny behavior. NetworkPolicy is a first-class API object, and enforcement is performed by the CNI plugin only when a NetworkPolicy selects the Pod. Relying on an invented annotation would leave the namespace completely unprotected, giving a false sense of security while no policy object exists.

A
Create a NetworkPolicy with podSelector matching all Pods and policyTypes Ingress only, plus an ingress rule allowing traffic from all namespaces.
Why it fails: An ingress rule allowing traffic from all namespaces explicitly permits inbound connections, which contradicts the default-deny goal. It also omits Egress from policyTypes, so outbound traffic remains unrestricted. This configuration increases exposure rather than reducing lateral movement, making it the opposite of what the engineer needs to implement.
B
Create two separate NetworkPolicy objects, one with policyTypes Ingress only and one with policyTypes Egress only, each using an empty podSelector and no rules.
Splitting the default-deny into an ingress-only policy and an egress-only policy achieves the same effect as a combined policy because NetworkPolicies are additive. Each policy independently denies its direction for all selected Pods. This approach is valid and often used for clarity, since operators can reason about ingress and egress rules separately when later adding exceptions.
C
Create a NetworkPolicy in the 'backend' namespace that selects all Pods with an empty podSelector and specifies policyTypes of Ingress and Egress with no ingress or egress rules.
A NetworkPolicy with an empty podSelector matches every Pod in the namespace, and listing Ingress and Egress in policyTypes while providing no allow rules denies all inbound and outbound traffic. This is the canonical default-deny pattern. It blocks lateral movement because no Pod in the namespace can initiate or receive traffic until a more permissive policy is added.
D
Apply a podSelector that matches the label 'tier=backend' and set policyTypes to Egress only, with no egress rules.
Why it fails: This policy only denies egress for Pods carrying the tier=backend label and says nothing about ingress. Pods without that label are unaffected, and inbound traffic is still allowed. It therefore fails to establish the required default-deny for both directions across the namespace, leaving the cluster exposed to lateral movement from other namespaces.
E
Set the namespace annotation 'network-policy.backend/default-deny=true' to instruct the CNI plugin to deny all traffic.
Why it fails: There is no such namespace annotation in Kubernetes for enabling default-deny behavior. NetworkPolicy is a first-class API object, and enforcement is performed by the CNI plugin only when a NetworkPolicy selects the Pod. Relying on an invented annotation would leave the namespace completely unprotected, giving a false sense of security while no policy object exists.

Question 7easymultiple choice

A Kubernetes administrator needs to verify that the kubelet is configured to use a secure TLS certificate for its API server. Which file should be checked for the kubelet's certificate authority and client certificate settings?

Trap 1: /etc/kubernetes/kubelet.conf

The /etc/kubernetes/kubelet.conf file is a kubeconfig file used by the kubelet to authenticate to the API server. It contains client certificate data for the kubelet's client identity, not the server TLS configuration for the kubelet's own API server. It does not hold the kubelet's serving certificate or CA settings.

Trap 2: /etc/kubernetes/pki/ca.crt

This file is the cluster's certificate authority certificate. While the kubelet may reference it, the file itself does not contain kubelet configuration settings. The kubelet's TLS options are specified in its configuration file, not in the CA certificate file.

Trap 3: /var/lib/kubelet/kubeadm-flags.env

This file contains command-line flags for the kubelet when managed by kubeadm. It may include flags like --config, but the detailed TLS settings are usually in the config file. It is not the primary place to verify certificate authority and client certificate configurations.

A
/etc/kubernetes/kubelet.conf
Why it fails: The /etc/kubernetes/kubelet.conf file is a kubeconfig file used by the kubelet to authenticate to the API server. It contains client certificate data for the kubelet's client identity, not the server TLS configuration for the kubelet's own API server. It does not hold the kubelet's serving certificate or CA settings.
B
/etc/kubernetes/pki/ca.crt
Why it fails: This file is the cluster's certificate authority certificate. While the kubelet may reference it, the file itself does not contain kubelet configuration settings. The kubelet's TLS options are specified in its configuration file, not in the CA certificate file.
C
/var/lib/kubelet/config.yaml
The kubelet's main configuration file is typically /var/lib/kubelet/config.yaml when using the KubeletConfiguration API. It contains fields such as authentication, authorization, and TLS settings, including the certificate authority and client certificate paths. Checking this file is the correct way to verify the kubelet's secure TLS configuration.
D
/var/lib/kubelet/kubeadm-flags.env
Why it fails: This file contains command-line flags for the kubelet when managed by kubeadm. It may include flags like --config, but the detailed TLS settings are usually in the config file. It is not the primary place to verify certificate authority and client certificate configurations.

Question 8easymultiple choice

A team needs to set up a highly available Kubernetes control plane across three availability zones. What is the minimum number of etcd members required to achieve fault tolerance against one zone failure?

Trap 1: 5

A 5-member control plane can tolerate two simultaneous failures while maintaining etcd quorum, but the question asks for the minimum required for high availability. Three nodes are sufficient to form a majority and provide HA; five adds unnecessary cost and operational overhead. Choosing 5 violates the 'minimum' constraint even though it is a valid HA configuration.

Trap 2: 1

A single control plane node cannot tolerate any failure because there is no redundant member to maintain etcd quorum; an etcd cluster with one member loses quorum entirely if that member goes down. High availability requires at least three nodes, so one is fundamentally inadequate. This option represents a single point of failure, not a highly available setup.

Trap 3: 7

A 7-member control plane can withstand up to three failures, but it is far above the minimum and creates performance drawbacks; each write must be replicated to a majority of seven nodes, increasing latency and network overhead. The question specifically asks for the minimum, and three already provides the required HA with one-failure tolerance. Extending to seven is not incorrect for HA, but it violates the 'minimum' criterion and can degrade etcd performance.

A
5
Why it fails: A 5-member control plane can tolerate two simultaneous failures while maintaining etcd quorum, but the question asks for the minimum required for high availability. Three nodes are sufficient to form a majority and provide HA; five adds unnecessary cost and operational overhead. Choosing 5 violates the 'minimum' constraint even though it is a valid HA configuration.
B
1
Why it fails: A single control plane node cannot tolerate any failure because there is no redundant member to maintain etcd quorum; an etcd cluster with one member loses quorum entirely if that member goes down. High availability requires at least three nodes, so one is fundamentally inadequate. This option represents a single point of failure, not a highly available setup.
C
3
Three control plane nodes are the minimum required for high availability because etcd quorum for a 3-node cluster is two, meaning the cluster can survive the loss of one node. With only two nodes, a single failure would leave one node and no majority, so three is the smallest odd number that provides fault tolerance. This is the standard recommendation for production Kubernetes control planes.
D
7
Why it fails: A 7-member control plane can withstand up to three failures, but it is far above the minimum and creates performance drawbacks; each write must be replicated to a majority of seven nodes, increasing latency and network overhead. The question specifically asks for the minimum, and three already provides the required HA with one-failure tolerance. Extending to seven is not incorrect for HA, but it violates the 'minimum' criterion and can degrade etcd performance.

Question 9mediummultiple choice

A security audit reveals that the kube-apiserver is using the default insecure port 8080 on a production cluster. Which is the most secure and recommended remediation?

Trap 1: Change the --insecure-port flag to 0

Setting --insecure-port=0 disables the HTTP listener on the kube-apiserver, but this alone does not guarantee that the API server is securely reachable. The control plane may still have the insecure port enabled via a separate bind address or default configuration, and without explicitly confirming --secure-port=6443 and its TLS settings, the remediation is incomplete. Therefore, while disabling the insecure port is a necessary step, it is insufficient as the 'most secure' fix.

Trap 2: Set --insecure-port=6443

Setting --insecure-port=6443 would expose the insecure, plaintext HTTP API on the default secure port, effectively replacing the TLS-protected endpoint with an unauthenticated one. This is critically dangerous because port 6443 is typically used for the secure API server, and doing so would allow unencrypted, unauthenticated access to the cluster, violating security best practices. The correct approach is to disable the insecure port entirely.

Trap 3: Set --secure-port=8080

Setting --secure-port=8080 reconfigures the TLS-serving port to 8080, but it does not disable the insecure port, which defaults to 8080 in some configurations. This can create a port conflict if the insecure listener is still active, or it may move the secure endpoint to a non-standard port without addressing the underlying plaintext listener. The most secure remediation must explicitly disable the insecure port (--insecure-port=0) and keep the secure port on its default 6443 with TLS, not just shift ports around.

A
Change the --insecure-port flag to 0
Why it fails: Setting --insecure-port=0 disables the HTTP listener on the kube-apiserver, but this alone does not guarantee that the API server is securely reachable. The control plane may still have the insecure port enabled via a separate bind address or default configuration, and without explicitly confirming --secure-port=6443 and its TLS settings, the remediation is incomplete. Therefore, while disabling the insecure port is a necessary step, it is insufficient as the 'most secure' fix.
B
Set --insecure-port=0 and ensure --secure-port=6443 is configured
Setting --insecure-port=0 disables the plaintext HTTP endpoint on the kube-apiserver, eliminating unauthenticated access. Simultaneously ensuring --secure-port=6443 is configured guarantees that all API communication is served over TLS on the standard secure port, using client certificate and token authentication. This combination is the recommended hardening measure per Kubernetes documentation.
C
Set --insecure-port=6443
Why it fails: Setting --insecure-port=6443 would expose the insecure, plaintext HTTP API on the default secure port, effectively replacing the TLS-protected endpoint with an unauthenticated one. This is critically dangerous because port 6443 is typically used for the secure API server, and doing so would allow unencrypted, unauthenticated access to the cluster, violating security best practices. The correct approach is to disable the insecure port entirely.
D
Set --secure-port=8080
Why it fails: Setting --secure-port=8080 reconfigures the TLS-serving port to 8080, but it does not disable the insecure port, which defaults to 8080 in some configurations. This can create a port conflict if the insecure listener is still active, or it may move the secure endpoint to a non-standard port without addressing the underlying plaintext listener. The most secure remediation must explicitly disable the insecure port (--insecure-port=0) and keep the secure port on its default 6443 with TLS, not just shift ports around.

Question 10easymultiple choice

A cluster is using kubeadm and the control plane components are running as static pods. Where are the static pod manifests for the API server located by default?

Trap 1: /var/lib/kubelet/

The /var/lib/kubelet/ directory is the kubelet's working directory, where it stores pod-related runtime data such as volumes, container logs, and plugin state. It is not a location from which the kubelet reads static pod manifests; the kubelet only monitors the static pod path configured via --pod-manifest-path or the staticPodPath in its configuration. Placing control plane YAML files here would have no effect, as the kubelet would not recognize them as pod definitions.

Trap 2: /etc/kubernetes/admin.conf

/etc/kubernetes/admin.conf is a kubeconfig file, not a directory for static pod manifests. It contains the client certificate, private key, and API server endpoint for the kubernetes-admin user, and is typically consumed by kubectl or other administrative tools to authenticate against the API server. The kubelet does not read this file when creating static pods, so modifying it or placing files there would have no impact on control plane pod definitions.

Trap 3: /etc/kubernetes/

/etc/kubernetes/ is the top-level configuration directory for Kubernetes, holding files like kubelet.conf, scheduler.conf, controller-manager.conf, and the pki subdirectory with certificates. Although this directory contains cluster configuration, the kubelet does not scan it for pod manifests; it only watches the manifests subdirectory within it. Therefore, placing YAML files directly under /etc/kubernetes/ would not cause the kubelet to launch any static pods, and it is distinct from the dedicated manifests path.

A
/var/lib/kubelet/
Why it fails: The /var/lib/kubelet/ directory is the kubelet's working directory, where it stores pod-related runtime data such as volumes, container logs, and plugin state. It is not a location from which the kubelet reads static pod manifests; the kubelet only monitors the static pod path configured via --pod-manifest-path or the staticPodPath in its configuration. Placing control plane YAML files here would have no effect, as the kubelet would not recognize them as pod definitions.
B
/etc/kubernetes/manifests/
/etc/kubernetes/manifests/ is the default static pod manifest directory in a kubeadm cluster. The kubelet watches this directory for YAML/JSON files and automatically creates and manages the pods they define, which is how the control plane components (kube-apiserver, kube-controller-manager, kube-scheduler, and etcd) are launched. This directory is the correct place for these manifests because the kubelet's staticPodPath is set to this location during kubeadm initialization, making it the source of truth for the control plane pods.
C
/etc/kubernetes/admin.conf
Why it fails: /etc/kubernetes/admin.conf is a kubeconfig file, not a directory for static pod manifests. It contains the client certificate, private key, and API server endpoint for the kubernetes-admin user, and is typically consumed by kubectl or other administrative tools to authenticate against the API server. The kubelet does not read this file when creating static pods, so modifying it or placing files there would have no impact on control plane pod definitions.
D
/etc/kubernetes/
Why it fails: /etc/kubernetes/ is the top-level configuration directory for Kubernetes, holding files like kubelet.conf, scheduler.conf, controller-manager.conf, and the pki subdirectory with certificates. Although this directory contains cluster configuration, the kubelet does not scan it for pod manifests; it only watches the manifests subdirectory within it. Therefore, placing YAML files directly under /etc/kubernetes/ would not cause the kubelet to launch any static pods, and it is distinct from the dedicated manifests path.

Question 11mediummultiple choice

A security team wants to ensure that all communication between the kubelet and the API server is encrypted. Which flag must be set on the kubelet to enforce this?

Trap 1: --tls-cert-file

The --tls-cert-file flag on the kubelet specifies the x509 certificate used to serve the kubelet's own HTTPS endpoints, such as /pods and /healthz. It does not influence how the kubelet authenticates itself when acting as a client to the API server. Client-side TLS for that connection is configured entirely by the kubeconfig file, including the server URL and credentials.

Trap 2: --node-status-update-frequency

The --node-status-update-frequency flag controls how often the kubelet posts node status and pod status updates to the API server. While these updates are part of kubelet-to-API-server traffic, the flag only changes the cadence of those updates, not the transport security. Encryption is determined by the TLS settings in the kubeconfig (e.g., an HTTPS server address) and the cluster's CA trust, so adjusting this flag has no impact on whether communication is encrypted.

Trap 3: --require-kubeconfig

The --require-kubeconfig flag is deprecated and only forces the kubelet to load a kubeconfig at startup, failing if none is present. It does not specify the server address, enable TLS, or enforce encryption; it simply guards against an insecure fallback to a local API server. In modern Kubernetes, this flag is effectively a no-op because the kubelet always requires a kubeconfig, and it cannot address the security team's goal of ensuring encrypted communication.

A
--tls-cert-file
Why it fails: The --tls-cert-file flag on the kubelet specifies the x509 certificate used to serve the kubelet's own HTTPS endpoints, such as /pods and /healthz. It does not influence how the kubelet authenticates itself when acting as a client to the API server. Client-side TLS for that connection is configured entirely by the kubeconfig file, including the server URL and credentials.
B
--node-status-update-frequency
Why it fails: The --node-status-update-frequency flag controls how often the kubelet posts node status and pod status updates to the API server. While these updates are part of kubelet-to-API-server traffic, the flag only changes the cadence of those updates, not the transport security. Encryption is determined by the TLS settings in the kubeconfig (e.g., an HTTPS server address) and the cluster's CA trust, so adjusting this flag has no impact on whether communication is encrypted.
C
--kubeconfig
The --kubeconfig flag is the correct mechanism because the kubeconfig file defines the API server endpoint (typically an HTTPS URL), the CA certificate used to verify the server, and the kubelet's client credentials for authentication. When the kubelet starts with --kubeconfig, it uses this file to establish a mutually authenticated, TLS-encrypted connection to the API server. Requiring a kubeconfig that points to the API server over HTTPS ensures all control-plane traffic from the kubelet is encrypted in transit.
D
--require-kubeconfig
Why it fails: The --require-kubeconfig flag is deprecated and only forces the kubelet to load a kubeconfig at startup, failing if none is present. It does not specify the server address, enable TLS, or enforce encryption; it simply guards against an insecure fallback to a local API server. In modern Kubernetes, this flag is effectively a no-op because the kubelet always requires a kubeconfig, and it cannot address the security team's goal of ensuring encrypted communication.

Question 12mediumdrag order

Order the steps to rotate a Kubernetes API server certificate.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: 1

Restarting kube-apiserver before generating a new certificate only causes the process to reload the existing certificate from disk, so it does nothing to rotate anything. If the old certificate is still present, the restart is wasted; if the old certificate has already been removed or expired, the API server may fail to start. The subsequent generate/replace steps cannot take effect until another restart, making the first restart redundant and the sequence incorrect.

Trap 2: 1

Attempting to replace certificate files before generating the new certificate is an impossible operation because there is no new key/cert pair to copy into place. Even if you removed the old files first, the API server would be left with no valid credentials, and any subsequent generation step would not automatically re-deploy the files unless repeated. The correct sequence must generate first to have the artifacts available for replacement.

Trap 3: 1

Running curl or openssl verification immediately after replacing files but before restarting the API server cannot confirm rotation because the running process still uses the previously loaded certificate from memory. The verification would either connect to the old certificate, giving false confidence, or fail if the old certificate has expired/been revoked, while the new files sit unused on disk. Only a restart loads the new certificate, so verification belongs after the restart step.

A
1. Generate a new certificate and key pair for the API server. 2. Replace the existing certificate files on the control plane node. 3. Restart the kube-apiserver process or container. 4. Verify the new certificate is serving correctly using curl or openssl.
This is the correct order because the new certificate must be generated first, then its files must replace the old ones, the API server must be restarted to load the new certificate, and finally verification ensures the process succeeded.
B
1. Restart the kube-apiserver process. 2. Generate a new certificate. 3. Replace the old certificates. 4. Verify.
Why it fails: Restarting kube-apiserver before generating a new certificate only causes the process to reload the existing certificate from disk, so it does nothing to rotate anything. If the old certificate is still present, the restart is wasted; if the old certificate has already been removed or expired, the API server may fail to start. The subsequent generate/replace steps cannot take effect until another restart, making the first restart redundant and the sequence incorrect.
C
1. Replace the existing certificate files. 2. Generate a new certificate. 3. Restart the API server. 4. Verify.
Why it fails: Attempting to replace certificate files before generating the new certificate is an impossible operation because there is no new key/cert pair to copy into place. Even if you removed the old files first, the API server would be left with no valid credentials, and any subsequent generation step would not automatically re-deploy the files unless repeated. The correct sequence must generate first to have the artifacts available for replacement.
D
1. Generate new certificate. 2. Replace old files. 3. Verify using curl. 4. Restart API server.
Why it fails: Running curl or openssl verification immediately after replacing files but before restarting the API server cannot confirm rotation because the running process still uses the previously loaded certificate from memory. The verification would either connect to the old certificate, giving false confidence, or fail if the old certificate has expired/been revoked, while the new files sit unused on disk. Only a restart loads the new certificate, so verification belongs after the restart step.

Question 13mediummatching

Match each Kubernetes admission controller to its role in security.

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

Concepts

Matches

Limits the Node and Pod objects a kubelet can modify

Ensures images are always pulled, preventing use of local images

Denies pods with certain security context settings (deprecated)

Implements automation for service accounts

Enforces namespace-level node selector restrictions

Trap 1: NodeRestriction: Controls automounting of service account tokens to…

This is incorrect because the NodeRestriction controller does not manage service account tokens. Token automounting is handled by the ServiceAccount admission controller, which reads the pod and service account settings to decide whether to project a token volume. NodeRestriction instead focuses on limiting which API objects a kubelet can modify, so this pairing mismatches the controller's actual scope.

Trap 2: PodSecurity: Limits the permissions of kubelet nodes.

This is incorrect because limiting kubelet permissions is the job of NodeRestriction, not PodSecurity. The PodSecurity controller operates on the pod's security context and applies the Pod Security Standards to enforce capabilities, privilege escalation, host paths, and other security-related fields. While both contribute to overall cluster hardening, they target entirely different layers: one constrains a node agent, the other validates pod-level security properties.

A
NodeRestriction: Limits the permissions of kubelet nodes to prevent unauthorized operations.
NodeRestriction admission controller is specifically designed to limit the kubelet's permissions on Node and Pod API objects. It ensures that a kubelet can only modify its own Node object and pods bound to it, and cannot add or edit labels, taints, or status fields that could be used to escalate privileges or disrupt the cluster. This prevents a compromised kubelet from impersonating another node or altering critical metadata.
B
PodSecurity: Enforces Pod Security Standards (privileged, baseline, restricted).
PodSecurity is a built-in admission controller that enforces the Pod Security Standards defined by Kubernetes. It applies the privileged, baseline, or restricted profiles based on the namespace's pod-security labels, and it can either enforce, audit, or warn on policy violations. This controller replaces the deprecated PodSecurityPolicy and validates pod specifications at creation time, refusing or logging workloads that exceed the configured security constraints.
C
ServiceAccount: Controls automounting of service account tokens to pods.
The ServiceAccount admission controller governs how service account tokens are mounted into pods. It checks the automountServiceAccountToken field on both the pod and the service account, and by default sets a token volume even if no explicit mount is requested. This controller can deny or modify the automount behavior, which is critical for limiting the exposure of the cluster's API credentials to containers that do not need them.
D
AlwaysPullImages: Forces pods to always pull container images, ensuring no local cached images are used without verification.
AlwaysPullImages is an admission controller that overwrites every pod's imagePullPolicy to Always, regardless of what the user specified. This forces the kubelet to contact the image registry on each container start, preventing the use of potentially stale or tampered images already cached on the node. It is commonly used in multi-tenant clusters to ensure that only registry-defined images run, and that image credentials are always validated for each pull.
E
NodeRestriction: Controls automounting of service account tokens to pods.
Why it fails: This is incorrect because the NodeRestriction controller does not manage service account tokens. Token automounting is handled by the ServiceAccount admission controller, which reads the pod and service account settings to decide whether to project a token volume. NodeRestriction instead focuses on limiting which API objects a kubelet can modify, so this pairing mismatches the controller's actual scope.
F
PodSecurity: Limits the permissions of kubelet nodes.
Why it fails: This is incorrect because limiting kubelet permissions is the job of NodeRestriction, not PodSecurity. The PodSecurity controller operates on the pod's security context and applies the Pod Security Standards to enforce capabilities, privilege escalation, host paths, and other security-related fields. While both contribute to overall cluster hardening, they target entirely different layers: one constrains a node agent, the other validates pod-level security properties.

Question 14hardmultiple choice

A platform team runs a multi-tenant cluster and wants to enforce that all newly created Pods in the 'payments' namespace must run as non-root and must drop all Linux capabilities. The team decides to use a Pod Security Admission (PSA) label on the namespace. Which label value should they apply to the namespace to enforce these restrictions while still allowing other namespaces to remain unrestricted?

Trap 1: pod-security.kubernetes.io/enforce: baseline

The baseline policy prevents known privilege escalations but still allows running as root and does not require dropping all capabilities. It would not enforce the non-root or drop-all-capabilities requirements the team needs for the payments namespace. Applying baseline leaves the namespace less restricted than the stated security objective demands, so it is insufficient here.

Trap 2: pod-security.kubernetes.io/audit: restricted

The audit label only records policy violations in the audit log; it does not block non-compliant Pods from being created. The team needs enforcement that rejects non-root or capability-retaining Pods, so an audit-only label fails to meet the objective. It provides visibility without prevention, which is not what this scenario requires.

Trap 3: pod-security.kubernetes.io/enforce: privileged

The privileged policy is the least restrictive and explicitly allows everything, including root, host access, and all capabilities. It exists for system workloads that genuinely need full access. Applying it to the payments namespace would do the opposite of the requirement, effectively disabling the security controls the team wants to impose.

A
pod-security.kubernetes.io/enforce: baseline
Why it fails: The baseline policy prevents known privilege escalations but still allows running as root and does not require dropping all capabilities. It would not enforce the non-root or drop-all-capabilities requirements the team needs for the payments namespace. Applying baseline leaves the namespace less restricted than the stated security objective demands, so it is insufficient here.
B
pod-security.kubernetes.io/audit: restricted
Why it fails: The audit label only records policy violations in the audit log; it does not block non-compliant Pods from being created. The team needs enforcement that rejects non-root or capability-retaining Pods, so an audit-only label fails to meet the objective. It provides visibility without prevention, which is not what this scenario requires.
C
pod-security.kubernetes.io/enforce: restricted
The restricted policy enforces the most hardened Pod Security Standard, requiring non-root execution, dropping all capabilities, disallowing privilege escalation, and mandating seccomp and runtime default settings. Applying this enforce label to the payments namespace makes non-compliant Pods rejected at admission, while other namespaces without the label remain unaffected, matching the requirement.
D
pod-security.kubernetes.io/enforce: privileged
Why it fails: The privileged policy is the least restrictive and explicitly allows everything, including root, host access, and all capabilities. It exists for system workloads that genuinely need full access. Applying it to the payments namespace would do the opposite of the requirement, effectively disabling the security controls the team wants to impose.

Question 15hardmultiple choice

A cluster administrator wants to enforce that all newly created pods in the 'production' namespace run with a read-only root filesystem. The cluster uses Kubernetes 1.25+ and the Pod Security Admission controller is enabled with the baseline and restricted profiles. Which namespace label must be applied to enforce the restricted policy?

Trap 1: pod-security.kubernetes.io/audit: restricted

The audit label records violations of the restricted policy in the audit log but does not prevent pod creation. It is used for monitoring, not enforcement. Since the requirement is to enforce a read-only root filesystem, this label alone would not block non-compliant pods, making it insufficient for the scenario.

Trap 2: pod-security.kubernetes.io/enforce: baseline

The baseline policy is less restrictive than restricted and does not require a read-only root filesystem. While it prevents known privilege escalations, it permits many settings that restricted forbids. Enforcing baseline would not meet the requirement of a read-only root filesystem for all pods in the namespace.

Trap 3: pod-security.kubernetes.io/warn: restricted

The warn label causes a warning to be shown to the user when a pod violates the restricted policy, but it still allows the pod to be created. It does not enforce any restriction. Therefore, it cannot guarantee that all pods run with a read-only root filesystem, failing the stated security objective.

A
pod-security.kubernetes.io/enforce: restricted
This label enforces the restricted Pod Security Standard on the namespace. The restricted profile requires a read-only root filesystem, among other controls. Applying this label ensures that any pod violating the policy is rejected. This directly satisfies the requirement without needing additional tools, and it is the correct label for Kubernetes 1.25+ with Pod Security Admission.
B
pod-security.kubernetes.io/audit: restricted
Why it fails: The audit label records violations of the restricted policy in the audit log but does not prevent pod creation. It is used for monitoring, not enforcement. Since the requirement is to enforce a read-only root filesystem, this label alone would not block non-compliant pods, making it insufficient for the scenario.
C
pod-security.kubernetes.io/enforce: baseline
Why it fails: The baseline policy is less restrictive than restricted and does not require a read-only root filesystem. While it prevents known privilege escalations, it permits many settings that restricted forbids. Enforcing baseline would not meet the requirement of a read-only root filesystem for all pods in the namespace.
D
pod-security.kubernetes.io/warn: restricted
Why it fails: The warn label causes a warning to be shown to the user when a pod violates the restricted policy, but it still allows the pod to be created. It does not enforce any restriction. Therefore, it cannot guarantee that all pods run with a read-only root filesystem, failing the stated security objective.