CKS Practice Test 14 — 15 Questions

Question 1

A security admin wants to drop all Linux capabilities for a container and then add only CAP_NET_BIND_SERVICE. Which YAML snippet correctly achieves this?

Accepted Answer

securityContext:
  capabilities:
    drop: ['ALL']
    add: ['NET_BIND_SERVICE']. It uses the standard Kubernetes `securityContext.capabilities` field with `drop: ['ALL']` to remove all Linux capabilities from the container, then `add: ['NET_BIND_SERVICE']` to grant only the `CAP_NET_BIND_SERVICE` capability. This is the proper YAML syntax for the desired capability set.

Answer

securityContext:
  capabilities:
    drop: ['ALL']
    add: ['NET_BIND_SERVICE']
  privileged: true

Answer

securityContext:
  capabilities:
    drop: ['NET_BIND_SERVICE']
    add: ['ALL']

Answer

securityContext:
  capDrop: ['ALL']
  capAdd: ['NET_BIND_SERVICE']

Question 2

You have configured Kyverno to enforce that all Pods must have an image from a trusted registry. However, a newly created Pod is not being rejected even though it uses an untrusted image. What is the most likely reason?

Accepted Answer

The Kyverno webhook is not invoked because the failure policy is set to Ignore or the resource is not matched by the policy's rules. Kyverno operates as a dynamic admission controller via a MutatingAdmissionWebhook or ValidatingAdmissionWebhook. If the webhook's failure policy is set to `Ignore`, the webhook will not block the Pod creation when it fails to invoke, and the Pod will be admitted. Additionally, if the policy's rules do not match the Pod (e.g., due to incorrect resource selection or namespace exclusion), the webhook will not be triggered, allowing untrusted images through.

Answer

Kyverno is not an admission controller; it only mutates resources

Answer

The Kyverno policy requires an external registry to compare images, which is unavailable

Answer

The Pod was created by a Deployment controller, which bypasses admission control

Question 3

Which THREE of the following are valid methods to restrict access to the Kubernetes Dashboard? (Choose three.)

Accepted Answer

Use a ClusterIP service and only allow access via kubectl proxy. Using a ClusterIP service restricts the Dashboard to internal cluster access only. Access is then granted exclusively through `kubectl proxy`, which creates a local proxy server that authenticates the user via their kubeconfig context, ensuring that only authenticated and authorized users can reach the Dashboard without exposing it to the network.

Answer

Expose the Dashboard via a NodePort service to the internet

Answer

Deploy the Dashboard with a hostNetwork: true configuration

Question 4

You want to run a workload in a sandboxed container using gVisor. You have created a RuntimeClass named 'gvisor' that references the 'runsc' handler. Which of the following Pod specs correctly uses this RuntimeClass?

Accepted Answer

apiVersion: v1
kind: Pod
metadata:
  name: sandbox-pod
spec:
  runtimeClassName: gvisor
  containers:
  - name: app
    image: nginx. The `runtimeClassName` field in the Pod spec is the standard Kubernetes API field used to specify a RuntimeClass for a Pod. The RuntimeClass named 'gvisor' must be defined in the cluster with a handler 'runsc', and setting `runtimeClassName: gvisor` in the Pod spec instructs the kubelet to use the gVisor runtime (runsc) to run the containers in a sandboxed environment, minimizing microservice vulnerabilities.

Answer

apiVersion: v1
kind: Pod
metadata:
  name: sandbox-pod
  annotations:
    runtimeClass: gvisor
spec:
  containers:
  - name: app
    image: nginx

Answer

apiVersion: v1
kind: Pod
metadata:
  name: sandbox-pod
spec:
  nodeSelector:
    runtime: gvisor
  containers:
  - name: app
    image: nginx

Answer

apiVersion: v1
kind: Pod
metadata:
  name: sandbox-pod
spec:
  runtimeClass:
    name: gvisor
  containers:
  - name: app
    image: nginx

