Certified Kubernetes Security Specialist CKS CKS Questions 226–300 | Page 4/12

226

MCQmedium

An administrator runs 'kube-bench run --targets=master' and sees a failing check for 'Ensure that the --audit-log-path argument is set'. What is the correct remediation?

A.Add '--audit-policy-file=/etc/kubernetes/audit-policy.yaml' to the API server

B.Add '--audit-log-path=/var/log/audit.log' to the kube-apiserver

C.Add '--audit-log-path=/var/log/audit.log' to the kube-controller-manager

D.Add '--audit-log-maxsize=100' to the API server

AnswerB

This is the correct approach: the Kubernetes API server is the component that processes API requests and is solely responsible for generating audit events. Setting `--audit-log-path=/var/log/audit.log` tells the kube-apiserver to append audit records to that file, enabling file-based audit logging. This is the standard and essential flag for meeting control-plane audit-logging requirements, and it is exactly what kube-bench checks for.

Why this answer

The kube-bench check for 'Ensure that the --audit-log-path argument is set' specifically targets the kube-apiserver component, as it is the primary component that handles API requests and should log them for audit purposes. The correct remediation is to add '--audit-log-path=/var/log/audit.log' to the kube-apiserver's startup arguments, which enables writing audit logs to a specified file path. This ensures that all API server requests are recorded for security monitoring and compliance.

Exam trap

The trap here is that candidates often confuse the audit policy file argument with the audit log path argument, or mistakenly think audit logging applies to other control plane components like the controller-manager, when in fact it is exclusively a kube-apiserver configuration.

How to eliminate wrong answers

Option A is wrong because '--audit-policy-file' defines the audit policy rules (what to log), not the log file path; it is a separate required setting but does not satisfy the check for '--audit-log-path'. Option C is wrong because the kube-controller-manager does not handle API requests directly and is not the target of this audit logging requirement; audit logging is a kube-apiserver responsibility. Option D is wrong because '--audit-log-maxsize' controls the maximum size of a log file before rotation, not the path where logs are written; it is an auxiliary setting, not the primary remediation for the missing log path.

Full explanation →

227

MCQhard

You need to detect any unexpected outbound connections from pods in the 'production' namespace. Which Falco rule condition is MOST appropriate?

A.evt.type=sendto and fd.sip != "0.0.0.0"

B.evt.type=connect and container.id != host and not fd.snet in ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8")

C.container.id != host and evt.type=accept

D.proc.name = curl and evt.type=connect

AnswerB

This is correct because `connect` is the syscall invoked whenever a process initiates an outbound TCP connection (and can also set a default peer for UDP), making it the ideal hook for detecting unexpected egress. The `container.id != host` condition ensures only events from containers are evaluated, excluding host-level connections. The `not fd.snet in (...)` clause excludes RFC1918 private ranges and loopback, so the rule only fires when a container connects to a public IP, i.e., an actual outbound internet connection.

Why this answer

It uses the `connect` syscall to detect outbound connection attempts from containers (excluding the host) and filters out private IP ranges (RFC 1918 and loopback) to flag only unexpected external destinations. This directly matches the requirement to detect unexpected outbound connections from pods in the 'production' namespace.

Exam trap

In the CKS exam, a common pitfall is confusing `connect` (outbound) with `accept` (inbound) syscalls in Falco rules. Candidates may choose `evt.type=accept` thinking it detects outbound connections, but `accept` is for incoming connections. The correct rule uses `connect` to catch outbound attempts and filters private IPs to flag unexpected external destinations.

How to eliminate wrong answers

Option A is wrong because `sendto` is used for sending data on a UDP socket, not for establishing a connection; it also uses `fd.sip` (server IP) but the condition `!= "0.0.0.0"` is too broad and does not filter private ranges, so it would generate many false positives. Option C is wrong because `evt.type=accept` detects incoming connections (server-side), not outbound connections from pods. Option D is wrong because it restricts detection to only the `curl` process, which is far too narrow and misses other tools or libraries (e.g., wget, netcat, or application-level HTTP clients) that could make outbound connections.

Full explanation →

228

MCQmedium

An administrator wants to ensure that no service account in the 'development' namespace has cluster-admin privileges. Which command should be used to identify such bindings?

A.kubectl get serviceaccounts -n development

B.kubectl get clusterrolebindings -o yaml | grep -B 10 namespace: development

C.kubectl get rolebindings -n development --all-namespaces

D.kubectl describe clusterrole cluster-admin

AnswerB

This is the correct approach because ClusterRoleBindings are the only mechanism that can grant a cluster-scoped role like cluster-admin to subjects, including ServiceAccounts. The YAML output includes each binding's subjects, and the -B 10 context around 'namespace: development' reveals bindings whose subjects reference a ServiceAccount in that namespace. This surfaces the specific ClusterRoleBinding and its roleRef, allowing the admin to see exactly who is bound to cluster-admin or any other cluster role. It is a practical grep-based audit even though it may also match unrelated namespaces in other fields.

Why this answer

`ClusterRoleBindings` are cluster-scoped resources that grant permissions across all namespaces, including the `development` namespace. By piping the YAML output through `grep -B 10 namespace: development`, you can identify which `ClusterRoleBinding` references a service account in the `development` namespace, revealing any binding that could grant cluster-admin privileges to that namespace's service accounts.

Exam trap

The trap here is that candidates often confuse `RoleBindings` (namespace-scoped) with `ClusterRoleBindings` (cluster-scoped), assuming that `RoleBindings` can grant cluster-admin privileges, or they mistakenly think listing service accounts or describing the ClusterRole itself will reveal the bindings.

How to eliminate wrong answers

Option A is wrong because `kubectl get serviceaccounts -n development` only lists service accounts in the namespace, not the bindings that grant them permissions; it cannot reveal whether any service account has cluster-admin privileges. Option C is wrong because `kubectl get rolebindings -n development --all-namespaces` is syntactically incorrect (you cannot combine `-n` with `--all-namespaces`), and even if corrected, `RoleBindings` are namespace-scoped and cannot grant cluster-admin privileges (which require a `ClusterRoleBinding`). Option D is wrong because `kubectl describe clusterrole cluster-admin` only describes the permissions of the `cluster-admin` ClusterRole, but does not show which subjects (users, groups, or service accounts) are bound to it, so it cannot identify bindings in the `development` namespace.

Full explanation →

229

MCQhard

You run kube-bench on a node and it reports a failure for control plane component etcd. The check says 'Ensure that the --cert-file and --key-file arguments are set as appropriate'. You examine the etcd manifest file and find that the cert-file and key-file are configured with a self-signed certificate. What is the BEST action to remediate this finding?

A.Add the --trusted-ca-file flag pointing to the CA certificate.

B.Remove the --cert-file and --key-file flags to disable TLS.

C.Change the self-signed certificate to one signed by the Kubernetes CA.

D.Set the --auto-tls flag to true to let etcd automatically generate a certificate.

AnswerC

Replacing the self-signed certificate with a certificate signed by the Kubernetes CA satisfies the benchmark because kube-apiserver is already configured to trust certificates issued by that CA. The CIS check verifies that etcd's server certificate is signed by a recognized CA (typically the Kubernetes PKI), rather than being self-signed. This change preserves TLS while establishing a valid certificate chain, so the apiserver can authenticate etcd's identity securely.

Why this answer

Kube-bench expects etcd to use certificates signed by a trusted CA (typically the Kubernetes CA) for secure communication. Self-signed certificates are not trusted by default and can lead to man-in-the-middle attacks or connection failures. Replacing the self-signed certificate with one signed by the Kubernetes CA ensures that the certificate chain is validated, aligning with the CIS Benchmark requirement for etcd.

Exam trap

The trap here is that candidates may confuse 'self-signed' with 'auto-generated' (option D) or think that adding a CA file (option A) fixes the issue, but the core requirement is that the certificate itself must be signed by a trusted CA, not just that a CA file is present.

How to eliminate wrong answers

Option A is wrong because adding --trusted-ca-file alone does not address the requirement that the server certificate itself must be signed by a trusted CA; it only specifies which CA to trust for client connections, but the self-signed cert still lacks a proper CA signature. Option B is wrong because removing --cert-file and --key-file disables TLS entirely, which violates the CIS Benchmark requirement for encrypted communication and exposes etcd to unencrypted traffic. Option D is wrong because setting --auto-tls to true enables automatic self-signed certificate generation, which still results in a self-signed certificate that is not trusted by the Kubernetes CA, failing the same check.

Full explanation →

230

Multi-Selecthard

Which THREE practices help ensure the integrity and confidentiality of container logs in a Kubernetes cluster?

Select 3 answers

A.Configure the log collector to use TLS when shipping logs to a central system.

B.Set container 'stdout' logging only, avoiding file-based logs.

C.Store logs in a backend that supports encryption at rest (e.g., S3 with SSE).

D.Run log collectors in a dedicated namespace with network policies limiting access.

E.Disable log rotation to prevent log tampering during rotation.

AnswersA, C, D

TLS (Transport Layer Security) encrypts log data in transit between the node's log collector and the central aggregation system, providing confidentiality by preventing eavesdropping and integrity via message authentication codes that detect tampering. Without TLS, logs sent over the network could be intercepted or modified by an attacker positioned on the network path, undermining the reliability of audit trails and forensic evidence. This practice directly addresses both confidentiality and integrity during the log transport phase.

Why this answer

Configuring the log collector to use TLS (e.g., Fluentd with TLS output plugin or Filebeat with SSL/TLS) encrypts log data in transit, preventing eavesdropping or tampering during shipping to a central system like Elasticsearch or Splunk. This directly protects confidentiality and integrity against man-in-the-middle attacks on the network path.

Exam trap

CNCF often tests the misconception that disabling log rotation improves security, but in reality, rotation is a standard operational practice that does not inherently compromise integrity; the trap is confusing operational controls with security controls.

Full explanation →

231

MCQhard

A pod runs with 'hostNetwork: true' and 'hostPID: true'. Which security concern is MOST directly increased?

A.The container can access host processes and potentially escape

B.The container can modify iptables rules

C.The container can sniff network traffic of other pods

D.The container can mount the host filesystem

AnswerA

With hostPID: true, the container shares the host's PID namespace, so it can enumerate and interact with every host process through /proc. If the container runs as root or has CAP_SYS_PTRACE, it can ptrace host processes, read their memory, inject signals, or extract credentials. This visibility drastically lowers the barrier to a container escape because a single kernel exploit or misconfiguration that gives code execution inside the container can be leveraged against host-level processes directly, rather than being confined to the container's own PID namespace.

Why this answer

Setting `hostNetwork: true` and `hostPID: true` in a pod grants the container direct access to the host's network namespace and process namespace. With `hostPID: true`, the container can see all host processes (e.g., via `ps aux`) and potentially interact with them using system calls like `ptrace`, which could allow escaping the container by injecting code into a host process. This combination directly increases the risk of container breakout, making A the most significant security concern.

Exam trap

The trap here is that candidates focus on the network-related concern (sniffing traffic) because `hostNetwork` is more obvious, but they overlook that `hostPID` enables direct process manipulation, which is a more severe security risk for container escape.

How to eliminate wrong answers

