CCNA Cluster Setup Questions

MCQhard

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?

A.pod-security.kubernetes.io/enforce: baseline

B.pod-security.kubernetes.io/audit: restricted

C.pod-security.kubernetes.io/enforce: restricted

D.pod-security.kubernetes.io/enforce: privileged

AnswerC

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.

Why this answer

Pod Security Admission enforces one of three levels: privileged, baseline, or restricted. The restricted level is the only one that requires non-root execution and dropping all capabilities. Setting the enforce label to restricted on the payments namespace blocks non-compliant Pods there while leaving other namespaces without the label unrestricted, which satisfies the multi-tenant requirement.

Exam trap

The trap here is confusing the audit or warn labels with enforce, when only the enforce label actually rejects non-compliant Pods.

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=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.

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

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.

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 →

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

/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.

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 →

MCQhard

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?

A.pod-security.kubernetes.io/enforce: restricted

B.pod-security.kubernetes.io/audit: restricted

C.pod-security.kubernetes.io/enforce: baseline

D.pod-security.kubernetes.io/warn: restricted

AnswerA

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.

Why this answer

The Pod Security Admission controller uses namespace labels to enforce policies. The restricted profile mandates a read-only root filesystem. Only the enforce label with value restricted actively blocks non-compliant pods.

Audit and warn labels merely log or alert, and baseline is insufficient. Thus, pod-security.kubernetes.io/enforce: restricted is the correct label.

Exam trap

The trap here is confusing the audit or warn labels with enforcement, or choosing the baseline profile which does not require a read-only root filesystem.

Practice this question →

Drag & Dropmedium

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

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 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.

Why this answer

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 →