CKS Practice Test 4 — 25 Questions

Question 1

A security admin runs 'trivy image --severity CRITICAL,HIGH myrepo/myapp:latest' and sees many CVEs. The admin wants to ensure that only images with no CRITICAL or HIGH severity vulnerabilities are deployed to the cluster. Which admission controller should be configured to enforce this policy?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

ImagePolicyWebhook. The ImagePolicyWebhook admission controller is specifically designed to evaluate container images against an external policy backend before they are admitted into the cluster. By configuring it to reject images with CRITICAL or HIGH severity vulnerabilities (as reported by Trivy), the admin can enforce that only compliant images are deployed. This controller intercepts Pod creation requests and queries an external webhook to decide whether to allow or deny the image based on the policy.

Answer

PodSecurityPolicy

Answer

ValidatingAdmissionWebhook

Answer

MutatingAdmissionWebhook

Question 2

A Falco rule is written to detect when a shell is spawned inside a container. The rule condition is: `spawned_process and container and proc.name = bash`. The rule is not triggering. Which of the following is the most likely reason?

Accepted Answer

The `spawned_process` macro may not match because the process was inherited (not spawned), e.g., from an entrypoint. The `spawned_process` macro in Falco specifically matches processes that are created via `execve` or `fork` system calls. If a shell is inherited from the container's entrypoint (e.g., the container runs `bash` as PID 1 directly), it is not considered a spawned process but rather the initial process of the container. Falco's default `spawned_process` macro filters out such inherited processes, so the rule condition fails to match even though `proc.name = bash` is true.

Answer

The rule is missing `proc.name in (bash, sh, zsh)` because only bash is checked

Answer

Falco is not running with the required syscall capabilities

Answer

The priority is set to `ERROR` but the output is being filtered

Question 3

Which TWO of the following are valid arguments for the kubectl command to create a secret from a file? (Select TWO)

Accepted Answer

--from-file. Options D and E are correct because both --from-file and --from-env-file are valid arguments for the kubectl create secret command when creating a secret from a file. --from-file reads the entire file content and uses the filename as the key. --from-env-file reads a file containing key=value lines, which is suitable for environment variable-style secrets. Option B (--from-literal) is incorrect because it specifies key-value pairs directly on the command line, not from a file. Option A (--dry-run) is a flag, not an argument for specifying secret data. Option C (--from-yaml) is not a valid argument for kubectl create secret.

Answer

--dry-run

Answer

--from-literal

Answer

--from-yaml

Question 4

A pod running in the cluster is in a CrashLoopBackOff state. You run 'kubectl describe pod <pod>' and see the following event: 'Warning BackOff Back-off restarting failed container'. Which command would you run to see the standard error output of the container?

Accepted Answer

kubectl logs --previous. `kubectl logs --previous` retrieves the logs from the previous instance of a crashed or restarting container. When a pod is in CrashLoopBackOff, the current container may have already restarted, so the standard error output from the failed run is only available in the previous container's logs. This command specifically fetches those logs, which typically contain the stderr output that caused the crash.

Answer

kubectl exec <pod> -- cat /var/log/syslog

Answer

kubectl describe pod <pod>

Answer

kubectl logs <pod>

Question 5

You want to run a container with gVisor (runsc) runtime for sandboxing. Which resource is required to use a non-default runtime?

Accepted Answer

RuntimeClass resource. In Kubernetes, to use a non-default runtime like gVisor (runsc), you must define a RuntimeClass resource that references the runtime handler (e.g., 'runsc') configured on the node. The RuntimeClass acts as a bridge between the Pod spec and the node's container runtime configuration, allowing the scheduler to select the appropriate runtime for sandboxing. Without a RuntimeClass, the default runtime (typically runc) is used, which does not provide the same isolation level.

Answer

PodSecurityPolicy

Answer

ContainerRuntime resource

Answer

Node runtime configuration only

Question 6

You need to encrypt Kubernetes secrets at rest. Which resource should you configure?

Accepted Answer

EncryptionConfiguration. Kubernetes uses an `EncryptionConfiguration` object to configure encryption at rest for secrets and other resources in etcd. This YAML-based resource defines which providers (e.g., `aescbc`, `kms`, `secretbox`) are used to encrypt data before it is written to the underlying storage. The API server reads this configuration from a file specified via the `--encryption-provider-config` flag, enabling transparent encryption and decryption of resource data.

Answer

EncryptionProvider

Answer

SecretEncryptionConfig

Answer