Option B is wrong because modifying iptables rules requires `NET_ADMIN` capability, which is not granted by `hostNetwork: true` alone; `hostNetwork` only shares the network namespace, not the ability to alter firewall rules. Option C is wrong because sniffing network traffic of other pods is already possible with `hostNetwork: true` (since the container shares the host's network stack), but this is a lesser concern compared to process-level escape; the question asks for the 'MOST directly increased' concern. Option D is wrong because mounting the host filesystem requires a `hostPath` volume mount or privileged access, which is not automatically provided by `hostNetwork` or `hostPID`; these settings do not grant filesystem access.

Full explanation →

232

Multi-Selectmedium

Which two of the following are recommended by the CIS Kubernetes Benchmark? (Choose two.)

Select 2 answers

A.Use NodePort services for internal communication

B.Enable the insecure port on the API server

C.Disable anonymous authentication on the API server

D.Use the default service account for all pods

E.Enable audit logging on the API server

AnswersC, E

Setting --anonymous-auth=false on the API server disables unauthenticated requests, so any request without valid credentials is rejected with HTTP 401. CIS Benchmark 1.2.1 specifically recommends this because anonymous access can allow unauthorized discovery of cluster metadata or exploitation of misconfigured RBAC. When enabled, the API server permits anonymous requests, which may be matched by overly permissive ClusterRoleBindings. Disabling it forces all clients to authenticate, reducing the risk of accidental exposure.

Why this answer

The CIS Kubernetes Benchmark explicitly recommends disabling anonymous authentication on the API server to prevent unauthenticated access. Anonymous requests bypass all authentication checks and can lead to unauthorized cluster operations if RBAC is not properly scoped. Setting the `--anonymous-auth=false` flag on the API server ensures that only authenticated users can interact with the cluster.

Exam trap

CNCF often tests the misconception that NodePort services are suitable for internal cluster communication, but the trap is that NodePort is designed for external access and introduces unnecessary network exposure, while ClusterIP is the correct internal service type.

Full explanation →

233

MCQeasy

Which crictl command is used to view logs from a specific container?

A.crictl exec <container-id>

B.crictl inspect <container-id>

C.crictl ps

D.crictl logs <container-id>

AnswerD

crictl logs retrieves stdout/stderr output for a given container ID from the runtime, optionally with --tail or --follow. It satisfies the requirement to inspect a specific container's logs when debugging via the CRI rather than the kubelet.

Why this answer

`crictl logs <container-id>` is the command used to retrieve logs from a specific container managed by a CRI-compatible runtime (e.g., containerd, CRI-O). This command fetches the container's stdout and stderr output, similar to `docker logs`, and is essential for debugging and monitoring containerized applications in Kubernetes.

Exam trap

The trap here is that candidates may confuse `crictl exec` (which runs commands) with `crictl logs` (which retrieves logs), or mistakenly think `crictl ps` shows logs because it lists containers, but it only shows status, not log output.

How to eliminate wrong answers

Option A is wrong because `crictl exec <container-id>` runs a command inside a running container, not view logs. Option B is wrong because `crictl inspect <container-id>` displays detailed metadata and configuration of a container, not its log output. Option C is wrong because `crictl ps` lists all running containers (similar to `docker ps`), but does not show logs for any specific container.

Full explanation →

234

MCQmedium

An administrator wants to ensure that only images from a specific registry (e.g., myregistry.internal) can run in the cluster. Which tool can be used to enforce this via admission control?

A.Cosign

B.Notary

C.Trivy

D.OPA/Gatekeeper

AnswerD

OPA/Gatekeeper is the correct choice because it is an admission controller that integrates with Kubernetes as a validating webhook. Using Constraint Templates and constraint manifests, an administrator can write a Rego policy that inspects each Pod's container images and denies creation if any image does not come from an approved registry. This provides real-time, cluster-wide enforcement of registry allowlists, which is exactly what the administrator wants.

Why this answer

OPA/Gatekeeper is a Kubernetes admission controller that can enforce policies on pod creation, including restricting which container image registries are allowed. By writing a ConstraintTemplate and Constraint that checks the image field against a whitelist of registries, Gatekeeper can reject any pod that attempts to use an image from an unauthorized source. This directly addresses the requirement to enforce registry restrictions at admission time.

Exam trap

The trap here is that candidates confuse tools for image signing or scanning (Cosign, Notary, Trivy) with admission control tools that enforce runtime policies, but only OPA/Gatekeeper provides the Kubernetes-native admission webhook mechanism to block pods based on image registry origin.

How to eliminate wrong answers

Option A is wrong because Cosign is a tool for signing and verifying container image signatures, not for enforcing admission policies based on registry origin. Option B is wrong because Notary is a framework for managing and signing image metadata (e.g., using TUF), but it does not act as a Kubernetes admission controller to block images from specific registries. Option C is wrong because Trivy is a vulnerability scanner for container images and filesystems; it does not enforce admission control policies on which registries can be used.

Full explanation →

235

MCQmedium

An admin wants to scan a local filesystem for vulnerabilities using Trivy. Which command should they use?

A.trivy image

B.trivy config

C.trivy fs

D.trivy repo

AnswerC

`trivy fs` is the correct subcommand to scan a local filesystem, as it takes a directory path and analyzes OS packages, language-specific dependencies, and other artifacts against Trivy's vulnerability database. It works without a container runtime and can be pointed at a source tree or a whole root filesystem, making it ideal for CI pipelines or vulnerability audits of a machine.

Why this answer

`trivy fs` scans a local filesystem for vulnerabilities, misconfigurations, and secrets. This command is specifically designed to analyze directories and files on disk, making it the appropriate choice for scanning a local filesystem as described in the question.

Exam trap

The trap here is that candidates often confuse `trivy image` (for container images) with `trivy fs` (for filesystems), or assume `trivy config` covers all local scanning, when in fact each subcommand targets a distinct artifact type.

How to eliminate wrong answers

Option A is wrong because `trivy image` scans container images (e.g., Docker images) for vulnerabilities, not a local filesystem. Option B is wrong because `trivy config` scans Infrastructure as Code (IaC) files (e.g., Terraform, Kubernetes YAML) for misconfigurations, not general filesystem vulnerabilities. Option D is wrong because `trivy repo` scans a remote Git repository for vulnerabilities, not a local filesystem.

Full explanation →

236

MCQmedium

A security analyst notices that a Falco rule intended to detect writes to /etc inside containers is generating alerts for a legitimate application that writes to /etc/app/config. The analyst wants to refine the rule to exclude this specific path while still detecting other writes to /etc. Which Falco rule condition modification should be applied?

A.Add 'and not fd.directory = /etc/app' to the condition

B.Add 'and not proc.name = app' to the condition

C.Change the rule's priority from WARNING to NOTICE

D.Add 'and not fd.name = /etc/app/config' to the condition

AnswerD

Falco's rule condition language supports boolean operators like 'and not' to exclude specific events. Adding 'and not fd.name = /etc/app/config' will prevent alerts when the file descriptor name exactly matches that path, while still triggering for other writes under /etc. This is the precise way to create an exception for a known legitimate file.

Why this answer

Falco rules can be tuned with boolean conditions to exclude known legitimate activity. To suppress alerts for a specific file path, the condition should include a check that the file descriptor name does not equal that path. This maintains detection for all other writes to /etc while eliminating the false positive from the legitimate application's configuration file.

Exam trap

The trap here is using process-based exclusions or severity changes instead of path-based exclusions, which either over-suppress or fail to suppress the false positive.

Full explanation →

237

MCQeasy

Which audit policy level logs the request metadata and the request body?

A.None

B.Metadata

C.RequestResponse

D.Request

AnswerD

The Request audit level provides all the metadata fields from the Metadata level and also includes the request body, enabling an administrator to see the exact payload the client submitted. It deliberately omits the response body, so the audit log does not capture what data the apiserver returned. This makes Request the precise answer for the question, which asks for request metadata plus the request body.

Why this answer

In Kubernetes audit logging, the 'Request' level logs both the request metadata (e.g., user, timestamp, resource) and the request body (the full object sent in the API request). This level provides detailed information about the operation without including the response body, which is reserved for the 'RequestResponse' level.

Exam trap

Kubernetes often tests the distinction between 'Request' and 'RequestResponse' levels, where candidates mistakenly choose 'RequestResponse' because they think it includes the request body, but the question specifically asks for only the request metadata and request body, not the response body.

How to eliminate wrong answers

Option A is wrong because 'None' logs no audit events at all, so it captures neither metadata nor the request body. Option B is wrong because 'Metadata' logs only the request metadata (e.g., user, timestamp, resource) but explicitly excludes the request body. Option C is wrong because 'RequestResponse' logs both the request metadata, request body, and the response body, which is more verbose than what the question asks for (only request metadata and request body).

Full explanation →

238

MCQmedium

You need to ensure that all containers in your cluster run with a read-only root filesystem. Which field should be set in the container's security context?

A.readOnlyRootFilesystem: true

B.allowPrivilegeEscalation: false

C.capabilities.drop: ['ALL']

D.runAsNonRoot: true

AnswerA

readOnlyRootFilesystem: true mounts the container's root filesystem as read-only, preventing processes from writing to binaries, libraries, or configuration files. This blocks runtime tampering with the container's filesystem layer. Note that writable tmpfs mounts or volumes are still allowed, but the root filesystem itself is immutable.

Why this answer

Setting `readOnlyRootFilesystem: true` in the container's security context mounts the container's root filesystem as read-only, preventing any writes to the root filesystem. This directly enforces the requirement that all containers run with a read-only root filesystem, which is a key supply chain security control to limit the impact of a compromised container.

Exam trap

This question tests the distinction between security context fields that limit privileges (like allowPrivilegeEscalation or capabilities.drop) and those that enforce filesystem immutability (readOnlyRootFilesystem). Candidates often confuse privilege reduction with filesystem write protection.

How to eliminate wrong answers

Option B is wrong because `allowPrivilegeEscalation: false` prevents a process from gaining more privileges than its parent (e.g., via setuid binaries), but it does not make the root filesystem read-only. Option C is wrong because `capabilities.drop: ['ALL']` removes all Linux capabilities from the container, reducing its privileges, but it does not affect the writability of the root filesystem. Option D is wrong because `runAsNonRoot: true` forces the container to run as a non-root user, which limits the impact of a compromise, but it does not prevent writes to the root filesystem.

Full explanation →

239

MCQhard

A ClusterRoleBinding grants cluster-admin to a service account in the 'kube-system' namespace. What is the best way to audit this for least privilege?

A.Use 'kubectl auth can-i --list' to check the service account's permissions.

B.Delete the ClusterRoleBinding immediately.

C.Run 'kubectl get clusterrolebindings' to list all bindings.

D.Review the permissions granted by cluster-admin and create a custom Role with only necessary permissions, then bind it.

AnswerD

The cluster-admin ClusterRole aggregates all core and custom resource permissions, including wildcard verbs and resources, and is intended for break-glass or node-level operations, not for routine service account workloads. By auditing the precise API resources and verbs the workload calls (e.g., using audit logs or kubectl auth can-i --list), you can construct a Role with minimal allow rules and bind it via a RoleBinding (for namespaced scope) or a ClusterRoleBinding (if truly cluster-scoped) limiting the subject to that service account. This aligns with the NIST least privilege principle and reduces the blast radius if the service account is compromised.

Why this answer

The cluster-admin ClusterRole grants superuser access across all namespaces, which violates the principle of least privilege. The best practice is to review the specific permissions required by the service account, create a custom Role with only those necessary permissions, and bind it via a RoleBinding or ClusterRoleBinding scoped appropriately. This minimizes the attack surface and aligns with Kubernetes RBAC hardening guidelines.

Exam trap

The trap here is that candidates may think simply listing or checking permissions (Options A or C) is sufficient for auditing, when the core requirement is to reduce permissions to the minimum necessary, which involves creating a custom Role.

How to eliminate wrong answers

Option A is wrong because 'kubectl auth can-i --list' only shows what the current user can do, not the permissions of a specific service account; to check a service account's permissions, you must use '--as' impersonation or inspect the RBAC bindings directly. Option B is wrong because immediately deleting the ClusterRoleBinding without understanding the service account's actual needs could break critical cluster functionality, such as controllers or add-ons running in kube-system. Option C is wrong because simply listing all ClusterRoleBindings does not audit for least privilege; it only provides a list without analyzing whether the bound permissions are excessive.

Full explanation →

240

MCQmedium

You need to configure Kubernetes audit logging to log all requests at the Metadata level for a specific namespace. Which audit policy level should you use?

A.Request

B.None

C.RequestResponse

D.Metadata

AnswerD

The Metadata audit level logs request metadata such as the user, groups, verb, resource, source IP, and response status, but it deliberately omits both request and response bodies. This is the correct choice for logging all requests because it provides a complete record of who did what and when for security review, without capturing the sensitive contents that would be written to disk. It is the recommended level in the Kubernetes audit policy as the default catch-all, balancing security, compliance, and data minimization.

Why this answer

The Metadata audit level logs request metadata (who, when, what resource, verb, etc.) but not the request or response body. This is exactly what is needed to log all requests at the Metadata level for a specific namespace. The other levels either log too much (Request, RequestResponse) or nothing (None).

Exam trap

CKS often tests the distinction between audit levels, and candidates may confuse 'Request' with 'Metadata' because both log requests, but only Metadata omits the request body.

How to eliminate wrong answers

Option A (Request) is wrong because it logs the request body in addition to metadata, which exceeds the requirement to log only at the Metadata level. Option B (None) is wrong because it disables audit logging entirely for the specified resources, providing no audit trail. Option C (RequestResponse) is wrong because it logs both the request and response bodies, which is more verbose than Metadata and not required here.

Full explanation →

241

Multi-Selectmedium

Which TWO admission plugins should be enabled to improve cluster security according to CIS benchmarks? (Choose two.)

Select 2 answers

A.PodSecurity

B.NodeRestriction

C.NamespaceLifecycle

D.PodSecurityPolicy

E.ServiceAccount

AnswersA, B

This admission plugin enforces the Pod Security Standards (baseline, restricted, privileged) by evaluating pod specifications against configured levels and policies at creation time. It replaces the deprecated PodSecurityPolicy and is a built-in, stable mechanism to prevent workloads from running with excessive privileges, thus directly improving cluster security.

Why this answer

PodSecurity is correct because it replaces the deprecated PodSecurityPolicy (PSP) and enforces the Pod Security Standards (baseline, restricted, privileged) via admission webhooks or built-in admission controllers. This prevents pods from running with excessive privileges, such as privileged containers or hostPath mounts, directly aligning with CIS benchmarks for Kubernetes hardening. NodeRestriction is correct because it limits the Node and Pod objects a kubelet can modify, preventing a compromised node from escalating privileges or modifying other nodes' statuses, which is a key CIS control for node-level security.

Exam trap

CNCF often tests the distinction between PodSecurity (current) and PodSecurityPolicy (deprecated/removed), and candidates mistakenly choose PSP because they recall it from older CKA exams, not realizing CIS benchmarks now mandate PodSecurity.

Full explanation →

242

MCQhard

You are a security engineer at a fintech startup. The company runs a Kubernetes cluster in production with hundreds of microservices. Recently, a container image from a public registry was compromised, and the attacker injected a backdoor that exfiltrated customer data. The CISO mandates that all images must come from an internal registry that only stores approved, scanned, and signed images. Currently, developers build images locally and push them to Docker Hub, then reference those images in Kubernetes manifests. You have deployed Harbor as a private registry with vulnerability scanning and Cosign for signing. However, you notice that some pods are still running images directly from Docker Hub. You need to enforce that only images from your internal Harbor registry can be used in the cluster. You cannot change the Kubernetes manifests immediately because of a large backlog. You have access to the cluster's kubelet configuration and can modify cluster-level components. Which single action will most effectively block any pod that tries to use an image not hosted on your internal registry?

A.Enforce a PodSecurityStandard that restricts containers from running with root privileges.

B.Apply a Kubernetes NetworkPolicy that blocks egress traffic from nodes to Docker Hub.

C.Configure the containerd configuration on each node to use Harbor as a mirror for all registries and set endpoint to Harbor only, disabling direct pull from public registries.

D.Deploy an admission webhook (e.g., OPA/Gatekeeper) that denies pods whose image registry is not the internal Harbor.

AnswerC

Configuring containerd to use Harbor as a mirror and setting endpoint to Harbor only forces all image pulls to go through the internal registry. This works at the runtime level and doesn't require changes to manifests, making it the most immediate and effective solution.

Why this answer

Configuring containerd to use Harbor as a mirror for all registries and setting the endpoint to Harbor only effectively blocks pulls from any external registry at the container runtime level. This approach works even if Kubernetes manifests reference Docker Hub images, as the kubelet will redirect all image pull requests to the internal Harbor registry, preventing direct pulls from public registries. It enforces the policy without requiring immediate changes to existing manifests, which aligns with the constraint of not modifying them due to a large backlog.

Option D (admission webhook) would require either modification of existing manifests or the webhook to deny pods that do not use the internal registry, but since manifests cannot be changed immediately, this would not affect already running pods unless they are recreated, making it less effective than runtime configuration. Option B (NetworkPolicy) only blocks network traffic but does not prevent the kubelet from pulling images from Docker Hub if the registry is reachable via a different path, and cached images can still be used.

Exam trap

CNCF often tests the distinction between admission control (webhooks) and runtime enforcement (container runtime configuration), where candidates mistakenly choose an admission webhook because it seems like a direct policy enforcement tool, but the question explicitly states that manifests cannot be changed immediately, making runtime-level enforcement the only viable option to block pulls without modifying existing resources.

How to eliminate wrong answers

Option A is wrong because PodSecurityStandard restricting root privileges does not control which image registry is used; it only enforces security context constraints on containers, not image source validation. Option B is wrong because a Kubernetes NetworkPolicy that blocks egress traffic to Docker Hub only prevents network-level communication from nodes to Docker Hub, but it does not prevent the kubelet or container runtime from pulling images if the DNS resolution or caching still allows it; moreover, it does not block pulls from other public registries and can be bypassed if the image is cached locally. Option D is wrong because deploying an admission webhook like OPA/Gatekeeper would require modifying Kubernetes manifests or applying policies that could be circumvented if the webhook is not properly configured or if there is a delay in policy enforcement; it also does not address the immediate need to block images without changing manifests, as the webhook would deny pods at admission time but does not prevent runtime pulls if the image is already cached or if the webhook is bypassed.

Full explanation →

243

Multi-Selecteasy

Which TWO of the following are best practices for securing container images?

Select 2 answers

A.Always use the latest tag

B.Use minimal base images like distroless

C.Run containers as root

D.Run containers in privileged mode

E.Use image vulnerability scanning

AnswersB, E

Distroless base images contain only the application and its runtime libraries, omitting shells, package managers, and compilers. This dramatically reduces the attack surface because an attacker who gains code execution has no interactive shell, no apt/yum, and no build toolchain to pivot with, and there are fewer packages to scan for known vulnerabilities. They also encourage running as non-root and keeping the filesystem read-only.

Why this answer

Minimal base images like distroless reduce the attack surface by eliminating unnecessary packages, libraries, and shell access. This aligns with the principle of least functionality, making it harder for attackers to exploit vulnerabilities or execute arbitrary commands within the container. Distroless images typically contain only the application and its runtime dependencies, significantly lowering the risk of privilege escalation or lateral movement.

Exam trap

CNCF often tests the misconception that using the 'latest' tag is safe or recommended, when in fact it is a security anti-pattern that undermines image integrity and reproducibility.

Full explanation →

244

MCQmedium

A security team wants to automatically reject any Pod that uses an image tagged with 'latest'. Which tool can be used to define this policy at the admission level?

A.ResourceQuota

B.NetworkPolicy

C.PodSecurityPolicy (PSP)

D.OPA/Gatekeeper

AnswerD

OPA/Gatekeeper is a validating admission webhook that integrates with Kubernetes' AdmissionReview API, allowing you to define custom policies as ConstraintTemplates written in Rego. These policies can inspect every field in the Pod spec, including container image references, and either mutate or reject the request at admission time. By writing a Rego rule that denies any image whose tag equals 'latest' (or that lacks an explicit tag), Gatekeeper can automatically reject violating pods before they are persisted, making it the correct tool for this requirement.

Why this answer

OPA/Gatekeeper is the correct tool because it allows you to define and enforce custom admission control policies via ConstraintTemplates and Constraints. You can create a policy that rejects any Pod using an image tagged with 'latest' by inspecting the `spec.containers[].image` field at admission time, which is not possible with native Kubernetes resources.

Exam trap

A common misconception is that PodSecurityPolicy (PSP) can enforce image-related policies, but PSP is deprecated and handles only security context constraints, not image tags or registries.

How to eliminate wrong answers

Option A is wrong because ResourceQuota only limits aggregate resource consumption (CPU, memory, storage, count) per namespace and cannot inspect or reject Pods based on image tags. Option B is wrong because NetworkPolicy controls network traffic between Pods and Services at L3/L4, not admission decisions about Pod specifications. Option C is wrong because PodSecurityPolicy (PSP) is deprecated and only restricts security context settings (e.g., privileged containers, host namespaces, SELinux), not image tags.

Full explanation →

245

MCQeasy

Which kube-apiserver flag enables audit logging?

A.--audit-log-path

B.--audit-log-dir

C.--enable-audit

D.--audit-policy-file

AnswerA

Setting --audit-log-path to a file path tells the kube-apiserver to write audit records to that file, thereby enabling the file audit backend. It is the flag that turns on audit logging output; without it, even if you define a policy, the apiserver has no destination for the audit events and emits nothing. You can combine it with rotation flags like --audit-log-maxsize and --audit-log-maxbackup to manage the log file.

Why this answer

The `--audit-log-path` flag is the correct kube-apiserver flag to enable audit logging because it specifies the file path where audit logs are written. When this flag is set, the API server starts recording audit events to the designated file, effectively enabling the audit logging feature. Without this flag, audit logging is disabled by default, even if other audit-related flags like `--audit-policy-file` are provided.

Exam trap

The trap here is that candidates often confuse `--audit-policy-file` (which defines what to log) with the flag that actually enables logging, or they assume a non-existent `--enable-audit` flag exists because other Kubernetes components use similar enable flags.

How to eliminate wrong answers

Option B is wrong because `--audit-log-dir` is not a valid kube-apiserver flag; the correct flag for specifying a directory is `--audit-log-path`, which accepts a full file path, not a directory. Option C is wrong because `--enable-audit` does not exist as a kube-apiserver flag; audit logging is implicitly enabled when `--audit-log-path` is set, and there is no separate boolean flag to enable it. Option D is wrong because `--audit-policy-file` defines the audit policy rules (what events to log) but does not enable audit logging itself; audit logging remains disabled unless `--audit-log-path` is also specified.

Full explanation →

246

MCQeasy

Which Kubernetes resource is used to define audit logging configuration?

A.A YAML file specified via `--audit-policy-file`

B.PodSecurityPolicy

C.ConfigMap in kube-system

D.AuditPolicy CRD

AnswerA

The kube-apiserver's audit logging behavior is governed by a YAML policy file located on the apiserver's host filesystem, whose path is passed via the `--audit-policy-file` startup flag. This file is not a Kubernetes API resource; it is a plain configuration file containing a set of rules that map requested attributes (verbs, resources, namespaces, users) to audit levels: None, Metadata, Request, or RequestResponse. The apiserver reads this file at initialization and applies it to all incoming API requests, so changing the policy requires editing the file and restarting the apiserver.

Why this answer

Kubernetes audit logging configuration is defined in a YAML file that specifies the audit policy rules, and this file is passed to the kube-apiserver via the `--audit-policy-file` command-line flag. This YAML file defines which events (e.g., requests to the API server) should be logged and at what level (e.g., Metadata, Request, RequestResponse). No other Kubernetes resource or CRD is used for this purpose.

Exam trap

The trap here is that candidates confuse the audit policy configuration mechanism (a static YAML file passed via `--audit-policy-file`) with a Kubernetes resource like a ConfigMap or CRD, because many other Kubernetes configurations (e.g., kubelet config, scheduler policies) are indeed stored in ConfigMaps or custom resources.

How to eliminate wrong answers

Option B is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) is a cluster-level resource that controls security-sensitive aspects of pod specification (e.g., privilege escalation, host namespaces), not audit logging configuration. Option C is wrong because a ConfigMap in kube-system is a generic resource for storing configuration data (e.g., environment variables, small files) and is not the mechanism for defining audit logging policies; while a ConfigMap could theoretically hold the audit policy content, the kube-apiserver does not read audit policy from a ConfigMap—it must be a file on disk referenced by `--audit-policy-file`. Option D is wrong because there is no standard Kubernetes CRD named 'AuditPolicy'; audit logging is configured via a static YAML file, not a custom resource definition.

