CKS Practice Exam 2 — 20 Questions

Question 1

What is the purpose of setting a container's filesystem to read-only in a Pod spec?

Accepted Answer

To prevent an attacker from modifying the container's filesystem after compromise. Setting a container's filesystem to read-only in a Pod spec (via `securityContext.readOnlyRootFilesystem: true`) ensures that the container's root filesystem cannot be written to at runtime. This is a critical runtime security hardening measure because even if an attacker gains code execution inside the container (e.g., through a web application vulnerability), they cannot modify binaries, configuration files, or scripts on the filesystem, severely limiting their ability to persist, escalate privileges, or tamper with the application. This aligns with the principle of immutable infrastructure and is a key control in the CKS domain of Runtime Security.

Answer

To allow multiple pods to share the same filesystem

Answer

To prevent the container from being deleted

Answer

To improve disk I/O performance

Question 2

A pod is running in a namespace that has a Kyverno policy requiring all images to come from a trusted registry. The pod is using an image from an untrusted registry. What will happen when the pod is created?

Accepted Answer

The pod creation will be rejected with an admission error. Kyverno operates as an admission controller in Kubernetes. When a pod is created, the Kyverno admission webhook intercepts the creation request and evaluates it against the configured policies. If the policy requires all images to come from a trusted registry and the pod uses an image from an untrusted registry, the admission webhook rejects the request, preventing the pod from being created. This results in an admission error, not a post-creation termination.

Answer

The pod will be created but immediately terminated

Answer

The pod will be created and run successfully

Answer

The pod will be created but the image will be replaced with a trusted one

Question 3

A security engineer needs to ensure that all communication between nodes and the control plane is encrypted. Which component must be configured with a TLS certificate to achieve this?

Accepted Answer

kube-apiserver. The kube-apiserver is the central gateway for all cluster operations, and it must be configured with a TLS certificate to encrypt communication between nodes (kubelets) and the control plane. The kube-apiserver presents this certificate to authenticate itself and establish encrypted HTTPS connections, ensuring that all traffic from node components (e.g., kubelets, kube-proxy) and other control plane components is secured in transit.

Answer

kube-proxy

Answer

etcd

Answer

kube-scheduler

Question 4

A security team wants to use OPA/Gatekeeper to enforce that all namespaces must have a label 'security-tier' with value 'high' or 'medium'. What is the correct approach?

Accepted Answer

Create a ConstraintTemplate with Rego that denies namespaces missing the label, then create a Constraint referencing that template.. OPA/Gatekeeper enforces policies via a two-part model: a ConstraintTemplate defines the Rego logic (e.g., denying a namespace if it lacks the required label), and a Constraint instantiates that template with specific parameters (e.g., 'security-tier' with values 'high' or 'medium'). This decouples policy definition from enforcement, allowing Gatekeeper's admission webhook to reject non-compliant resources at creation or update time.

Answer

Write a MutatingWebhookConfiguration that adds the label automatically.

Answer

Use kubectl label command with a --validate flag.

Answer

Create a ValidatingWebhookConfiguration that directly contains the Rego policy.

Question 5

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?

Accepted Answer

Set --insecure-port=0 and ensure --secure-port=6443 is configured. 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.

Answer

Change the --insecure-port flag to 0

Answer

Set --insecure-port=6443

Answer

Set --secure-port=8080

Question 6

An OPA/Gatekeeper ConstraintTemplate is defined with the following Rego rule:

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  container.securityContext.runAsNonRoot != true
  msg := "Container must run as non-root"
}

What happens when a pod is submitted with a container that has runAsNonRoot: true?

Accepted Answer

The pod is admitted. The Rego rule `container.securityContext.runAsNonRoot != true` only triggers a violation when the field is not set to `true`. When `runAsNonRoot: true` is explicitly set, the condition evaluates to `false`, so no violation is generated, and the pod is admitted without any denial or mutation. OPA/Gatekeeper by default enforces constraints by denying admission; it does not mutate resources or generate audit logs unless specifically configured for dry-run or audit mode.

Answer

The pod is admitted but an audit log is generated

Answer

The pod is denied with a message

Answer

The pod is mutated to set runAsNonRoot

Question 7

Which of the following host access settings should be disabled to reduce the attack surface of a container?

Accepted Answer