Question 5

Which TWO of the following are best practices for Dockerfile security according to CKS guidelines?

Accepted Answer

RUN adduser -D myuser && USER myuser. It creates a dedicated non-root user (`adduser -D myuser`) and then switches to that user with `USER myuser`, ensuring the container runs without root privileges. This aligns with the CKS best practice of least privilege, reducing the risk of privilege escalation if the container is compromised. The `-D` flag in Alpine's `adduser` creates a user without a password, which is appropriate for containerized environments.

Answer

RUN useradd -m myuser && USER root

Answer

COPY --from=builder /app /app

Answer

FROM alpine:latest

Question 6

Which THREE of the following are best practices for reducing the attack surface of a Kubernetes node?

Accepted Answer

Run containers with non-root user and drop all capabilities. Option A is correct because running containers as a non-root user and dropping all Linux capabilities (e.g., via securityContext runAsNonRoot: true and capabilities.drop: ["ALL"]) prevents a compromised container from gaining root privileges or abusing kernel capabilities on the node. Option C is correct because disabling unneeded host services such as Bluetooth (bluetooth.service) and ModemManager (ModemManager.service) removes daemons and attack vectors that are irrelevant to a Kubernetes node's role. Option E is correct because a read-only root filesystem (securityContext readOnlyRootFilesystem: true) blocks attackers from writing malicious binaries or modifying files inside the container, limiting persistence and lateral movement. Option B is not a best practice as stated: installing all available packages increases the attack surface, whereas the correct practice is to apply security patches and keep the installed package set minimal. Option D is not a best practice because removing SSH access from all nodes eliminates a legitimate administrative and troubleshooting channel; SSH should instead be restricted, key-based, and network-limited rather than universally removed.

Answer

Install all available security patches and packages

Answer

Remove SSH access from all nodes

Question 7

Developer A runs 'cosign verify --key cosign.pub myregistry/myimage:tag' and receives an error: 'No signatures found'. Developer B previously ran 'cosign sign --key cosign.key myregistry/myimage:tag'. What is the most likely cause of the verification failure?

Accepted Answer

The signing command failed to push the signature to the registry. The error 'No signatures found' indicates that the verification process could not locate any signature associated with the image in the registry. Since Developer B attempted to sign the image with 'cosign sign', the most likely cause is that the signing command failed to push the signature artifact (typically stored as a separate tag like 'myimage:sha256-<digest>.sig' in the same registry) to the registry. Without the signature being successfully uploaded, the 'cosign verify' command finds nothing to validate against the provided public key.

Answer

The image tag does not exist in the registry

Answer

Developer B used a different private key to sign than the public key used for verification

Answer

Developer A used the public key instead of the private key

Question 8

A security team wants to ensure that only container images from a trusted registry (mytrustedregistry.io) are deployed in the cluster. They plan to use OPA/Gatekeeper. Which kind of Gatekeeper constraint template and constraint should they create?

Accepted Answer

A constraint that uses a pattern to match the image field against allowed registries. OPA/Gatekeeper enforces policies via constraint templates that define Rego rules. To restrict container images to a trusted registry, you create a constraint template that inspects the `spec.containers[*].image` field in the Pod spec and uses a pattern (e.g., regex or prefix match) to ensure the image string starts with `mytrustedregistry.io/`. The constraint then applies this template to the cluster, rejecting any Pod that references an image from an untrusted registry.

Answer

A constraint that validates the cluster's registry mirror configuration

Answer

A constraint that inspects the image field in the Pod's metadata annotations

Answer

A constraint that checks the imagePullSecrets field in the Pod spec

Question 9

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?

Accepted Answer

Upgrade the control plane from 1.21 to 1.22 first, then upgrade worker nodes. 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.

Answer

Upgrade worker nodes first, then the control plane

Answer

Upgrade etcd to 1.22 first, then the API server

Answer

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

Question 10