Full explanation →

247

MCQeasy

Which flag enables the NodeRestriction admission plugin on the API server?

A.--enable-admission-plugins=NodeRestriction

B.--admission-control=NodeRestriction

C.--kubelet-restriction=NodeRestriction

D.--node-restriction=true

AnswerA

NodeRestriction is an admission plugin that ensures the kubelet can only modify its own Node object and its own Pods (and only those bound to it). On a modern kube-apiserver, the `--enable-admission-plugins` flag takes a comma-separated list of plugin names to turn on, so `--enable-admission-plugins=NodeRestriction` is the exact syntax. This flag is appended to the API server's startup parameters, either in a static pod manifest or systemd unit. Without this flag, NodeRestriction is not active by default, which is why it must be explicitly enabled.

Why this answer

The `--enable-admission-plugins` flag is the correct parameter to activate admission controllers in the kube-apiserver. The NodeRestriction plugin limits the Node and Pod objects a kubelet can modify, enforcing the principle of least privilege. Option A correctly uses this flag with the plugin name.

Exam trap

The trap here is that candidates confuse the deprecated `--admission-control` flag with the current `--enable-admission-plugins` flag, or they invent non-existent flags like `--kubelet-restriction` or `--node-restriction` that sound plausible but are not valid API server options.

How to eliminate wrong answers

Option B is wrong because `--admission-control` is a deprecated flag from older Kubernetes versions (pre-1.10) and is no longer supported; the correct flag is `--enable-admission-plugins`. Option C is wrong because `--kubelet-restriction` is not a valid kube-apiserver flag; it does not exist in the Kubernetes API server options. Option D is wrong because `--node-restriction` is not a valid boolean flag; the NodeRestriction feature is an admission plugin, not a simple boolean toggle.

Full explanation →

248

Multi-Selecthard

Which three of the following are valid ways to enforce supply chain security in a Kubernetes cluster? (Select THREE.)

Select 3 answers

A.Use Cosign to sign images and configure verification in the cluster

B.Configure ImagePolicyWebhook to reject images from untrusted registries

C.Use ResourceQuota to limit the number of images that can be pulled

D.Use NetworkPolicy to block egress traffic to unknown registries

E.Use OPA/Gatekeeper to enforce that container images come from an allowed list of registries

AnswersA, B, E

Cosign lets you sign container images with a private key or use sigstore's keyless flow, then store the signature in a registry alongside the image. To enforce in the cluster, you pair Cosign with an admission controller such as the sigstore policy-controller, which verifies the signature on the image manifest during pod creation. Only images signed by trusted keys are admitted, blocking tampered or unofficial images directly at the API server.

Why this answer

A is correct because Cosign is a tool for signing container images using cryptographic keys, and by integrating it with Kubernetes admission controllers (e.g., via the Cosign webhook or Kyverno), the cluster can verify image signatures before allowing a pod to run. This ensures that only images signed by trusted parties are deployed, directly enforcing supply chain integrity.

Exam trap

The CKS exam often tests the distinction between resource management (ResourceQuota) and security controls (image verification), and the trap here is that candidates confuse limiting pull counts with enforcing image trust, or assume NetworkPolicy can filter by registry identity when it only works at the IP/port level.

Full explanation →

249

MCQhard

An incident responder needs to isolate a compromised pod immediately without deleting it. Which action should they take?

A.Modify the pod's labels to prevent it from receiving traffic

B.Delete the pod to stop its activity

C.Apply a NetworkPolicy that denies all traffic to and from the pod's labels

D.Scale down the deployment to zero replicas

AnswerC

Applying a NetworkPolicy that selects the compromised pod's labels and declares policyTypes: [Ingress, Egress] with no ingress or egress rules establishes an immediate default-deny boundary. The CNI enforces this at the data path, blocking all existing and new connections while leaving the pod and its logs, memory, and filesystem untouched for forensic analysis. This is the correct incident response because it contains the blast radius without destroying evidence.

Why this answer

Applying a NetworkPolicy that denies all ingress and egress traffic to the pod's labels is the correct isolation action because it preserves the pod for forensic analysis while cutting off all network communication. Kubernetes NetworkPolicy operates at the pod-selector level, so a default-deny policy targeting the compromised pod's labels immediately blocks both inbound and outbound traffic without touching the pod's lifecycle. This satisfies the incident responder's requirement to isolate without deleting, keeping volatile memory and container state intact for investigation.

Exam trap

CKS often tests the distinction between 'isolate' and 'delete' — candidates instinctively pick deletion or label changes as the fastest containment, missing that NetworkPolicy default-deny is the only option that preserves the pod for forensics while cutting all traffic.

How to eliminate wrong answers

Option A is wrong because modifying labels only affects which services or selectors match the pod; it does not stop existing connections or prevent the pod from initiating outbound traffic, and it may break forensic tooling that relies on labels. Option B is wrong because deleting the pod destroys volatile evidence (memory, running processes, network connections) and violates the explicit requirement to isolate without deleting; the ReplicaSet would also recreate it. Option D is wrong because scaling the deployment to zero deletes all pods including the compromised one, again destroying evidence and affecting other replicas rather than isolating a single pod.

Full explanation →

250

Multi-Selecthard

Which THREE of the following are correct statements about Kubernetes admission controllers in the context of supply chain security? (Select 3)

Select 3 answers

A.Admission controllers are executed in a specific order that can affect the final state of the resource

B.ValidatingAdmissionWebhook can be used to enforce policies like requiring all images to be signed

C.MutatingAdmissionWebhook can only modify pods, not other resources

D.ImagePolicyWebhook is used to validate container images against an external policy

E.OPA/Gatekeeper uses MutatingAdmissionWebhook to enforce policies

AnswersA, B, D

The order of admission controllers can impact the final resource, especially when mutating and validating are mixed.

Why this answer

Admission controllers are executed in a specific order: mutating controllers run first, then validating controllers. This ordering is critical because a mutating webhook can modify the resource before a validating webhook evaluates it, potentially bypassing intended policies if the order is not carefully managed. The Kubernetes API server processes admission controllers sequentially based on the order defined in the API server flags or the built-in chain, which directly affects the final resource state.

Exam trap

A common misconception is that MutatingAdmissionWebhook is limited to pods, when in fact it can intercept and mutate any Kubernetes resource type. Another is that OPA/Gatekeeper relies on mutating webhooks, whereas its primary enforcement mechanism is validating webhooks.

Full explanation →

251

Multi-Selecthard

Which THREE of the following are valid ways to restrict access to etcd? (Select 3)

Select 3 answers

A.Enable etcd RBAC to restrict read/write access

B.Use HTTP instead of HTTPS

C.Disable client authentication for simplicity

D.Use firewall rules to restrict network access to etcd

E.Use TLS client certificates for authentication

AnswersA, D, E

Enabling etcd RBAC lets cluster administrators create users and roles that specify which key prefixes a client may read or write. Because etcd stores the entire Kubernetes cluster state—including secrets, configmaps, and service account tokens—RBAC provides a granular gate that complements the coarse access offered by network and TLS controls. This is a legitimate way to restrict both read and write operations to specific key spaces.

Why this answer

Etcd supports Role-Based Access Control (RBAC) that allows you to define roles and permissions to restrict read and write access to keys. By enabling etcd RBAC, you can enforce fine-grained authorization, ensuring that only authenticated and authorized clients (e.g., the Kubernetes API server) can perform specific operations on etcd data.

Exam trap

CNCF often tests the misconception that disabling security features (like authentication or encryption) can simplify access control, but in reality, these features are essential for restricting access, and candidates may incorrectly think that network-level controls alone are insufficient or that HTTP is acceptable for internal traffic.

Full explanation →

252

MCQeasy

A DevOps engineer wants to ensure that all microservice containers run with a read-only root filesystem to prevent unauthorized writes. What is the simplest way to enforce this at the Pod level?

A.Set `securityContext.runAsNonRoot: true` in the Pod spec

B.Mount an emptyDir volume to the container's writable directories

C.Set `securityContext.readOnlyRootFilesystem: true` in the Pod spec

D.Set `securityContext.privileged: false` in the Pod spec

AnswerC

Setting readOnlyRootFilesystem: true instructs the container runtime to mount the container's root filesystem as read-only, so no process can create, delete, or modify files in the root layer. This is the precise securityContext field that the requirement asks for, and it works regardless of the UID the container runs as. Any process that needs to write temporary data must have explicit writable volumes, such as emptyDir, mounted over required paths.

Why this answer

Setting `securityContext.readOnlyRootFilesystem: true` in the Pod spec directly enforces that the container's root filesystem is read-only, preventing any unauthorized writes to the root filesystem. This is the simplest and most direct way to achieve the requirement at the Pod level, as it applies to all containers in the Pod unless overridden at the container level.

Exam trap