hostPID: false. Setting `hostPID: false` explicitly disables the container's access to the host's process ID namespace, which reduces the attack surface by preventing the container from seeing or interacting with host processes. In Kubernetes, when `hostPID` is set to `true`, the container shares the host's PID namespace, allowing it to potentially escalate privileges or interfere with other workloads. Disabling this setting (i.e., `false`) is a recommended security best practice to enforce process isolation.

Answer

hostNetwork: true

Answer

hostPID: true

Answer

hostIPC: true

Question 8

After a security incident, you need to restrict which pods can communicate with each other in the 'finance' namespace. You want to allow only pods with label 'app: api' to connect to pods with label 'app: db' on TCP port 5432, and deny all other traffic. Which NetworkPolicy should you create?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: finance
spec:
  podSelector:
    matchLabels:
      app: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api
    ports:
    - port: 5432. It defines a NetworkPolicy that selects pods with label 'app: db' as the target and allows ingress traffic only from pods with label 'app: api' on TCP port 5432. By default, if no NetworkPolicy exists, all traffic is allowed; once a NetworkPolicy selects a pod, all traffic not explicitly allowed is denied. This policy therefore restricts communication to only the intended api-to-db flow on the specified port.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: finance
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: db
    ports:
    - port: 5432

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: finance
spec:
  podSelector:
    matchLabels:
      app: api
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: db
    ports:
    - port: 5432

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: finance
spec:
  podSelector:
    matchLabels:
      app: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api

Question 9

An administrator runs kube-bench on a cluster node and receives failures for CIS benchmark checks related to kubelet configuration. Which kubelet flag should be set to ensure that kernel defaults are not used when they might be insecure?

Accepted Answer

--protect-kernel-defaults. The `--protect-kernel-defaults` kubelet flag ensures that the kubelet will not use insecure kernel defaults by enforcing that certain sysctl settings (e.g., `kernel.panic`, `vm.overcommit_memory`) are set to secure values. If these kernel parameters are not explicitly configured to safe values, the kubelet will fail to start, preventing the node from running with potentially insecure kernel defaults. This directly addresses CIS benchmark checks that require hardening of the kubelet's interaction with the host kernel.

Answer

--read-only-port=0

Answer

--anonymous-auth=false

Answer

--kubelet-extra-args

Question 10

You are configuring encryption at rest for Kubernetes secrets. After creating an EncryptionConfiguration with aescbc provider, which additional step is required to enable encryption?

Accepted Answer

Restart the kube-apiserver with --encryption-provider-config flag. The EncryptionConfiguration resource defines how Kubernetes should encrypt data at rest, but it is not automatically applied. The kube-apiserver must be restarted with the `--encryption-provider-config` flag pointing to the configuration file so that it reads and enforces the encryption settings for all subsequent writes to etcd. Without this flag, the apiserver ignores the EncryptionConfiguration entirely.

Answer

Apply the EncryptionConfiguration as a ConfigMap

Answer

Restart the kube-scheduler

Answer

Recreate all secrets in the cluster

Question 11

You are asked to generate an SBOM for a container image and attach it as an attestation using cosign. Which two commands would you run in sequence?

Accepted Answer

syft myimage:latest -o spdx > sbom.spdx && cosign attest --type spdx --predicate sbom.spdx myimage:latest. It first uses Syft to generate an SPDX-format SBOM from the container image, then uses cosign attest to attach that SBOM as an in-toto attestation to the image. This sequence satisfies the requirement to generate an SBOM and attach it as an attestation using cosign.

Answer

trivy image --format spdx myimage:latest > sbom.spdx && cosign verify --key cosign.pub myimage:latest

Answer

cosign sign --key cosign.key myimage:latest && syft myimage:latest -o spdx

Answer

crane ls myimage:latest && cosign attest --type spdx --predicate sbom.spdx myimage:latest

Question 12

Which TWO AppArmor modes are available? (Select 2)

Accepted Answer

enforce. AppArmor has two operational modes: 'enforce' and 'complain'. In 'enforce' mode, AppArmor actively enforces the security policy, blocking actions that violate the profile and logging the denial. In 'complain' mode, AppArmor logs policy violations but does not block them, allowing administrators to test profiles before enforcing them.

Answer

audit

Answer

allow

Answer

unconfined

Question 13

An auditor requires that all audit logs from the Kubernetes API server be stored for 90 days and be tamper-proof. Which TWO measures should be implemented?

Accepted Answer

