CCNA Cluster Setup Questions

MCQhard

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?

A.Edit the etcd configuration to use the encryption config file directly

B.Add --experimental-encryption-provider-config=/etc/kubernetes/encryption-config.yaml to the kube-apiserver manifest and restart the kubelet

C.Move the etcd data directory to an encrypted filesystem using LUKS

D.Add --encryption-provider-config=/etc/kubernetes/encryption-config.yaml to the kube-apiserver manifest, then kubelet will automatically restart the static pod

AnswerD

Correct flag and automatic restart by kubelet.

Why this answer

Option D is correct because in Kubernetes v1.28, the `--experimental-encryption-provider-config` flag has been graduated to stable and renamed to `--encryption-provider-config`. Adding this flag to the kube-apiserver manifest (static pod YAML) causes the kubelet to automatically restart the static pod when the manifest file changes, minimizing downtime. This ensures both existing and new secrets are encrypted using the configured provider (e.g., AES-CBC or secretbox) as the apiserver rewrites existing secrets on startup.

Exam trap

The trap here is that candidates may confuse the deprecated `--experimental-encryption-provider-config` flag with the stable `--encryption-provider-config` flag, or think they need to manually restart the kubelet or modify etcd directly, when in fact the kubelet auto-restarts static pods and the apiserver handles encryption transparently.

How to eliminate wrong answers

Option A is wrong because etcd does not directly consume the encryption configuration file; the kube-apiserver is the component that encrypts/decrypts data before storing it in etcd. Option B is wrong because `--experimental-encryption-provider-config` is deprecated in Kubernetes v1.28 and the correct flag is `--encryption-provider-config`; additionally, restarting the kubelet is unnecessary as the kubelet automatically restarts static pods when their manifest changes. Option C is wrong because moving the etcd data directory to an encrypted filesystem (e.g., LUKS) encrypts data at the filesystem level, not at the Kubernetes API level, and does not satisfy the requirement to encrypt secrets at rest via the encryption configuration; it also requires etcd downtime and does not leverage the native Kubernetes encryption provider mechanism.

Practice this question →

MCQmedium

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?

A.Change the --insecure-port flag to 0

B.Set --insecure-port=0 and ensure --secure-port=6443 is configured

C.Set --insecure-port=6443

D.Set --secure-port=8080

AnswerB

Setting insecure-port to 0 disables it, and secure-port=6443 uses TLS.

Why this answer

Setting `--insecure-port=0` disables the unencrypted HTTP port (default 8080), which eliminates the risk of unauthenticated access to the API server. Ensuring `--secure-port=6443` is configured enforces TLS-encrypted communication on the standard secure port, which is the only recommended and secure method for production clusters.

Exam trap

CNCF often tests the misconception that simply changing the insecure port number or setting it to a non-default value is sufficient, whereas the only secure remediation is to disable it entirely with `--insecure-port=0` and explicitly enable the secure port.

How to eliminate wrong answers

Option A is wrong because merely changing the insecure port to 0 without explicitly ensuring the secure port is configured may leave the API server without any listening port if the secure port is also misconfigured or defaulting to an unintended value. Option C is wrong because setting `--insecure-port=6443` would enable the insecure port on the same port as the secure port, causing a conflict and still exposing unauthenticated access. Option D is wrong because setting `--secure-port=8080` would move the TLS-encrypted port to 8080, but this does not disable the insecure port (default 8080), leading to a port conflict and continued exposure of the insecure endpoint.

Practice this question →

MCQeasy

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?

A.5

B.1

C.3

D.7

AnswerC

3 members tolerate one member failure, maintaining majority.

Why this answer

For a highly available Kubernetes control plane across three availability zones, the etcd cluster must tolerate the loss of one entire zone. With three etcd members, one per zone, the cluster requires a majority (2) to form quorum. If one zone fails, the remaining two members still constitute a majority, ensuring continued operation.

This matches the minimum odd number greater than one that provides fault tolerance against a single failure.

Exam trap

CNCF often tests the misconception that you need an even number of etcd members for high availability, but the Raft consensus algorithm requires an odd number to avoid split-brain scenarios, and the minimum for fault tolerance against one failure is three, not five or seven.

How to eliminate wrong answers

Option A is wrong because 5 etcd members would provide fault tolerance against two zone failures, which is more than required and not the minimum. Option B is wrong because a single etcd member has no fault tolerance; if that member or its zone fails, the entire cluster loses quorum and becomes unavailable. Option D is wrong because 7 etcd members provide fault tolerance against three zone failures, far exceeding the minimum needed for one zone failure and introducing unnecessary overhead.

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.Enable encryption at rest for etcd data

B.Configure RBAC on etcd

C.Enable TLS with peer certificates for etcd member communication

D.Enable TLS with client certificates for etcd client communication

E.Apply NetworkPolicies to etcd pods

AnswersC, D

Peer certificates secure inter-etcd communication.

Why this answer

Option C is correct because etcd uses the Raft consensus protocol for distributed coordination, and enabling TLS with peer certificates ensures that all communication between etcd members (nodes) is encrypted and authenticated. This prevents man-in-the-middle attacks and unauthorized nodes from joining the cluster, which is a core security requirement for the control plane's data store.

Exam trap

CNCF often tests the distinction between securing the etcd cluster itself (via TLS for communication) versus securing the data at rest or using Kubernetes-level controls like RBAC or NetworkPolicies, which do not apply to the etcd process running outside the pod network.

Practice this question →

MCQhard

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?

A.The kubelet's node IP has changed

B.The kubelet's certificate has expired