CNCF often tests the distinction between security contexts that control user identity (runAsNonRoot) versus those that control filesystem permissions (readOnlyRootFilesystem), and the trap here is that candidates may confuse 'non-root' with 'read-only' or assume that disabling privileged mode is sufficient to prevent writes.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot: true` only ensures the container runs as a non-root user, but does not restrict writes to the root filesystem; a non-root user can still write to writable directories. Option B is wrong because mounting an emptyDir volume to writable directories is a workaround to allow specific writes while keeping the root filesystem read-only, but it does not enforce the read-only root filesystem itself; the root filesystem remains writable unless explicitly set to read-only. Option D is wrong because `privileged: false` is the default and simply disables privileged mode, but it does not prevent writes to the root filesystem; a non-privileged container can still modify the root filesystem if it is not explicitly set to read-only.

Full explanation →

253

MCQeasy

Which annotation is used to apply an AppArmor profile to a pod?

A.apparmor.security.kubernetes.io/profile

B.security.kubernetes.io/apparmor

C.container.apparmor.security.beta.kubernetes.io/<container_name>

D.seccomp.security.alpha.kubernetes.io/pod

AnswerC

This is the correct annotation format. The key 'container.apparmor.security.beta.kubernetes.io/<container_name>' targets a specific container by name, and its value specifies the AppArmor profile to enforce, such as 'runtime/default' or 'localhost/<custom-profile>'. Although it is a beta annotation that has been superseded by the AppArmor field in the container's securityContext, it remains a valid and functional way to apply profiles on older or legacy Kubernetes versions.

Why this answer

The AppArmor profile for a container in a pod is specified using the annotation `container.apparmor.security.beta.kubernetes.io/<container_name>`, where `<container_name>` is the name of the container. This annotation, which was introduced in Kubernetes v1.4 as a beta feature, tells the kubelet to apply the referenced AppArmor profile (e.g., `localhost/k8s-apparmor-example`) to the specified container during runtime.

Exam trap

The trap here is that candidates confuse the AppArmor annotation with the seccomp annotation (option D) or invent a non-existent annotation (options A and B), because the exam often tests the exact syntax of these security annotations, which are easy to mix up due to similar naming patterns.

How to eliminate wrong answers

Option A is wrong because `apparmor.security.kubernetes.io/profile` is not a valid Kubernetes annotation; the correct prefix is `container.apparmor.security.beta.kubernetes.io/`. Option B is wrong because `security.kubernetes.io/apparmor` is not a recognized annotation for AppArmor; it resembles a generic security context key but does not exist in the Kubernetes API. Option D is wrong because `seccomp.security.alpha.kubernetes.io/pod` is the annotation used to apply a seccomp profile to a pod, not an AppArmor profile.

Full explanation →

254

Matchingmedium

Match each Kubernetes security component to its description.

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

Concepts

Matches

Admission controller that enforces security constraints on pods

Defines how groups of pods can communicate with each other and other network endpoints

Role-based access control for authorization within the cluster

Linux security facility to restrict system calls from a container

Mandatory access control system that confines programs to a limited set of resources

Why these pairings

RBAC controls permissions, Pod Security Admission enforces pod security, Network Policies manage traffic, and ServiceAccounts provide identity. Distractors confuse these functions.

Full explanation →

255

Multi-Selecthard

Which THREE Falco priority levels sequences are correctly ordered from lowest to highest severity? (Choose three)

Select 3 answers

A.WARNING, ERROR, CRITICAL, ALERT, EMERGENCY

B.DEBUG, INFORMATIONAL, NOTICE, WARNING

C.INFORMATIONAL, NOTICE, DEBUG, WARNING

D.ALERT, CRITICAL, ERROR, WARNING

E.NOTICE, WARNING, ERROR, CRITICAL

AnswersA, B, E

This sequence starts at WARNING and moves through ERROR, CRITICAL, ALERT, and EMERGENCY, which exactly matches Falco's ascending severity ranking for those levels. Each step denotes a progressively more serious security event, from a notable anomaly to a system-wide emergency requiring immediate response.

Why this answer

Options A, B, and E are correctly ordered from lowest to highest severity according to Falco's priority levels, which follow the standard syslog severity ordering (RFC 5424). Option A: WARNING, ERROR, CRITICAL, ALERT, EMERGENCY is correct. Option B: DEBUG, INFORMATIONAL, NOTICE, WARNING is correct.

Option E: NOTICE, WARNING, ERROR, CRITICAL is correct. Options C and D are incorrectly ordered (C has DEBUG after NOTICE, and D starts with ALERT which is higher than ERROR).

Exam trap

The question asks to choose three correct sequences; all three (A, B, E) are valid. Some candidates may mistakenly think that only two are correct due to the ordering complexities, but all three follow the correct ascending severity order.

Full explanation →

256

MCQmedium

In Kubernetes, you need to enforce a default deny-all network policy for pods in a specific namespace to ensure pods cannot communicate unless explicitly allowed by policy. Which resource should you create?

A.NetworkPolicy

B.ResourceQuota

C.LimitRange

D.RuntimeClass

AnswerA

A NetworkPolicy with an empty pod selector and both Ingress and Egress policyTypes set to deny enforces default deny-all for every pod in the namespace, satisfying the requirement that communication is blocked unless explicitly permitted. Kubernetes' native policy object operates at layer 3/4, matching the namespace-scoped constraint in the stem.

Why this answer

A NetworkPolicy is the Kubernetes resource that controls network traffic to and from pods. A default deny-all policy can be created by selecting all pods (e.g., using an empty podSelector) and omitting ingress/egress rules. ResourceQuota and LimitRange manage compute/resource usage, not network traffic, and RuntimeClass selects a container runtime configuration rather than enforcing network policy.

Exam trap

Candidates often confuse namespace-scoped controls: ResourceQuota and LimitRange limit resource consumption, while NetworkPolicy is the only one of these that enforces pod-to-pod network segmentation.

How to eliminate wrong answers

Option B (VirtualService) is wrong because it is used for traffic routing, such as canary deployments or A/B testing, not for setting authentication or mTLS policies. Option C (ServiceEntry) is wrong because it is used to register external services (outside the mesh) into the service mesh, not to enforce mTLS within the mesh. Option D (DestinationRule) is wrong because while it can define traffic policies including TLS settings, it applies to specific host-level traffic rules, not to set a namespace-wide default mTLS mode; PeerAuthentication is the intended resource for this purpose.

Full explanation →

257

MCQeasy

Falco detects a shell being opened inside a container. Which Falco rule field is used to specify the syscall condition for detection?

A.condition

B.priority

C.output

D.rule

AnswerA

The `condition` field in a Falco rule is the mandatory boolean filter expression that actually defines which events trigger the rule. For shell detection, it combines syscalls such as `evt.type=execve` with process and container fields (e.g., `proc.name in (bash, sh)` and `container.id != host`) to match a shell being opened inside a container. No other rule field performs event matching, so this is the correct place to encode the detection logic.

Why this answer

In Falco, the `condition` field within a rule defines the specific syscall or event filter that triggers the rule. For detecting a shell being opened inside a container, the condition would include a syscall like `execve` or `clone` combined with container context filters such as `container.id != host`. This field is where you specify the exact syscall and its parameters (e.g., `evt.type=execve and proc.name in (bash, sh, zsh)`), making it the correct answer.

Exam trap

The CKS exam often tests the distinction between the `condition` field (which holds the detection logic) and the `rule` field (which is just a label), causing candidates to confuse the rule name with the filtering criteria.

How to eliminate wrong answers

Option B is wrong because `priority` is used to set the severity level of the rule (e.g., CRITICAL, WARNING) and does not define the syscall condition. Option C is wrong because `output` specifies the formatted alert message or action (e.g., stdout, syslog) when the rule triggers, not the detection logic. Option D is wrong because `rule` is the name or identifier of the Falco rule (e.g., 'Terminal shell in container'), not the field containing the syscall condition.

Full explanation →

258

Multi-Selectmedium

Which THREE of the following are valid arguments for etcd encryption at rest?

Select 3 answers

A.kms

B.identity

C.base64

D.secretbox

E.aescbc

AnswersA, D, E

The kms argument enables envelope encryption, where the Kubernetes API server delegates data encryption keys to an external Key Management Service provider. This satisfies the requirement for encryption at rest by keeping key material outside etcd, unlike the local aescbc or secretbox providers.

Why this answer

The question asks for valid encryption providers for etcd encryption at rest in Kubernetes, which are configured via the --encryption-provider-config flag. Option A, kms, is correct because the KMS provider integrates with an external Key Management Service (e.g., via a gRPC plugin) to perform envelope encryption, keeping the data encryption key outside the cluster. Option D, secretbox, is correct because it uses the XSalsa20-Poly1305 authenticated encryption algorithm from NaCl and is a supported provider in the encryption configuration.

Option E, aescbc, is correct because it implements AES-CBC with PKCS#7 padding and is one of the standard providers (though it requires a 32-byte key and is not authenticated). Option B, identity, is not a valid encryption provider for securing data at rest; it is a no-op that stores values in plaintext and is only used as a fallback or for reading unencrypted data. Option C, base64, is not an encryption provider at all; it is merely an encoding scheme and provides no confidentiality, so it cannot be used to encrypt etcd data.

Exam trap

Candidates often confuse encoding (base64) or identity (no encryption) with actual encryption providers, or mistakenly think KMS is not a valid etcd encryption provider when it is one of the supported providers alongside aescbc and secretbox.

Full explanation →

259

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.

Full explanation →

260

MCQmedium

A cluster administrator needs to run a workload that uses gVisor (runsc) for container sandboxing. Which Kubernetes resource is required to enable this?

A.RuntimeClass

B.PriorityClass

C.NetworkPolicy

D.PodSecurityPolicy

AnswerA

RuntimeClass is a cluster-level resource that defines a handler (e.g., 'runsc' or 'gvisor') that the Kubernetes node's CRI runtime should use to launch the pod. A pod can reference a RuntimeClass via `spec.runtimeClassName`, and the kubelet then passes the handler to the runtime (like containerd) to run the container with that specific runtime engine. This is precisely how gVisor is selected, since multiple runtimes can be installed on the same node and chosen per-pod. Importantly, the RuntimeClass must be created by an administrator, and the handler must match a runtime configured on the node.

Why this answer

A RuntimeClass resource is required to enable gVisor (runsc) because it defines the container runtime configuration that should be used for pods. By creating a RuntimeClass with the handler set to 'runsc', the cluster administrator can instruct the kubelet to use gVisor as the OCI-compatible runtime for sandboxing, providing an additional security layer through a user-space kernel.

Exam trap

The trap here is that candidates confuse RuntimeClass with PodSecurityPolicy or PriorityClass, thinking that sandboxing is enforced through security policies or scheduling priorities, rather than understanding that RuntimeClass is the explicit Kubernetes resource for selecting a different container runtime per pod.

How to eliminate wrong answers

Option B (PriorityClass) is wrong because it manages pod scheduling priority and preemption, not container runtime selection. Option C (NetworkPolicy) is wrong because it controls network traffic rules between pods, not the underlying container runtime or sandboxing mechanism. Option D (PodSecurityPolicy) is wrong because it enforces security constraints on pod specifications (e.g., privileged containers, host namespaces), but does not configure which OCI runtime (like runsc) is used to run the containers.

Full explanation →

261

MCQmedium

Which of the following commands creates a ValidatingWebhookConfiguration that uses an OPA Gatekeeper webhook?

A.kubectl apply -f validatingwebhook.yaml where the webhook's service reference points to the gatekeeper-validating-webhook service.

B.kubectl apply -f constraint.yaml with a ConstraintTemplate.

C.kubectl create validatingwebhook gatekeeper --from-file=webhook.yaml

D.kubectl run gatekeeper-webhook --image=openpolicyagent/gatekeeper:v3.14.0

AnswerA

This is correct because Gatekeeper's admission webhook is implemented as a Kubernetes ValidatingWebhookConfiguration, which is a cluster-scoped API object created declaratively with kubectl apply. The configuration references the gatekeeper-validating-webhook service by name and namespace, telling the API server to forward matching admission requests to that service's HTTPS endpoint. Applying the YAML file registers the webhook with the API server, enabling policy enforcement during pod creation and updates.

Why this answer

A ValidatingWebhookConfiguration in Kubernetes must reference a service that handles the admission review request. OPA Gatekeeper exposes its webhook via the `gatekeeper-validating-webhook` service, which listens for `AdmissionReview` requests on the `/v1/admit` endpoint. Applying a YAML manifest that correctly specifies this service reference in the `clientConfig.service` field creates the necessary webhook configuration to integrate Gatekeeper.

Exam trap

This exam often tests the distinction between creating the Kubernetes resource that registers the webhook (ValidatingWebhookConfiguration) versus deploying the webhook server itself (Pod/Deployment), and candidates mistakenly think running the Gatekeeper container alone is sufficient to enable admission control.

How to eliminate wrong answers

Option B is wrong because `kubectl apply -f constraint.yaml` with a `ConstraintTemplate` creates a Gatekeeper constraint or template, not a ValidatingWebhookConfiguration; the webhook configuration must be created separately to register the external admission webhook with the API server. Option C is wrong because `kubectl create validatingwebhook gatekeeper --from-file=webhook.yaml` is not a valid kubectl command; kubectl does not have a `validatingwebhook` subcommand, and ValidatingWebhookConfigurations are created via `kubectl apply` or `kubectl create -f` with a YAML file. Option D is wrong because `kubectl run gatekeeper-webhook --image=openpolicyagent/gatekeeper:v3.14.0` only deploys a Pod running the Gatekeeper container, but does not create the ValidatingWebhookConfiguration resource that registers the webhook with the API server; without that registration, the API server will not forward admission requests to the Gatekeeper service.

Full explanation →

262

MCQhard

An administrator wants to set an immutable root filesystem for a container in a Pod. Which securityContext field should be set to true?

A.allowPrivilegeEscalation

B.readOnlyRootFilesystem

C.runAsNonRoot

D.privileged

AnswerB

Setting readOnlyRootFilesystem to true mounts the container's root filesystem as read-only, so any attempt by the container process to write, create, or delete files in / fails. This makes the root filesystem effectively immutable from the container's perspective because all write operations are blocked at the mount layer. Note that volumes can still be mounted writable, so immutability applies only to the root filesystem itself, not to data volumes.

Why this answer

The readOnlyRootFilesystem field, when set to true in a container's securityContext, mounts the container's root filesystem as read-only. This prevents any process inside the container from writing to the root filesystem, which is a key security hardening measure to prevent runtime modifications, such as an attacker downloading tools or modifying binaries. It directly addresses the requirement for an immutable root filesystem.

Exam trap

CKS often tests the confusion between readOnlyRootFilesystem and other securityContext fields like allowPrivilegeEscalation or runAsNonRoot, where candidates might incorrectly associate privilege escalation or user ID with filesystem immutability.

How to eliminate wrong answers

Option A is wrong because allowPrivilegeEscalation controls whether a process can gain more privileges than its parent (e.g., via setuid or setgid binaries), not filesystem immutability. Option C is wrong because runAsNonRoot ensures the container runs as a non-root user, which is unrelated to making the root filesystem read-only. Option D is wrong because privileged grants the container almost all capabilities of the host, effectively disabling isolation, and does not set the root filesystem to read-only.

Full explanation →

263

MCQeasy

Which Pod Security Standard level allows the use of hostNetwork, hostPID, and hostIPC?

A.None of the above

B.Baseline

C.Privileged

D.Restricted

AnswerC

The Privileged level is intentionally the most permissive Pod Security Standard, imposing no restrictions on the pod's security context or namespace usage. It explicitly permits access to host namespaces, so setting hostNetwork to true is allowed without any policy interference. This is why Privileged is the only standard among the three that satisfies the requirement in the question.

Why this answer

The Privileged Pod Security Standard (PSS) level is the most permissive, allowing unrestricted access to host-level resources, including hostNetwork, hostPID, and hostIPC. These settings grant the pod direct access to the host's network namespace, process table, and inter-process communication mechanisms, which are explicitly prohibited in the Baseline and Restricted levels. The Privileged level is designed for system-level workloads that require such elevated permissions, such as CNI plugins or monitoring agents.

Exam trap

CNCF often tests the misconception that Baseline allows host-level namespace sharing, when in fact Baseline only permits a limited set of non-host-level privileges, while hostNetwork, hostPID, and hostIPC are exclusive to the Privileged level.

How to eliminate wrong answers

Option A is wrong because 'None of the above' is incorrect; the Privileged level explicitly allows hostNetwork, hostPID, and hostIPC. Option B is wrong because the Baseline level prohibits hostNetwork, hostPID, and hostIPC by default, as defined in the Kubernetes Pod Security Standards documentation. Option D is wrong because the Restricted level is the most restrictive, enforcing the strongest security controls and disallowing all host namespace sharing, including hostNetwork, hostPID, and hostIPC.

Full explanation →

264

MCQmedium

Which command would you run to check if anonymous authentication is enabled on the API server?

A.ps aux | grep kube-apiserver | grep anonymous-auth

B.kubectl get nodes -o yaml | grep anonymous

C.kubectl describe configmap anonymous

D.kubectl get clusterrolebinding anonymous

AnswerA

It directly examines the kube-apiserver process arguments, where anonymous authentication is controlled by the --anonymous-auth flag (default true). Running this command shows whether the flag is explicitly set to false (disabling anonymous auth) or left unset (enabling it). This is the authoritative way to audit a running API server, because the effective configuration comes from the process launch parameters rather than cluster objects.

Why this answer

The `--anonymous-auth` flag on the kube-apiserver binary controls whether anonymous requests are allowed. Running `ps aux | grep kube-apiserver | grep anonymous-auth` directly inspects the running process arguments to see if the flag is set to `true` (enabled) or `false` (disabled). This is the most direct way to check the runtime configuration of the API server.

Exam trap

CNCF often tests the ability to distinguish between runtime process inspection and Kubernetes API resource queries, leading candidates to mistakenly use `kubectl` commands that query non-existent or irrelevant resources instead of checking the actual process arguments.

How to eliminate wrong answers

Option B is wrong because `kubectl get nodes -o yaml` retrieves node objects, which do not contain any information about the API server's authentication configuration. Option C is wrong because there is no standard Kubernetes resource called `configmap anonymous`; ConfigMaps are namespaced and unrelated to API server authentication settings. Option D is wrong because `ClusterRoleBinding` named `anonymous` does not exist by default; anonymous access is controlled by the `system:anonymous` user and `system:unauthenticated` group, not by a dedicated ClusterRoleBinding.

Full explanation →

265

MCQeasy

A DevOps team is tasked with upgrading a Kubernetes cluster from version 1.21 to 1.22. They want to minimize downtime and follow best practices. Which approach should they take?

A.Upgrade worker nodes first, then the control plane

B.Upgrade etcd to 1.22 first, then the API server

C.Upgrade the control plane from 1.21 to 1.22 first, then upgrade worker nodes

D.Drain all nodes, then upgrade all components to 1.22 at once

AnswerC

This is the supported upgrade path because the kube-apiserver must run at a higher or equal minor version than all other control-plane components and kubelets. By upgrading the control plane from 1.21 to 1.22 first, the API server can continue serving the existing 1.21 worker nodes without any version-skew violation; the policy explicitly allows kubelet to lag the API server by exactly one minor version. After the control plane is stable and the cluster object store is on the new version, each worker node is cordoned, drained, upgraded to 1.22, and uncordoned. This rolling approach keeps the cluster functional throughout and matches the kubeadm upgrade sequence.

Why this answer

The Kubernetes upgrade process mandates upgrading the control plane first, as it is the authoritative source for cluster state and API operations. Worker nodes can then be upgraded to match the control plane version, ensuring compatibility and minimizing downtime by allowing workloads to continue running during the node upgrade phase.

Exam trap

The trap here is that candidates often assume upgrading worker nodes first is safer to avoid control plane downtime, but Kubernetes requires the control plane to be upgraded first to maintain version skew compatibility and cluster stability.

How to eliminate wrong answers

Option A is wrong because upgrading worker nodes before the control plane violates the Kubernetes version skew policy, which requires the control plane to be at the highest version; doing so could cause API server incompatibility with node components like kubelet. Option B is wrong because etcd is upgraded as part of the control plane upgrade process, not independently first, and the API server must be upgraded before or simultaneously with etcd to maintain cluster stability. Option D is wrong because draining all nodes before upgrading any component would cause unnecessary total cluster downtime, and upgrading all components at once ignores the required sequential upgrade order (control plane first, then nodes) and version skew support.

Full explanation →

266

Multi-Selectmedium

Which TWO of the following are valid AppArmor profile modes?

Select 2 answers

A.Complain

B.Enforce

C.Audit

D.Disable

E.Permissive

AnswersA, B

Complain mode logs AppArmor policy violations but still permits the action, unlike enforce which blocks it. It is a valid profile mode used to test policy before enforcing, satisfying the question's requirement for a genuine AppArmor mode.

Why this answer

Option A, Complain mode, is correct because AppArmor profiles can be set to complain (also called learning) mode, in which policy violations are logged but not blocked, allowing administrators to test and refine profiles. Option B, Enforce mode, is correct because it is the standard operational mode where the profile's rules are actively applied and violations are denied and logged. The unmarked options do not belong: Audit is not a profile mode (auditing is a logging behavior that occurs within complain or enforce modes), Disable is not a mode but rather the state of having no profile loaded or the profile removed, and Permissive is not an AppArmor term — it is the terminology used by SELinux, while AppArmor's equivalent is Complain.

Exam trap

The CKS exam often tests the distinction between AppArmor and SELinux modes; the trap here is that candidates confuse 'Permissive' (SELinux) with 'Complain' (AppArmor), or assume 'Audit' is a valid AppArmor mode because of the Linux audit subsystem.

Full explanation →

267

MCQmedium

You run 'trivy image myapp:latest' and the scan reports several critical CVEs. What is the best action to take?

A.Use kubectl delete pod to remove the running container

B.Delete the image from the registry

C.Rebuild the image with updated base images and re-deploy

D.Ignore the CVEs because the image is running in a non-production environment

AnswerC

Rebuilding the image with updated base images ensures that the vulnerable layers are replaced with patched versions, eliminating the reported CVEs. After rebuilding, re-deploying the workload (e.g., by updating the Deployment's image tag) forces nodes to pull the new image and run a clean container. This is the correct remediation because it addresses the root cause—vulnerable dependencies in the image—rather than mitigating symptoms.

Why this answer

Rebuilding the image with updated base images directly addresses the root cause of the CVEs—outdated or vulnerable packages in the container image. After rebuilding, you must re-deploy the updated image to replace the running vulnerable containers. This aligns with the supply chain security principle of maintaining a secure software bill of materials (SBOM) and ensuring images are patched against known vulnerabilities before deployment.

Exam trap

A common misconception is that deleting the pod or image is sufficient remediation, when the correct action is to patch the image at the source and re-deploy to eliminate the vulnerability from the running environment.

How to eliminate wrong answers

Option A is wrong because deleting the running pod does not fix the underlying vulnerable image; any new pod created from the same image will still have the same CVEs. Option B is wrong because deleting the image from the registry removes the artifact but does not remediate the running containers, which continue to execute the vulnerable code. Option D is wrong because ignoring CVEs in a non-production environment is still a security risk; vulnerabilities can be exploited to pivot to production systems, and the CKS exam emphasizes consistent security practices across all environments.

Full explanation →

268

MCQhard

During a security audit, you run kube-bench and find that the API server audit logging is not enabled. Which set of flags should be added to the kube-apiserver to enable audit logging with a policy file located at /etc/kubernetes/audit-policy.yaml?

A.--audit-log-path=/var/log/kubernetes/audit.log --audit-policy-file=/etc/kubernetes/audit-policy.yaml

B.--audit-log-maxage=30 --audit-policy-file=/etc/kubernetes/audit-policy.yaml

C.--audit-log-path=/var/log/kubernetes/audit.log --audit-log-maxbackup=10

D.--audit-log-path=/var/log/kubernetes/audit.log --audit-webhook-config-file=/etc/kubernetes/audit-policy.yaml

AnswerA

These two flags together are the minimal required configuration for Kubernetes audit logging. --audit-log-path specifies the file where audit events are appended; without it, the audit backend is not enabled. --audit-policy-file tells the apiserver which events to record based on rules; if omitted, no events are logged. This ensures both the destination and the filtering policy are set, satisfying kube-bench checks for audit logging.

Why this answer

Enabling audit logging in kube-apiserver requires both `--audit-log-path` to specify the output file and `--audit-policy-file` to define the audit policy rules. Without the policy file, the API server will not know which events to log, and without the log path, no audit logs will be written.

Exam trap

The trap here is that candidates often confuse `--audit-policy-file` with `--audit-webhook-config-file` or assume that providing only the log path or only the policy file is sufficient, when both are required for local audit logging to function.

How to eliminate wrong answers

Option B is wrong because it includes `--audit-log-maxage=30` but omits `--audit-log-path`, so no audit log file is created; the policy file alone cannot enable logging. Option C is wrong because it provides `--audit-log-path` and `--audit-log-maxbackup=10` but lacks `--audit-policy-file`, meaning the API server will not apply any audit policy and will not log events. Option D is wrong because `--audit-webhook-config-file` is used for sending audit events to an external webhook, not for specifying a local policy file; the correct flag for a local policy is `--audit-policy-file`.

Full explanation →

269

MCQhard

You need to run kube-bench on a control plane node. Which command should you use?

A.kube-bench run --targets=controlplane

B.kube-bench run --targets=master

C.kube-bench run --targets=node

D.kube-bench run --targets=etcd

AnswerB

This is the correct invocation because 'master' is the kube-bench target that maps to the control plane section of the CIS Kubernetes Benchmark. Running with --targets=master audits kube-apiserver, kube-controller-manager, kube-scheduler, and etcd bundles on the control plane node. It ensures comprehensive coverage of control plane checks rather than a partial or empty run.

Why this answer

`kube-bench` uses the `--targets` flag to specify which CIS benchmark targets to scan, and for control plane nodes, the correct target is `master` (not `controlplane`). This is because the CIS Kubernetes Benchmark historically refers to the control plane node as the 'master' node, and `kube-bench` follows that naming convention.

Exam trap

The trap here is that candidates assume the target name matches the modern Kubernetes terminology 'controlplane', but `kube-bench` still uses the legacy term 'master' for backward compatibility with the CIS Benchmark.

How to eliminate wrong answers

Option A is wrong because `--targets=controlplane` is not a valid target in `kube-bench`; the tool uses `master` for control plane nodes. Option C is wrong because `--targets=node` targets worker nodes, not the control plane. Option D is wrong because `--targets=etcd` only scans the etcd component, not the full control plane node.

Full explanation →

270

MCQhard

To encrypt secrets at rest in Kubernetes, an administrator configures an EncryptionConfiguration. What is the correct flag to pass to the kube-apiserver to use this configuration?

A.--encryption-provider-config=/path/to/config.yaml

B.--feature-gates=EncryptionAtRest=true

C.--encryption-key=/path/to/config.yaml

D.--encryption-config=/path/to/config.yaml

AnswerA

The `--encryption-provider-config` flag points the kube-apiserver to an EncryptionConfiguration YAML file that defines which providers (like `aescbc`, `aesgcm`, or `secretbox`) to use for encrypting Secrets and other resources at rest. The file also holds the actual encryption keys under each provider and specifies the order in which providers are attempted for throttling and decryption. Without this flag, Kubernetes stores Secrets in etcd as plaintext, so this is the standard way to enable encryption.

Why this answer

The `--encryption-provider-config` flag is the exact command-line option that the kube-apiserver expects to locate the EncryptionConfiguration YAML file. This flag tells the API server to read the configuration that defines which encryption providers (e.g., `aescbc`, `secretbox`) to use for encrypting Kubernetes secrets at rest in etcd.

Exam trap

The trap here is that candidates may confuse the flag name with similar-sounding options like `--encryption-config` or `--encryption-key`, or mistakenly think encryption at rest is enabled via a Kubernetes feature gate (`--feature-gates=EncryptionAtRest=true`). In reality, Kubernetes secret encryption at rest requires an EncryptionConfiguration YAML file specified via the `--encryption-provider-config` flag on the kube-apiserver. The feature gate approach is not valid; the correct mechanism is the dedicated configuration file and flag.

How to eliminate wrong answers

Option B is wrong because `--feature-gates=EncryptionAtRest=true` is not a valid flag; encryption at rest is enabled by providing an EncryptionConfiguration, not by a feature gate. Option C is wrong because `--encryption-key` is not a recognized kube-apiserver flag; encryption keys are specified inside the EncryptionConfiguration file, not passed directly as a command-line argument. Option D is wrong because `--encryption-config` is not the correct flag name; the correct flag is `--encryption-provider-config`.

Full explanation →

271

MCQhard

An admin creates the following EncryptionConfiguration to encrypt secrets at rest. After applying it, what must the admin do to ensure existing secrets are encrypted?

A.Re-create the existing secrets

B.Restart the kube-apiserver

C.Delete the existing secrets and wait for them to be recreated automatically

D.Nothing, the existing secrets are automatically encrypted

AnswerA

Existing secrets are stored in etcd with the identity provider (plaintext) until they are rewritten. Enabling an encryption provider in the EncryptionConfiguration only affects future write operations; the kube-apiserver does not retroactively scan or encrypt existing entries. To force encryption, you must re-create each secret (e.g., via kubectl get secret -o yaml | kubectl replace -f -) so the apiserver writes the new record using the configured encryption provider.

Why this answer

When an EncryptionConfiguration is applied to encrypt secrets at rest, the kube-apiserver uses the configured encryption provider to encrypt new or updated secrets as they are written to etcd. However, existing secrets that were stored in plaintext before the configuration was applied remain unencrypted in etcd. To ensure these existing secrets are encrypted, the admin must re-create them (e.g., by deleting and recreating them or using `kubectl get secret -o yaml | kubectl replace -f -`), which triggers a write to etcd through the encryption provider.

Exam trap

A common misconception is that applying an EncryptionConfiguration automatically encrypts all existing data, but the trap here is that encryption at rest only applies to new or updated writes, not to data already stored in etcd.

How to eliminate wrong answers

Option B is wrong because restarting the kube-apiserver does not re-encrypt existing secrets; it only loads the new EncryptionConfiguration for future writes. Option C is wrong because deleting existing secrets does not cause them to be automatically recreated; Kubernetes does not regenerate deleted secrets unless they are managed by a controller (e.g., ServiceAccount token secrets), and even then, the new secret would be encrypted, but the original data is lost. Option D is wrong because existing secrets are not automatically encrypted; the EncryptionConfiguration only applies to data written after it is active, so previously stored plaintext secrets remain unencrypted until they are rewritten.

Full explanation →

272

MCQmedium

A cluster administrator wants to encrypt secrets at rest in etcd. Which resource must be created to configure encryption?

A.KMSProvider

B.EncryptionConfiguration

C.SecretEncryptionConfig

D.EncryptionConfig

AnswerB

EncryptionConfiguration is the exact Kubernetes API resource used to configure encryption at rest. It is an object from the apiserver.config.k8s.io/v1 API group, and it defines a providers list that determines how the API server encrypts resources like Secrets before writing them to etcd. The API server loads this object via the --encryption-provider-config flag, making it the correct and only valid resource for this purpose.

Why this answer

The correct resource is an EncryptionConfiguration object, which is a Kubernetes API resource that defines how to encrypt secrets at rest in etcd. It specifies providers (such as aesgcm, secretbox, or kms) and their order of precedence for encrypting and decrypting data. This configuration is passed to the kube-apiserver via the --encryption-provider-config flag.

Exam trap

The trap here is that candidates confuse the generic term 'encryption config' with the exact Kubernetes API resource name 'EncryptionConfiguration', or they mistakenly think a KMS provider is a standalone resource rather than a provider type within the EncryptionConfiguration.

How to eliminate wrong answers

Option A is wrong because KMSProvider is not a Kubernetes resource; it is a type of encryption provider (e.g., using a Key Management Service) that can be referenced within an EncryptionConfiguration, not a standalone resource. Option C is wrong because SecretEncryptionConfig is not a valid Kubernetes API resource; the correct resource name is EncryptionConfiguration. Option D is wrong because EncryptionConfig is not a valid Kubernetes resource; the exact API resource name is EncryptionConfiguration (v1) in the apiserver.config.k8s.io group.

Full explanation →

273

MCQmedium

An administrator runs 'trivy image myapp:1.0' and receives an output with several CRITICAL vulnerabilities. What is the best next step to ensure the image is secure before deployment?

A.Delete the image entirely and do not deploy

B.Rebuild the image using updated base images and fix the identified vulnerabilities

C.Deploy the image anyway because vulnerabilities are common

D.Ignore the output and re-run the scan

AnswerB

Rebuilding the image is the correct remediation because Trivy's findings are tied to the exact package versions present in the image layers. By updating the base image tag (e.g., switching to a newer Alpine or Ubuntu release) and re-installing dependencies with patched versions, you eliminate the vulnerable components. After rebuilding, run Trivy again to confirm the image is clean before deployment.

Why this answer

The best practice for addressing container image vulnerabilities is to rebuild the image using updated base images and apply patches for the identified CVEs. Trivy reports vulnerabilities in the image layers, and simply deleting or ignoring them does not resolve the security issues; rebuilding with patched dependencies ensures the image is secure before deployment.

Exam trap

CNCF often tests the misconception that deleting or ignoring vulnerable images is acceptable, when the correct action is to remediate by rebuilding with updated base images and patching dependencies.

How to eliminate wrong answers

Option A is wrong because deleting the image entirely is an overreaction and does not provide a deployable solution; the goal is to fix the vulnerabilities, not discard the image. Option C is wrong because deploying an image with CRITICAL vulnerabilities violates supply chain security best practices and could expose the cluster to exploitation. Option D is wrong because ignoring the output and re-running the scan does not address the underlying vulnerabilities; it only repeats the same findings without remediation.

Full explanation →

274

MCQmedium

What is the default seccomp profile for Kubernetes containers when no seccompProfile is specified?

A.Localhost

B.No profile is applied

C.RuntimeDefault

D.Unconfined

AnswerC

The effective default seccomp profile for containers in Kubernetes is `RuntimeDefault`, which instructs the container runtime to apply its own built-in seccomp policy. This policy allows common application syscalls while blocking privileged or rarely needed ones such as `mount`, `reboot`, and `kexec_load`, providing a secure baseline. Even though a pod's `securityContext` may omit `seccompProfile`, the runtime enforces this profile automatically; in v1.29+ this is the expected behavior unless explicitly overridden.

Why this answer

When no `seccompProfile` is specified in the Pod or container security context, Kubernetes applies the `RuntimeDefault` seccomp profile by default. This profile is defined by the container runtime (e.g., containerd or CRI-O) and blocks a specific set of syscalls that are considered dangerous or unnecessary for containers, while allowing normal application operations. This default behavior was introduced in Kubernetes 1.19 and became the default for all pods in Kubernetes 1.22, enhancing security without requiring explicit configuration.

Exam trap

A common trap is the misconception that no seccomp profile means 'no restrictions' (Unconfined), but the correct default is `RuntimeDefault`, which applies a secure baseline profile automatically.

How to eliminate wrong answers

Option A is wrong because `Localhost` refers to a custom seccomp profile loaded from a file on the node's filesystem, which is not the default; it must be explicitly specified via `localhostProfile`. Option B is wrong because Kubernetes does apply a default seccomp profile (`RuntimeDefault`) when none is specified, so no profile is not the default behavior. Option D is wrong because `Unconfined` disables seccomp entirely, allowing all syscalls, which is the opposite of the secure default and must be explicitly set.

Full explanation →

275

MCQmedium

You need to configure a Kubernetes Pod to have an immutable root filesystem. Which field should you set in the Pod spec?

A.spec.hostPID: true

B.securityContext.allowPrivilegeEscalation: false

C.securityContext.runAsUser: 1000

D.securityContext.readOnlyRootFilesystem: true

AnswerD

securityContext.readOnlyRootFilesystem: true mounts the container's root filesystem with read-only permissions, so any process inside the container cannot write to the root filesystem at all. This directly enforces immutability of the core container filesystem, which is exactly what this question requires. Note that ephemeral volumes like emptyDir can still be mounted to provide writable directories, so the setting is compatible with workloads that need temporary storage.

Why this answer

Setting `securityContext.readOnlyRootFilesystem: true` in the container's security context makes the container's root filesystem read-only, preventing the container from writing to its own filesystem unless explicitly allowed (e.g., via volume mounts). Option A (`spec.hostPID`) shares the host's PID namespace, not relevant. Option B (`allowPrivilegeEscalation`) controls whether a process can gain more privileges than its parent, not filesystem immutability.

Option C (`runAsUser`) sets the user ID for the container, not filesystem permissions. Thus, only D achieves an immutable root filesystem.

Full explanation →

276

MCQmedium

Which of the following correctly adds the NET_ADMIN capability to a container in a Kubernetes pod?

A.securityContext: capabilities: cap_add: - ALL

B.securityContext: capabilities: add: - NET_ADMIN

C.securityContext: capabilities: cap_add: - NET_ADMIN (but placed at pod spec level)

D.securityContext: capabilities: cap_add: - NET_ADMIN

AnswerB

This is the correct Kubernetes syntax: the container-level securityContext contains a `capabilities` field with an `add` list. The key `add` is part of the Kubernetes API and instructs the container runtime to grant the specified Linux capabilities to the container's processes. Here, `NET_ADMIN` enables administrative operations on network devices and settings, which is a common requirement for networking containers. Placing this securityContext at the container level is also required for it to take effect.

Why this answer

In Kubernetes, the correct field to add a Linux capability to a container is `capabilities.add` in the container's `securityContext`. Option B uses `add: - NET_ADMIN` at the container level, which is the proper syntax. Option D uses `cap_add`, which is Docker Compose syntax and invalid in Kubernetes.

Option A uses `cap_add` with `ALL`, which adds all capabilities and is not specific. Option C places the `securityContext` at the pod spec level, but the pod-level `securityContext` does not support a `capabilities` field; capabilities must be set in each container's `securityContext`. Therefore, C is invalid, not just less precise.

Exam trap

The correct Kubernetes syntax for adding capabilities is `add` in the container's `securityContext`. A common pitfall is using `cap_add` (Docker Compose syntax) or attempting to place `capabilities` under the pod-level `securityContext`, which is not supported.

How to eliminate wrong answers

Option A is wrong because it uses `cap_add` (a Docker Compose key) instead of the Kubernetes `add` field, and it adds `ALL` capabilities, which violates the principle of least privilege and is not a targeted addition of `NET_ADMIN`. Option B is wrong because although it uses the correct `add` field, it is placed at the pod spec level (`securityContext` at the pod level) rather than at the container level, where `capabilities` must be defined; pod-level `securityContext` does not support a `capabilities` field. Option C is wrong because it uses `cap_add` (a Docker Compose key) instead of the Kubernetes `add` field, even though it is placed at the pod spec level, which is also incorrect.

Full explanation →

277

MCQeasy

An admin runs 'kubectl get pod web -o yaml' and sees the following security context. Which setting prevents privilege escalation?

A.allowPrivilegeEscalation: false

B.Both B and C

C.runAsNonRoot: true

D.capabilities: drop: [ALL]

AnswerA

Setting allowPrivilegeEscalation to false blocks the container process from gaining more privileges than its parent, disabling setuid binaries and preventing escalation via no_new_privs. This directly satisfies the stem's requirement to identify the setting that stops privilege escalation.

Why this answer

`allowPrivilegeEscalation: false` directly prevents a process from gaining more privileges than its parent process, such as through setuid binaries or gaining root capabilities. This setting is enforced by the kernel via the `no_new_privs` flag, which blocks privilege escalation attempts regardless of other security context settings.

Exam trap

A common misconception is that dropping all capabilities or running as non-root alone prevents privilege escalation, but the kernel's `no_new_privs` flag (set by `allowPrivilegeEscalation: false`) is the only direct control against setuid-based escalation.

How to eliminate wrong answers

Option B is wrong because it claims both B and C are correct, but only A directly prevents privilege escalation; `runAsNonRoot: true` ensures the container does not run as root but does not block privilege escalation if the container later gains root capabilities. Option C is wrong because `runAsNonRoot: true` only enforces that the container's user is not UID 0; it does not prevent the process from escalating privileges via setuid binaries or capability grants. Option D is wrong because dropping all capabilities removes many privileges but does not prevent privilege escalation—a process could still use setuid binaries or other mechanisms to gain root if `allowPrivilegeEscalation` is not set to false.

Full explanation →

278

MCQeasy

Which field in a Pod's securityContext prevents privilege escalation by the container?

A.capabilities.add: ["SYS_ADMIN"]

B.runAsNonRoot

C.allowPrivilegeEscalation

D.privileged

AnswerC

This field is the direct and intended control for privilege escalation. Setting allowPrivilegeEscalation: false applies the Linux no_new_privs attribute to all processes in the container, which prevents them from gaining more privileges than their parent process, including setuid/setgid executions and file capability acquisition. It is a runtime security feature that blocks the actual mechanism of privilege escalation, making it the correct answer. Without this setting, a container running as a non-root user may still escalate to root via a setuid binary.

Why this answer

`allowPrivilegeEscalation` controls whether a process can gain more privileges than its parent process. In a Pod's securityContext, setting this field to `false` prevents the container from performing privilege escalation, such as via setuid binaries or system calls like `setuid(0)`. This directly mitigates a common attack vector where an attacker exploits a container process to gain root access.

Exam trap

CNCF often tests this by having candidates confuse `allowPrivilegeEscalation` with `runAsNonRoot`, where the trap is that `runAsNonRoot` only sets the initial user but does not block subsequent privilege escalation via setuid binaries or capability-based syscalls.

How to eliminate wrong answers

Option A is wrong because `capabilities.add: ["SYS_ADMIN"]` grants the SYS_ADMIN capability, which itself allows many privileged operations, but it does not control or prevent privilege escalation; in fact, it can enable it. Option B is wrong because `runAsNonRoot` ensures the container runs as a non-root user but does not prevent the container from escalating privileges (e.g., via a setuid binary) if the binary is owned by root and the container has the necessary capabilities. Option D is wrong because `privileged: true` disables all security constraints and inherently allows privilege escalation; it is the opposite of preventing it.

Full explanation →

279

MCQhard

You need to restrict access to etcd so that only the API server can communicate with it. Which method should you use?

A.Configure etcd with TLS client certificates and require authentication

B.Set the etcd flag --peer-auto-tls=true

C.Configure etcd to use RBAC with a role that allows only the API server

D.Use a firewall rule to restrict access to etcd's port from the API server's IP

AnswerA

When etcd is started with --client-cert-auth=true and a --trusted-ca-file, it requires every client to present a valid X.509 certificate signed by that CA. The kube-apiserver is configured with its own client certificate and key, enabling mutual TLS (mTLS) so etcd verifies both the identity of the API server and the integrity of the encrypted channel. This cryptographically guarantees that only the API server—and any other explicitly trusted client—can read or write cluster state, preventing both unauthorized access and eavesdropping.

Why this answer

Etcd supports mutual TLS (mTLS) authentication, which requires clients to present a valid TLS certificate signed by a trusted CA. By configuring etcd with `--client-cert-auth=true` and providing the API server's client certificate, you ensure that only the API server (or any client with a valid certificate) can communicate with etcd. This is the recommended Kubernetes approach to restrict access to etcd, as it cryptographically verifies the identity of the client.

Exam trap

The trap here is that candidates often confuse network-level restrictions (firewall rules) with identity-based authentication (mTLS), or mistakenly think etcd supports RBAC like Kubernetes, leading them to choose options D or C.

How to eliminate wrong answers

Option B is wrong because `--peer-auto-tls=true` enables automatic TLS for etcd peer-to-peer communication between etcd members, not for client-to-server communication; it does not restrict client access. Option C is wrong because etcd does not support RBAC natively; RBAC is a Kubernetes API server feature, not an etcd feature, and etcd uses certificate-based authentication, not role-based access control. Option D is wrong because a firewall rule only restricts network access at the IP/port level, but it does not authenticate the API server's identity; any process on the API server's node could potentially connect to etcd, and it does not protect against compromised nodes or spoofed IPs.

Full explanation →

280

MCQhard

You are a security engineer at a company running a Kubernetes cluster in production. The cluster uses containerd as the container runtime and has been configured with Node Authorizer and NodeRestriction admission controller. Recently, a security audit revealed that several pods running as root have been compromised via container escape vulnerabilities. The audit report recommends hardening the nodes to reduce the attack surface. Specifically, you need to ensure that even if an attacker gains root access inside a container, they cannot execute privileged operations on the host node, such as loading kernel modules, modifying host network settings, or accessing host devices. The cluster runs on Ubuntu 20.04 nodes with Linux kernel 5.4. You have access to modify node-level configurations but must minimize performance impact and avoid breaking existing workloads that rely on standard Linux capabilities. Which of the following actions would most effectively mitigate these risks?

A.Configure containerd to use a default seccomp profile that blocks unprivileged user namespaces and restricts kernel modules loading, and apply it to all pods via a mutating admission webhook.

B.Enable user namespaces for all containers by setting the 'hostUsers: false' option in the pod spec, which maps container root to a non-root user on the host.

C.Remove the CAP_SYS_ADMIN and CAP_NET_ADMIN capabilities from all containers by setting a default PodSecurityPolicy that drops these capabilities.

D.Enable AppArmor on all nodes and apply a custom profile that denies all mount and network-related system calls.

AnswerA

A default seccomp profile that blocks risky syscalls (e.g., those used for kernel module loading, user namespace creation) effectively prevents many container escapes without breaking most workloads. Applying it via a webhook ensures all pods use it.

Why this answer

Seccomp (secure computing mode) can filter system calls at the kernel level, and by configuring containerd to use a default seccomp profile that blocks syscalls related to unprivileged user namespaces (e.g., `clone` with `CLONE_NEWUSER`) and kernel module loading (e.g., `init_module`, `finit_module`), you prevent container escapes from performing privileged host operations. This approach is runtime-level, applies globally without modifying pod specs, and minimizes performance impact since seccomp uses a BPF-based filter that adds negligible overhead.

Exam trap

CNCF often tests the misconception that dropping capabilities alone is sufficient for host-level hardening, but the trap here is that capabilities only restrict privileged operations that require them, while seccomp provides syscall-level filtering that can block escape vectors even when the container runs as root.

How to eliminate wrong answers

Option B is wrong because setting `hostUsers: false` in the pod spec enables user namespace remapping, which maps the container's root user to a non-root user on the host, but this feature is not supported by containerd in Kubernetes versions prior to 1.27 and requires specific runtime support; it also does not block kernel module loading or host network modifications if the container retains capabilities like CAP_SYS_MODULE. Option C is wrong because dropping CAP_SYS_ADMIN and CAP_NET_ADMIN reduces the attack surface but does not prevent an attacker from using other capabilities (e.g., CAP_SYS_MODULE to load kernel modules) or exploiting syscalls that do not require capabilities, such as `mount` with `MS_BIND` if the container runs as root. Option D is wrong because AppArmor profiles deny system calls at the LSM level, but applying a custom profile that denies all mount and network-related syscalls would break standard container operations (e.g., creating network interfaces, mounting tmpfs) and is not a default or easily maintainable solution; additionally, AppArmor is not enabled by default on all Ubuntu 20.04 nodes and requires kernel configuration.

Full explanation →

281

MCQhard

A pod fails to start with the error 'Container runtime network not ready', and the node uses Kata Containers (RuntimeClass: kata). What is the most likely cause?

A.The node has insufficient memory

B.The pod is trying to mount a hostPath volume

C.The CNI plugin is not configured correctly for the kata RuntimeClass

D.The pod's securityContext sets runAsNonRoot: true

AnswerC

Kata Containers runs each pod inside a lightweight VM, so CNI must do more than create a veth pair in the host namespace: it must set up a virtual network interface (e.g., TAP or virtio-net) that connects the guest VM to the host's network infrastructure. If the CNI plugin in use is not compatible with Kata's VM-based model — for example, a plugin that assumes the container's network namespace is a regular host netns — the plugin's ADD command may fail or return before the VM's network interface is ready. This causes the containerd/kubelet sandbox creation to fail with a network not ready error, exactly as described in the scenario.

Why this answer

Kata Containers use lightweight VMs for pod isolation, which require a separate CNI plugin (e.g., flannel, calico) to be configured specifically for the kata RuntimeClass. The error 'Container runtime network not ready' indicates that the CNI plugin is either missing, misconfigured, or not compatible with the kata runtime, preventing the pod's network namespace from being set up.

Exam trap

Candidates often overlook the need for RuntimeClass-specific CNI configuration when using Kata Containers, assuming that the network error is always due to a cluster-wide CNI issue.

How to eliminate wrong answers

Option A is wrong because insufficient memory would typically cause an OOMKill or pod eviction, not a network readiness error. Option B is wrong because hostPath volume mounts do not affect the container runtime's network initialization; they are handled by the kubelet after the pod is scheduled. Option D is wrong because runAsNonRoot: true is a security context setting that enforces user ID restrictions, but it does not impact the container runtime's network setup or CNI plugin configuration.

Full explanation →

282

MCQmedium

A DevOps engineer wants to enforce that all container images running in the cluster are signed using Cosign. Which Kubernetes admission controller is designed for this purpose?

A.MutatingAdmissionWebhook

B.ImagePolicyWebhook

C.PodSecurityPolicy (deprecated)

D.ValidatingAdmissionWebhook

AnswerB

The ImagePolicyWebhook is an admission controller that contacts an external webhook service to evaluate every Pod's image references at creation time. The external service can verify signatures, digest pins, or other supply-chain criteria, returning an allow/deny decision (and optionally an image rewrite). This is the built-in, dedicated mechanism for enforcing image signing and provenance policies, distinct from generic webhooks.

Why this answer

The ImagePolicyWebhook admission controller is specifically designed to enforce that container images meet certain criteria, such as being signed with Cosign, by querying an external webhook service that validates image signatures before admitting a pod. It intercepts pod creation requests and checks the image references against a configured policy, making it the correct choice for this Cosign-based image signing enforcement scenario.

Exam trap

The trap here is that candidates confuse the generic ValidatingAdmissionWebhook (a Kubernetes admission controller) with the dedicated ImagePolicyWebhook, which is the specific admission controller designed for image policy enforcement in Kubernetes.

How to eliminate wrong answers

Option A is wrong because MutatingAdmissionWebhook is used to mutate (modify) objects during admission, not to enforce image signing policies; it can be used in conjunction with an image validation webhook but is not the dedicated controller for this purpose. Option C is wrong because PodSecurityPolicy (deprecated) is a cluster-level resource that controls security-sensitive aspects of pod specification (e.g., privilege escalation, host namespaces) and does not validate container image signatures. Option D is wrong because ValidatingAdmissionWebhook is a generic webhook for validating any aspect of an admission request, but the question specifically asks for the admission controller designed for image policy enforcement, which is the ImagePolicyWebhook.

Full explanation →

283

Multi-Selectmedium

Which TWO actions help minimize vulnerabilities in microservices by securing secrets? (Choose two)

Select 2 answers

A.Base64 encode the secret in the YAML manifest

B.Set the secret as a label on the pod

C.Mount Secrets as volumes instead of environment variables

D.Use an external secrets manager like HashiCorp Vault

E.Store secrets in ConfigMaps to leverage ConfigMap encryption

AnswersC, D

Mounting a Secret as a volume (e.g., in /var/secrets) keeps the secret data out of the container's environment variables, which are exposed through /proc/<pid>/environ and can be inherited by child processes or captured in debug output. A mounted file also lets you set restrictive file permissions (e.g., 0400) and, with projected volumes or subPath, can be updated without restarting the container. However, this only mitigates runtime exposure; the Secret is still stored in etcd and should be protected with encryption at rest.

Why this answer

Mounting secrets as volumes is more secure than using environment variables. When secrets are injected as environment variables, they can be exposed through the process environment (e.g., via `/proc/self/environ` or `env` command) and are more likely to be accidentally logged or leaked. Mounting as a volume ensures the secret is only available as a file in the container's filesystem, and the secret data is not visible in the process list or environment dumps, reducing the attack surface.

Exam trap

The exam often tests the misconception that Base64 encoding is a form of security, or that storing secrets in ConfigMaps is acceptable because ConfigMaps can be encrypted, but the exam expects you to know that ConfigMaps are for non-sensitive data and that external secrets managers or volume mounts are the correct approaches for secret management.

Full explanation →

284

MCQmedium

A security audit reveals that the etcd datastore is not encrypted at rest. Which resource should be created to enable encryption of secrets at rest?

A.EncryptionConfiguration

B.EtcdEncryption

C.EncryptionConfig

D.SecretEncryption

AnswerA

EncryptionConfiguration is the correct Kubernetes API resource, defined in the apiserver.config.k8s.io/v1 API group, that specifies how etcd data is encrypted at rest. It declares an ordered list of providers (identity, aescbc, aesgcm, secretbox, or kms) and the corresponding keys; the kube-apiserver reads it via --encryption-provider-config. This is the only one of these options that actually exists as a first-class configuration object.

Why this answer

To enable encryption of secrets at rest in Kubernetes, you must create an EncryptionConfiguration resource. This resource defines which encryption providers (e.g., AES-CBC, secretbox) to use and how to encrypt resources stored in etcd. The kube-apiserver reads this configuration via the --encryption-provider-config flag and applies it to all resources in the specified resource group, such as secrets.

Exam trap

CNCF often tests the exact API resource name, and candidates mistakenly pick 'EtcdEncryption' or 'EncryptionConfig' because they sound plausible, but only 'EncryptionConfiguration' is the correct Kubernetes resource defined in the apiserver configuration.

How to eliminate wrong answers

Option B is wrong because EtcdEncryption is not a valid Kubernetes API resource; the correct resource is EncryptionConfiguration. Option C is wrong because EncryptionConfig is not a Kubernetes resource name; it might be confused with the kube-apiserver configuration file but does not exist as an API object. Option D is wrong because SecretEncryption is not a Kubernetes resource; encryption at rest applies to multiple resource types, not just secrets, and the resource is named EncryptionConfiguration.

Full explanation →

285

MCQmedium

You run 'kube-bench' on a cluster node and get a failure for the test 'Ensure that the --anonymous-auth argument is set to false' (ID: 1.2.1). Which file do you need to modify to fix this issue?

A./etc/kubernetes/kubelet.conf

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

C./etc/kubernetes/pki/

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

AnswerB

In kubeadm-deployed clusters, control plane components run as static pods, and their manifests live in /etc/kubernetes/manifests. kube-bench inspects this YAML for hardening settings such as --authorization-mode=RBAC, --anonymous-auth=false, --secure-port, --tls-cipher-suites, and --service-account-lookup. Modifying flags here and restarting kubelet (or moving the file) changes API server behavior for kube-bench validation.

Why this answer

The kube-bench test ID 1.2.1 checks the kube-apiserver configuration for the `--anonymous-auth` flag. The API server is a static pod managed by the kubelet, and its configuration is defined in the manifest file `/etc/kubernetes/manifests/kube-apiserver.yaml`. To fix the failure, you must edit this file to set `--anonymous-auth=false`.

Exam trap

The trap here is that candidates often confuse the kubelet configuration file (`/var/lib/kubelet/config.yaml`) with the API server manifest, but the `--anonymous-auth` flag is specific to the API server, not the kubelet.

How to eliminate wrong answers

Option A is wrong because `/etc/kubernetes/kubelet.conf` is the kubelet's bootstrap configuration file, not the API server's manifest; it does not control the `--anonymous-auth` flag. Option C is wrong because `/etc/kubernetes/pki/` is a directory containing TLS certificates and keys, not configuration files for the API server. Option D is wrong because `/var/lib/kubelet/config.yaml` is the kubelet's own configuration file, which does not contain the `--anonymous-auth` argument for the API server.

Full explanation →

286

Multi-Selecteasy

Which TWO of the following are valid methods to restrict etcd access? (Choose two.)

Select 2 answers

A.Use firewall rules to restrict access to etcd port 2379

B.Use TLS client certificates for authentication

C.Enable etcd RBAC

D.Use etcd's built-in password authentication

E.Set the --etcd-certfile flag on kube-apiserver

AnswersB, C

TLS client certificate authentication is one of the two native, supported ways to restrict access to etcd. When etcd is started with --client-cert-auth=true, the server requires every client to present a certificate signed by a trusted CA, and it can optionally check the certificate's common name against a configured allowlist. This provides strong, transport-level authentication that prevents unauthenticated clients from contacting the etcd API, which is essential because etcd stores all Kubernetes cluster state.

Why this answer

Etcd supports mutual TLS (mTLS) authentication, where the client (e.g., kube-apiserver) presents a client certificate signed by the etcd CA. This ensures that only authenticated clients can communicate with etcd, effectively restricting access. Option C is correct because etcd has its own Role-Based Access Control (RBAC) system, which can be enabled to restrict read/write operations to specific users or roles, providing fine-grained access control.

Exam trap

The trap here is that candidates often confuse network-level controls (firewall rules) or API server flags with actual etcd authentication/authorization mechanisms, or mistakenly believe etcd supports password authentication like traditional databases.

Full explanation →

287

Drag & Dropmedium

Order the steps to configure and apply a NetworkPolicy to restrict pod-to-pod traffic.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

NetworkPolicy must be created and applied, then tested by deploying pods and checking connectivity. The policy is enforced immediately.

Full explanation →

288

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.

Full explanation →

289

MCQmedium

An administrator runs kube-bench on a node and sees a warning about the kubelet anonymous authentication being enabled. Which kubelet flag should be set to disable anonymous access?

A.--anonymous-auth=false

B.--anonymous-auth=true

C.--enable-anonymous=false

D.--disable-anonymous=true

AnswerA

Setting --anonymous-auth=false on the kubelet rejects unauthenticated requests to the kubelet API, closing the anonymous access path flagged by kube-bench. This satisfies the requirement to disable anonymous authentication; the flag is configured in the kubelet config or systemd unit.

Why this answer

The kubelet's `--anonymous-auth` flag controls whether requests to the kubelet API that are not rejected by other authentication modules are treated as anonymous requests. Setting `--anonymous-auth=false` disables anonymous access, requiring all requests to present valid credentials. This directly addresses the kube-bench warning about anonymous authentication being enabled, which is a security concern as it allows unauthenticated access to the kubelet's API.

Exam trap

The trap here is that candidates may confuse the kubelet's `--anonymous-auth` flag with similar-sounding but non-existent flags like `--enable-anonymous` or `--disable-anonymous`, or mistakenly think that setting the flag to `true` disables anonymous access.

How to eliminate wrong answers

Option B is wrong because `--anonymous-auth=true` enables anonymous access, which is the opposite of what is needed to disable it. Option C is wrong because `--enable-anonymous=false` is not a valid kubelet flag; the correct flag is `--anonymous-auth`. Option D is wrong because `--disable-anonymous=true` is not a valid kubelet flag; the kubelet uses `--anonymous-auth` with a boolean value to control anonymous access.

Full explanation →

290

Multi-Selectmedium

Which ONE of the following is a valid method to restrict a container's filesystem to read-only in Kubernetes?

Select 1 answer

A.Use a ConfigMap volume with defaultMode 0444

B.Set readOnly: true on a hostPath volume mount

C.Set readOnlyRootFilesystem: true in the container's securityContext

D.Mount an emptyDir volume with readOnly: true

AnswersC

Setting readOnlyRootFilesystem: true in the container's securityContext causes the entire root filesystem of the container to be mounted read-only, so any attempt to write to filesystem paths that are part of the image or container layer will fail. This is the standard, recognized method to enforce a read-only container filesystem, because it applies globally to the container's base filesystem rather than to a specific volume. Note that this does not affect volumes that are explicitly mounted; each volume still needs to be explicitly marked readOnly if that is desired.

Why this answer

The only valid method listed. Setting `readOnlyRootFilesystem: true` in the container's securityContext directly makes the container's root filesystem read-only. Options A, B, and D only make specific volumes read-only (ConfigMap, hostPath, emptyDir), but do not prevent writes to the container's own filesystem (e.g., /etc, /tmp, /var).

Therefore, only option C correctly restricts the container's filesystem to read-only.

Exam trap

In the CKS exam, the distinction between making a specific volume read-only (e.g., via `readOnly: true` on a mount) versus making the entire container's root filesystem read-only via `readOnlyRootFilesystem` is often tested. Candidates mistakenly think that setting `readOnly: true` on any volume achieves the same effect.

Full explanation →

291

MCQeasy

Which command would you use to sign a container image with Cosign?

A.cosign push <image>

B.cosign verify <image>

C.cosign attest <image>

D.cosign sign <image>

AnswerD

Cosign signs container images stored in an OCI registry, binding a signature to the image digest. Running cosign sign against the image reference creates and uploads that signature, satisfying the requirement to cryptographically sign the container image.

Why this answer

The `cosign sign <image>` command is used to sign a container image with Cosign, attaching a digital signature to the image manifest in the container registry. This signature can later be verified to ensure the image's integrity and origin, which is a core requirement for supply chain security in Kubernetes environments.

Exam trap

The exam often tests the distinction between `cosign sign` (which signs the image) and `cosign attest` (which creates a signed attestation about the image's metadata), causing candidates to confuse the two commands.

How to eliminate wrong answers

Option A is wrong because `cosign push` is used to push an image to a registry, not to sign it. Option B is wrong because `cosign verify` is used to check an existing signature against an image, not to create one. Option C is wrong because `cosign attest` is used to create an in-toto attestation (a signed statement about the image's provenance or build process), not to directly sign the image itself.

Full explanation →

292

Multi-Selecthard

Which THREE of the following can be used to enforce policies on container images in a Kubernetes cluster? (Select 3)

Select 3 answers

A.Kyverno

B.ImagePolicyWebhook

C.Trivy

D.OPA/Gatekeeper

E.kubectl

AnswersA, B, D

Kyverno is a Kubernetes-native admission controller that validates and mutates resources against policies written as YAML, so it can block non-compliant container images at admission time without requiring a separate policy language or external agent.

Why this answer

Kyverno (A) is correct because it is a Kubernetes-native policy engine that runs as an admission controller and can validate, mutate, and generate resources, including enforcing rules on container images (e.g., allowed registries, required signatures, or tag restrictions) via ClusterPolicy/Policy resources. ImagePolicyWebhook (B) is correct because it is a built-in Kubernetes admission controller plugin that sends image admission requests to an external HTTP webhook, which can approve or reject pods based on image policy decisions. OPA/Gatekeeper (D) is correct because Gatekeeper deploys Open Policy Agent as a validating admission webhook in Kubernetes, using ConstraintTemplates and Constraints to enforce policies such as restricting container image registries or requiring trusted images.

Trivy (C) is not correct here because it is a vulnerability and misconfiguration scanner for images and filesystems, not an admission-time policy enforcement mechanism. kubectl (E) is not correct because it is the Kubernetes command-line client for interacting with the API server, not a policy engine or admission controller.

Exam trap

The trap here is that candidates confuse vulnerability scanning tools (like Trivy) with policy enforcement engines, or assume kubectl can enforce policies via commands, when in fact only admission controllers or policy engines like Kyverno, OPA/Gatekeeper, and ImagePolicyWebhook can enforce image policies at the cluster level.

Full explanation →

293

MCQhard

A security team wants to ensure that all pods in a namespace run with a restricted seccomp profile. Which Pod Security Standard admission controller mode should be used to enforce this without blocking necessary pods?

A.Enable the PodSecurity admission plugin with the 'restricted' policy and 'enforce' mode

B.Use a mutating admission webhook to automatically add seccomp profiles

C.Enable the PodSecurity admission plugin with the 'baseline' policy and 'enforce' mode

D.Enable the PodSecurity admission plugin with the 'restricted' policy and 'warn' mode

AnswerA

PodSecurity admission with the 'restricted' policy in 'enforce' mode acts as an admission controller that rejects any pod that fails the restricted profile, including the requirement that seccomp be set to RuntimeDefault or Localhost. This directly blocks non-compliant pods at creation time, ensuring only pods meeting the strict security requirements run in the namespace. Enforce mode is the only mode that provides hard enforcement, making this the correct choice.

Why this answer

The Pod Security Standards (PSS) define three policies: privileged, baseline, and restricted. The restricted policy enforces the most stringent security controls, including requiring a seccomp profile to be set to 'RuntimeDefault' or 'localhost/*'. Using the PodSecurity admission plugin with 'enforce' mode ensures that any pod failing the restricted policy is immediately rejected, guaranteeing that only compliant pods run in the namespace.

Exam trap

CNCF often tests the distinction between 'enforce' and 'warn' modes: candidates mistakenly choose 'warn' thinking it is sufficient, but 'enforce' is required to actually block non-compliant pods.

How to eliminate wrong answers

Option B is wrong because a mutating admission webhook can automatically add seccomp profiles, but it does not enforce a Pod Security Standard policy; it only mutates the pod spec, and pods could still be created without the required profile if the webhook fails or is bypassed. Option C is wrong because the 'baseline' policy is less restrictive and does not require a seccomp profile; it only prevents known privilege escalations, so it would not enforce the restricted seccomp requirement. Option D is wrong because 'warn' mode only generates a warning for non-compliant pods but still allows them to be created, which does not enforce the restricted seccomp profile as required by the question.

Full explanation →

294

MCQeasy

Which admission plugin enforces that kubelets cannot modify pods they do not own?

A.PodSecurity

B.AlwaysPullImages

C.NodeRestriction

D.ServiceAccount

AnswerC

NodeRestriction is the admission plugin that, together with the Node authorizer, restricts kubelets to self-service APIs. It limits a kubelet to modifying only its own Node object and only specific fields such as status, while denying updates to other Nodes or arbitrary metadata like labels. Critically, it also prevents a kubelet from writing to Pod objects that it does not own (i.e., pods without spec.nodeName matching its node), thereby preventing a compromised kubelet from escalating cluster-wide privileges.

Why this answer

The NodeRestriction admission plugin ensures that kubelets can only modify Node and Pod objects that are bound to their own node. It enforces that a kubelet cannot update or delete pods it does not own, preventing a compromised or misconfigured kubelet from interfering with workloads on other nodes.

Exam trap

CNCF often tests the NodeRestriction plugin as a control for kubelet authorization, and the trap here is confusing it with PodSecurity (which handles pod security contexts) or AlwaysPullImages (which handles image pull policy), rather than recognizing that NodeRestriction specifically limits what a kubelet can modify.

How to eliminate wrong answers

Option A is wrong because PodSecurity is an admission plugin that enforces Pod Security Standards (e.g., privileged, baseline, restricted) on pod creation, not kubelet authorization. Option B is wrong because AlwaysPullImages forces every pod to pull its container images from the registry with credentials, but does not restrict kubelet modifications to pods. Option D is wrong because ServiceAccount is an admission plugin that manages service account automounting and token projection, not kubelet node-level access control.

Full explanation →

295

Multi-Selectmedium

Which THREE of the following actions help reduce the attack surface of containers? (Select 3 correct answers)

Select 3 answers

A.Set hostNetwork: true for better network performance

B.Set securityContext.runAsNonRoot: true

C.Drop all capabilities and add only required ones

D.Enable audit logging for all API requests

E.Run containers with read-only root filesystem

AnswersB, C, E

Setting securityContext.runAsNonRoot: true enforces that the container's primary process runs as a non-root UID, failing to start otherwise. This prevents an attacker who exploits a container vulnerability from gaining root privileges on the host via trivial container escape paths, because the process lacks UID 0. Combined with an explicit runAsUser and a non-root user in the image, this hardens the workload against privilege escalation.

Why this answer

Setting `securityContext.runAsNonRoot: true` forces the container to run with a user ID that is not 0 (root). This prevents an attacker who gains code execution inside the container from having root privileges, which would otherwise allow them to escape the container, modify system binaries, or perform privileged operations. It is a fundamental principle of least privilege and directly reduces the attack surface by limiting the damage a compromised container can do.

Exam trap

A common pitfall in this exam is confusing security controls that directly reduce the attack surface (e.g., dropping capabilities, read-only filesystem, non-root user) with controls that provide visibility or performance improvements (e.g., audit logging, hostNetwork). Candidates often incorrectly select options that enhance monitoring or speed rather than those that harden the container.

Full explanation →

296

Drag & Dropmedium

Arrange the steps to create and enforce a Pod Security Policy (PSP) in a Kubernetes cluster.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

PSPs require enabling the admission controller, creating the policy, granting access via RBAC, and binding to subjects. Testing confirms enforcement.

Full explanation →

297

MCQmedium

You are configuring kubelet to protect kernel defaults. Which flag enables this?

A.--security-opt=protect-kernel

B.--protect-kernel-defaults

C.--enable-protect-kernel

D.--kernel-security

AnswerB

The kubelet flag --protect-kernel-defaults, when set to true, enforces that the node's kernel parameters (such as vm.overcommit_memory and kernel.panic) are at their default secure values, and it refuses to start if these settings deviate. This flag also blocks pods from overriding unsafe sysctls, preventing kernel-level misconfigurations that could compromise the node. It is the only correct flag among the options for enabling this kind of kernel protection in a Kubernetes kubelet.

Why this answer

The `--protect-kernel-defaults` flag is a kubelet option that, when set to `true`, enforces kernel tunable protections by checking that sysctl settings like `vm.overcommit_memory`, `vm.panic_on_oom`, and `kernel.panic` match the kubelet's expected safe defaults. This is a critical hardening measure to prevent container breakout scenarios where a compromised pod could weaken host kernel parameters.

Exam trap

The trap here is that candidates confuse Docker's `--security-opt` flags (which apply per-container) with kubelet's node-level hardening flags, or they invent plausible-sounding flag names like `--enable-protect-kernel` that do not exist in the kubelet reference.

How to eliminate wrong answers

Option A is wrong because `--security-opt=protect-kernel` is a Docker run flag, not a kubelet flag; it applies to individual containers, not the kubelet's global kernel protection. Option C is wrong because `--enable-protect-kernel` is not a valid kubelet flag; the correct syntax uses `--protect-kernel-defaults` without the 'enable' prefix. Option D is wrong because `--kernel-security` is not a recognized kubelet flag; it might be confused with AppArmor or SELinux profiles, but it does not enforce kernel default protections.

Full explanation →

298

MCQmedium

You are creating a ServiceAccount that should not automatically mount its token to pods. Which field should be set in the ServiceAccount manifest?

A.automountServiceAccountToken: false

B.disableAutomount: true

C.tokenMountDisabled: true

D.mountToken: false

AnswerA

Setting automountServiceAccountToken to false in the ServiceAccount spec disables the automatic creation and mounting of the service account API token into every Pod that uses this ServiceAccount. This is the correct field name and value; the default is true, so explicitly setting it to false ensures that Pods do not receive the token merely by referencing the ServiceAccount, which limits the attack surface for workloads that never need to talk to the Kubernetes API. Pods can still override this via the Pod spec if needed.

Why this answer

The `automountServiceAccountToken` field in a ServiceAccount manifest, when set to `false`, prevents pods using that ServiceAccount from automatically mounting the service account token as a volume. This is a security hardening measure to reduce the attack surface in case a pod is compromised, as the token could be used to authenticate to the Kubernetes API server.

Exam trap

The trap here is that candidates may confuse the ServiceAccount-level field with the Pod-level field of the same name, or invent non-existent field names like `disableAutomount` or `tokenMountDisabled`, instead of recalling the exact API field `automountServiceAccountToken`.

How to eliminate wrong answers

Option B is wrong because `disableAutomount: true` is not a valid field in the ServiceAccount API; the correct field name is `automountServiceAccountToken`. Option C is wrong because `tokenMountDisabled: true` does not exist in the Kubernetes API; it is a fabricated field name. Option D is wrong because `mountToken: false` is not a recognized field; the correct boolean field is `automountServiceAccountToken`, and setting it to `false` achieves the desired behavior.

Full explanation →

299

MCQhard

An admin has created an EncryptionConfiguration to encrypt secrets at rest in etcd. After applying the configuration and restarting the kube-apiserver, existing secrets are still stored in plaintext. What is the most likely reason?

A.The encryption provider is set to 'identity' which does not encrypt

B.The kube-apiserver was not restarted after applying the configuration

C.Existing secrets are not automatically encrypted; they need to be rewritten by reading and writing them back

D.The EncryptionConfiguration has a syntax error that caused it to be ignored

AnswerC

This is the correct answer. When a new EncryptionConfiguration becomes active, the API server only encrypts objects that are written to etcd after that point; any objects that already exist in etcd remain in their original unencrypted form until they are modified. To encrypt existing secrets, they must be rewritten by reading them and then performing a write operation, such as `kubectl get secret -o yaml | kubectl replace -f -` or by deleting and recreating them. The API server does not automatically backfill encryption for pre-existing data.

Why this answer

Kubernetes does not automatically encrypt existing secrets stored in etcd when an EncryptionConfiguration is applied. The encryption configuration only affects data written after the kube-apiserver is restarted; previously stored secrets remain in plaintext until they are read and rewritten (e.g., by running `kubectl get secret <name> -o yaml | kubectl replace -f -`). This behavior is by design, as the API server encrypts data on write, not retroactively.

Exam trap

The trap here is that candidates assume applying an EncryptionConfiguration and restarting the API server automatically encrypts all existing data, but Kubernetes only encrypts data on new writes, not retroactively.

How to eliminate wrong answers

Option A is wrong because the 'identity' provider does not encrypt, but the question states an EncryptionConfiguration was created to encrypt secrets, implying a non-identity provider (e.g., aesgcm or secretbox) was configured; if identity were used, no encryption would occur for new data either. Option B is wrong because the question explicitly states the kube-apiserver was restarted after applying the configuration, so the restart is not the issue. Option D is wrong because a syntax error in the EncryptionConfiguration would typically cause the kube-apiserver to fail to start or log an error, not silently ignore the configuration; the question implies the configuration was applied and the server restarted successfully.

Full explanation →

300

MCQmedium

A developer reports that a pod cannot reach an external database at 192.168.1.100:3306. The pod's namespace is 'app'. You need to create a NetworkPolicy that allows egress to that IP only. Which policy is correct?

A.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-egress namespace: app spec: podSelector: {} egress: - to: - ipBlock: cidr: 192.168.1.100/32 policyTypes: - Egress

B.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-egress namespace: app spec: podSelector: matchLabels: app: myapp egress: - to: - ipBlock: cidr: 192.168.1.100/32 policyTypes: - Egress

C.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-egress namespace: app spec: podSelector: {} ingress: - from: - ipBlock: cidr: 192.168.1.100/32 policyTypes: - Ingress

D.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-egress namespace: app spec: podSelector: {} egress: - to: - ipBlock: cidr: 192.168.1.100/32 ports: - port: 3306 protocol: TCP policyTypes: - Egress

AnswerD

This policy selects all pods in the namespace via podSelector: {} and permits egress traffic specifically to the database IP on TCP port 3306, which is the MySQL port mentioned in the scenario. By including both the destination IP and the exact port, it follows least privilege and directly restores the pod's ability to reach the external data source while blocking other outbound traffic.

Why this answer

The correct NetworkPolicy must allow egress traffic from pods in the 'app' namespace to the specific IP 192.168.1.100 on port 3306. Option D meets this requirement by using 'podSelector: {}' to apply to all pods, specifying an egress rule to the ipBlock with the correct CIDR and port 3306, and setting 'policyTypes: [Egress]'. Option A is missing the port specification, so it would allow egress to the IP on any port, which is too permissive.

Option B uses 'matchLabels: app: myapp', restricting the policy to pods with that label, and also lacks the port. Option C defines an ingress rule instead of egress, which does not address the egress requirement.

Full explanation →

Certified Kubernetes Security Specialist CKS (CKS) — Questions 226–300