Configure the audit log backend to write to an immutable object store like S3 with Object Lock. Storing audit logs in an immutable object store like S3 with Object Lock ensures tamper-proof retention by preventing any object from being overwritten or deleted for a specified retention period. This directly satisfies the auditor's requirement for logs that cannot be altered or destroyed, regardless of the Kubernetes cluster state.

Answer

Enable the AuditDynamicConfiguration feature gate

Answer

Deploy Fluentd to forward logs to a central Elasticsearch cluster

Answer

Set --audit-log-maxbackup=10 and --audit-log-maxsize=100

Question 14

A developer wants to ensure that all containers in a pod run with a read-only root filesystem except for a specific volume mounted for writing logs. Which container-level security context field should be set to true?

Accepted Answer

readOnlyRootFilesystem. Setting `readOnlyRootFilesystem: true` in the container-level security context forces the container's root filesystem to be read-only, preventing any writes to the root filesystem. This is exactly what the developer needs to enforce immutability for the root filesystem while allowing writes only to a specific volume (e.g., for logs) mounted with write access. The field is a boolean in the `securityContext` of a container specification in Kubernetes.

Answer

allowPrivilegeEscalation

Answer

privileged

Answer

runAsNonRoot

Question 15

A microservice running as a Deployment in a Kubernetes cluster needs to authenticate to a third-party API using a static API key. Which is the most secure way to store and inject this secret into the container?

Accepted Answer

Store the API key in a Kubernetes Secret and mount it as a volume inside the container. Mounting a Kubernetes Secret as a volume provides the most secure method for injecting sensitive data into a container. Unlike environment variables, which can be exposed through process listings, container logs, or `/proc` filesystem, a volume mount stores the secret in the container's filesystem with permissions restricted to the runtime user. This approach also supports automatic rotation of secret values without restarting the pod, as the filesystem is updated in place when the Secret object changes.

Answer

Store the API key in a ConfigMap and expose it as an environment variable

Answer

Hardcode the API key in the container image

Answer

Store the API key in a Kubernetes Secret and expose it as an environment variable

Question 16

In a CI/CD pipeline, which step is MOST effective for detecting known vulnerabilities in a container image before deployment?

Accepted Answer

Run a vulnerability scan on the container image. Running a vulnerability scan on the container image (Option A) is the most effective step because it directly checks the image layers and installed packages against known Common Vulnerabilities and Exposures (CVEs) databases, such as the National Vulnerability Database (NVD). This identifies security flaws in base images and dependencies before deployment, which is a core requirement of supply chain security in Kubernetes.

Answer

Check the image size

Answer

Run unit tests on the application code

Answer

Lint the Dockerfile

Question 17

Which TWO of the following are valid audit stages in Kubernetes audit logging?

Accepted Answer

ResponseStarted. The Kubernetes audit stages include RequestReceived, ResponseStarted, ResponseComplete, and Panic. In the given options, ResponseStarted (A) and RequestReceived (E) are valid stages and are the two correct answers according to the question. Option C (ResponseComplete) is also a valid stage, but since the question explicitly asks for two, it is not selected as a correct answer here. Options B (ResponseDelay) and D (RequestProcessing) are not valid audit stages.

Answer

ResponseDelay

Answer

ResponseComplete

Answer

RequestProcessing

Question 18

Which TWO of the following are valid audit stages in Kubernetes audit logging?

Accepted Answer

ResponseComplete. Valid Kubernetes audit stages include RequestReceived, ResponseStarted, ResponseComplete, and Panic. All three options B (ResponseComplete), D (RequestReceived), and E (ResponseStarted) are valid audit stages. The question asks for two, but there are three valid options; thus, the correct set includes B, D, and E.

Answer

Authentication

Answer

Authorization

Question 19

In a Falco rule, you have the condition: 'evt.type=execve and proc.name=bash and container.id!=host'. What does this rule detect?

Accepted Answer

A bash shell being spawned inside a container. The rule triggers when a bash shell is executed (execve) inside any container (container.id != host). It does not check for interactive use; it simply detects bash execution.

Answer

A non-root bash process on the host

Answer

An interactive shell session inside a container

Answer

A bash process reading /etc/shadow

Question 20

Which TWO of the following are valid audit stages in Kubernetes?

Accepted Answer

Panic. Kubernetes audit stages include RequestReceived, ResponseStarted, ResponseComplete, and Panic. Among the given options, RequestReceived (D), ResponseStarted (C), and Panic (B) are all valid stages. Options A (ResponseReceived) and E (RequestSent) are not standard stages.

Answer

ResponseReceived

Answer

RequestSent