KMSProvider

Question 7

You need to enforce that all pods in the 'production' namespace run with read-only root filesystems. Which OPA Gatekeeper resource do you create first?

Accepted Answer

A ConstraintTemplate containing a Rego policy that checks for readOnlyRootFilesystem: true. OPA Gatekeeper requires a ConstraintTemplate first to define the Rego policy logic that checks for `readOnlyRootFilesystem: true`. The ConstraintTemplate is a custom resource that tells Gatekeeper what rule to enforce; without it, you cannot create a Constraint to apply the policy to the 'production' namespace. This follows the Gatekeeper workflow: template → constraint → enforcement via admission webhooks.

Answer

A ConfigMap containing the Rego policy, then reference it in a custom admission controller

Answer

A Constraint resource that enforces the readOnlyRootFilesystem rule

Answer

A ValidatingWebhookConfiguration that points to the Gatekeeper service

Question 8

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 9

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 10

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 11

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 12

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 13

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 14

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 15

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 16

Which admission plugin is recommended by the CIS Kubernetes Benchmark to restrict the kubelet's ability to modify nodes?

Accepted Answer

NodeRestriction. The NodeRestriction admission plugin is recommended by the CIS Kubernetes Benchmark to restrict the kubelet's ability to modify nodes. It limits the kubelet's permissions to only modify its own node and its own pods, preventing it from altering other nodes or performing unauthorized operations. This plugin enforces a security boundary by rejecting requests that attempt to modify node labels, taints, or status outside the kubelet's assigned scope.

Answer

PodNodeSelector

Answer

SecurityContextDeny

Answer

AlwaysPullImages

Question 17

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

Accepted Answer

container.apparmor.security.beta.kubernetes.io/. The AppArmor profile for a container in a pod is specified using the annotation `container.apparmor.security.beta.kubernetes.io/`, where `` 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.

Answer

apparmor.security.kubernetes.io/profile

Answer

security.kubernetes.io/apparmor

Answer

seccomp.security.alpha.kubernetes.io/pod

Question 18

You need to encrypt Kubernetes secrets at rest using aescbc. Which YAML snippet defines the EncryptionConfiguration correctly?

Accepted Answer

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: MDEyMzQ1Njc4OWFiY2RlZjAxMjM0NTY3ODlhYmNkZWY=
  - identity: {} [CORRECT]. It defines an EncryptionConfiguration with the correct apiVersion (apiserver.config.k8s.io/v1), kind (EncryptionConfiguration), and a valid provider list. It uses the aescbc provider with a base64-encoded 32-byte key (MDEyMzQ1Njc4OWFiY2RlZjAxMjM0NTY3ODlhYmNkZWY=) for encrypting secrets, and includes the identity provider as a fallback to allow reading existing unencrypted data. This configuration ensures that secrets are encrypted at rest using AES-CBC with a properly encoded 32-byte key.

Answer

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: my-plain-text-key

Answer

apiVersion: v1
kind: EncryptionConfig
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: c2VjcmV0LWtleS0zMi1ieXRlcw==

Answer

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - secretbox:
      keys:
      - name: key1
        secret: c2VjcmV0LWtleS0zMi1ieXRlcw==

Question 19

A DevOps engineer is setting up a CI/CD pipeline to scan container images for vulnerabilities. They want to fail the pipeline if any critical vulnerabilities are found. Which command should they use to scan the image and produce a JSON output that can be parsed?

Accepted Answer

trivy image --severity CRITICAL --format json myimage:tag. `trivy image` scans a container image. Use `--severity CRITICAL` to filter only critical vulnerabilities and `--format json` to produce machine-parseable JSON output. This lets the pipeline parse the JSON and fail on critical vulnerabilities. Note: `--output` specifies an output file path, not the report format.

Answer

trivy fs --severity CRITICAL --output json .

Answer

trivy image --format table myimage:tag

Answer

trivy image --severity HIGH myimage:tag

Question 20

To verify a signed container image, which command should be used?

Accepted Answer

cosign verify myimage:latest. The `cosign verify` command is the correct tool for verifying the cryptographic signature of a signed container image stored in an OCI-compliant registry. Cosign, part of the Sigstore project, uses public-key or keyless signing to ensure image integrity and authenticity. The command checks the signature against the image manifest and the provided public key or Fulcio certificate, confirming that the image has not been tampered with since signing.

Answer

trivy verify myimage:latest

Answer

kubectl verify myimage:latest

Answer

cosign validate myimage:latest