Cluster Setup practice questions

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 wrong: 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 wrong: 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 wrong: 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 2hardmultiple choice

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 wrong: 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 wrong: 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 wrong: 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 3mediummulti 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 wrong: 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 wrong: 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 wrong: 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 4hardmulti 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 wrong: 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 wrong: 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 5easymultiple 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 wrong: 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 wrong: /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 wrong: /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 6hardmultiple 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 wrong: 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 wrong: 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 wrong: 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 7mediummultiple 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 wrong: 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 wrong: 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 wrong: 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 8mediumdrag order

Order the steps to rotate a Kubernetes API server certificate.

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

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 wrong: 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 wrong: 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 wrong: 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 9mediummatching

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 wrong: 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 wrong: 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 10mediummultiple 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 wrong: 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 wrong: 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 wrong: 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.