C.The kubelet is using an outdated kubeconfig

D.The bootstrap kubeconfig file is missing or misconfigured

AnswerD

The bootstrap kubeconfig is used to initially request a client certificate; missing file leads to this error.

Why this answer

The error 'failed to load bootstrap client certificate: open /var/lib/kubelet/pki/kubelet-client-current.pem: no such file or directory' indicates that the kubelet cannot find the bootstrap client certificate file. This file is generated from the bootstrap kubeconfig file during the initial TLS bootstrapping process. If the bootstrap kubeconfig file is missing or misconfigured, the kubelet cannot request or renew its client certificate, leading to this failure.

Exam trap

CNCF often tests the distinction between bootstrap kubeconfig errors and certificate expiry errors; the trap here is that candidates confuse a missing file (bootstrap configuration issue) with a certificate expiry or authentication problem, leading them to choose options B or C.

How to eliminate wrong answers

Option A is wrong because a change in the node IP would cause network connectivity issues or certificate SAN mismatches, not a missing certificate file. Option B is wrong because an expired certificate would produce a different error, such as 'certificate has expired' or 'x509: certificate has expired or is not yet valid', not a 'no such file or directory' error. Option C is wrong because an outdated kubeconfig would cause authentication failures (e.g., 'Unauthorized') or token expiry errors, not a missing file error for the bootstrap client certificate.

Practice this question →

Matchingmedium

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

Why these pairings

Admission controllers intercept requests to the API server and can enforce security policies.

Practice this question →

MCQeasy

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?

A./var/lib/kubelet/

B./etc/kubernetes/manifests/

C./etc/kubernetes/admin.conf

D./etc/kubernetes/

AnswerB

Default static pod manifest directory.

Why this answer

In a kubeadm-deployed cluster, the control plane components (API server, controller manager, scheduler) run as static pods. The kubelet watches a specific directory for pod manifests to create these static pods. By default, kubeadm places the manifests for the API server (and other control plane components) in /etc/kubernetes/manifests/.

This directory is specified via the --pod-manifest-path or staticPodPath in the kubelet configuration.

Exam trap

The trap here is that candidates confuse the static pod manifest directory (/etc/kubernetes/manifests/) with the kubelet's working directory (/var/lib/kubelet/) or the general cluster configuration directory (/etc/kubernetes/), leading them to pick a plausible but incorrect path.

How to eliminate wrong answers

Option A is wrong because /var/lib/kubelet/ is the default directory for kubelet's internal data (e.g., pod volumes, plugins, and the device plugin directory), not for static pod manifests. Option C is wrong because /etc/kubernetes/admin.conf is the kubeconfig file used by kubectl and administrators to authenticate to the cluster, not a directory for manifests. Option D is wrong because /etc/kubernetes/ is the parent directory containing cluster configuration files (like admin.conf, kubelet.conf, and the manifests subdirectory), but the static pod manifests themselves reside specifically in the /etc/kubernetes/manifests/ subdirectory, not directly in /etc/kubernetes/.

Practice this question →

Drag & Dropmedium

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

Why this order

Certificate rotation involves generating new certs, replacing files, restarting the service, and verifying. Kubeconfig updates may be needed if CA changes.

Practice this question →

MCQmedium

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?

A.--tls-cert-file

B.--node-status-update-frequency

C.--kubeconfig

D.--require-kubeconfig

AnswerC

The kubeconfig file contains the API server address with HTTPS.

Why this answer

Option C is correct because the `--kubeconfig` flag on the kubelet specifies the path to a kubeconfig file that contains the credentials and server address for the API server. When this flag is set, the kubelet uses TLS to authenticate and encrypt all communication with the API server, as the kubeconfig file typically references an HTTPS endpoint and includes client certificates or tokens. Without this flag, the kubelet may fall back to insecure or unencrypted connections, violating the requirement for encrypted communication.

Exam trap

The trap here is that candidates often confuse `--tls-cert-file` (which secures the kubelet's own server) with the flag that secures outbound kubelet-to-API-server communication, leading them to pick Option A instead of the correct `--kubeconfig`.

How to eliminate wrong answers

Option A is wrong because `--tls-cert-file` specifies the certificate file for the kubelet's own TLS server (used when serving its metrics or health endpoints), not for encrypting outbound communication to the API server. Option B is wrong because `--node-status-update-frequency` controls how often the kubelet posts node status to the API server, but has no effect on encryption of the communication channel. Option D is wrong because `--require-kubeconfig` is a deprecated flag that caused the kubelet to exit if no kubeconfig was provided, but it does not itself enforce encryption; the actual encryption is enforced by the presence and content of the kubeconfig file referenced by `--kubeconfig`.

Practice this question →

Multi-Selecthard

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

Select 3 answers

A.Ensure the Kubernetes version is not downgraded

B.Specify --pod-network-cidr to define the pod network range

C.Specify --control-plane-endpoint for high availability

D.Specify --apiserver-advertise-address

E.Generate a bootstrap token with kubeadm token create

AnswersA, B, C

kubeadm prevents downgrading.

Why this answer

Option A is correct because kubeadm enforces a strict version skew policy: the kubelet version must not be newer than the control plane version, and downgrading the control plane (e.g., from v1.28 to v1.27) is not supported. Attempting a downgrade can lead to API version mismatches, schema incompatibilities, and cluster instability. In production, you must plan upgrades carefully and never downgrade the control plane components.

Exam trap

CNCF often tests the misconception that --apiserver-advertise-address is mandatory for all control plane setups, but it is only needed when the node has multiple network interfaces or you need to override the default IP detection.

Practice this question →