Which of the following is NOT a valid seccomp profile type in Kubernetes?

Accepted Answer

SeccompDefault. SeccompDefault is not a valid seccomp profile type in Kubernetes. The valid profile types are Unconfined, RuntimeDefault, and Localhost. SeccompDefault is a feature gate (introduced in Kubernetes 1.22) that, when enabled, tells the kubelet to use the RuntimeDefault seccomp profile by default for pods, but it is not itself a profile type.

Answer

Unconfined

Answer

RuntimeDefault

Answer

Localhost

Question 11

An administrator wants to enforce mTLS between all services in the 'mesh' namespace using Istio. Which resource should be applied to require mutual TLS for all workloads in that namespace?

Accepted Answer

PeerAuthentication with mtls.mode: STRICT in the namespace. PeerAuthentication defines the authentication policy for workloads within a namespace. Setting `mtls.mode: STRICT` in a PeerAuthentication resource for the 'mesh' namespace enforces that all services in that namespace require mutual TLS for incoming traffic, ensuring that only authenticated and encrypted connections are accepted. This is the correct Istio resource to enforce mTLS at the namespace level.

Answer

VirtualService with tls mode

Answer

DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

Answer

ServiceEntry for external services

Question 12

An etcd cluster is configured with TLS. You need to enforce that only the API server can read and write to etcd. Which method should you use?

Accepted Answer

Configure etcd RBAC with a role that grants readwrite access only to the API server's client certificate CN. Etcd supports Role-Based Access Control (RBAC) that can restrict access based on the Common Name (CN) in the client certificate. By creating a role with readwrite access and binding it only to the API server's client certificate CN, you ensure that only the API server can read and write to etcd, while other clients are denied.

Answer

Set etcd's --peer-client-cert-auth flag to true

Answer

Set etcd's --client-cert-auth flag to false

Answer

Use a NetworkPolicy to restrict access to etcd port 2379

Question 13

A Gatekeeper Constraint is not blocking pods that violate the policy. The constraint references a ConstraintTemplate that has been successfully created. What is the most likely cause?

Accepted Answer

The Constraint has 'enforcementAction: dryrun'. When a Gatekeeper Constraint has `enforcementAction: dryrun`, it logs violations but does not block pod creation or updates. This is the most likely cause because the constraint is correctly configured and the ConstraintTemplate exists, but the enforcement action is set to dryrun instead of the default `deny`.

Answer

The Constraint is missing the 'match' field

Answer

The Constraint is in a different namespace than the pods

Answer

The ConstraintTemplate is missing the 'violation' rule

Question 14

A security engineer runs the following command to inspect a pod's security context:

kubectl get pod secure-pod -o jsonpath='{.spec.containers[0].securityContext.capabilities}'

The output is: {"drop":["ALL"]}

What does this indicate?

Accepted Answer

The container has all Linux capabilities dropped. The output `{"drop":["ALL"]}` indicates that the container's security context explicitly drops all Linux capabilities via the `drop` field. This is a common security hardening practice to reduce the attack surface by removing all privileged operations, such as `CAP_NET_ADMIN` or `CAP_SYS_ADMIN`, from the container's effective capability set.

Answer

The output is invalid because capabilities should be in add field

Answer

The container has no capability restrictions

Answer

The container has only the NET_ADMIN capability added

Question 15

Which kubectl command creates a secret named 'mysecret' from a file called 'credentials.json'?

Accepted Answer

kubectl create secret generic mysecret --from-file=credentials.json. `kubectl create secret generic` is the command to create a generic (opaque) secret from a file. The `--from-file` flag reads the contents of `credentials.json` and stores them as the secret's data, using the filename as the key by default. This is the standard method for injecting sensitive file-based data into a Kubernetes secret.

Answer

kubectl apply -f credentials.json

Answer

kubectl create configmap mysecret --from-file=credentials.json

Answer

kubectl create secret tls mysecret --cert=credentials.json