CKS Practice Test 45 — 15 Questions

Question 1

A security engineer wants to enforce that all images in the cluster must come from a trusted registry 'trusted-registry.io'. They are using OPA/Gatekeeper. Which constraint template and constraint combination would achieve this?

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

Accepted Answer

A constraint template that checks 'spec.containers[*].image' starts with 'trusted-registry.io/' and a constraint that denies if it does not.. The constraint template must enforce that container images originate from the trusted registry by checking that the image string starts with 'trusted-registry.io/'. This ensures that only images from that specific registry are allowed, and the constraint denies any pod that does not meet this condition. OPA/Gatekeeper uses Rego policies to evaluate the image field and reject non-compliant resources during admission control.

Answer

A constraint template that checks 'spec.containers[*].image' contains 'trusted-registry.io' and a constraint that denies if it does.

Answer

A constraint template that allows all images and a constraint that audits violations.

Answer

A constraint template that checks 'spec.containers[*].image' equals 'trusted-registry.io' and a constraint that denies if it does not.

Question 2

Which THREE of the following are valid methods to secure etcd?

Accepted Answer

Encrypt secrets at rest using EncryptionConfiguration. Kubernetes supports encrypting secrets at rest in etcd via an EncryptionConfiguration object. This configuration specifies which resources (e.g., secrets) should be encrypted and which encryption provider (e.g., AES-CBC, secretbox) to use, ensuring that data stored on disk is protected against unauthorized access to the etcd data directory.

Answer

Use HTTP instead of HTTPS to reduce overhead

Answer

Open etcd port 2379 to all network interfaces

Question 3

An administrator uses the following audit policy file for the Kubernetes API server to enable audit logging:
apiVersion: audit.k8s.io/v1
kind: Policy
metadata:
  name: audit-policy
rules:
- level: Metadata
  resources:
  - group: ""
    resources: ["secrets"]
Which audit level is being used for requests to the Secrets API?

Accepted Answer

Metadata. The manifest defines an audit policy rule with `level: Metadata` for the Secrets API (group: "", resources: ["secrets"]). The Metadata level logs only the metadata of the request—such as user, timestamp, and resource—without logging the request body or response body. Therefore, the correct audit level for requests to the Secrets API is Metadata.

Answer

RequestResponse

Answer

Request

Answer

None

Question 4

You have built a custom seccomp profile at /var/lib/kubelet/seccomp/audit.json. Which YAML snippet correctly applies this profile to a container?

Accepted Answer

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: "audit.json". The seccomp profile is stored at `/var/lib/kubelet/seccomp/audit.json`. The `localhostProfile` field expects a relative path from the base directory `/var/lib/kubelet/seccomp/`. Therefore, `audit.json` correctly resolves to the full path. The `seccompProfile` API with `type: Localhost` is the current method for applying custom profiles.

Answer

securityContext:
  seccompProfile:
    type: RuntimeDefault

Answer

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: "profiles/audit.json"

Answer

securityContext:
  seccomp:
    type: Localhost
    profile: "audit.json"

Question 5

A security team wants to ensure that all containers in a pod run with only the minimum required Linux capabilities. Which of the following approaches is BEST?

Accepted Answer

Set securityContext.capabilities.drop: ['ALL'] and add only necessary capabilities. It implements the principle of least privilege by first dropping all capabilities with `drop: ['ALL']` and then explicitly adding back only those capabilities that are strictly necessary for the container to function. This ensures that the container runs with the absolute minimum set of Linux capabilities, reducing the attack surface and adhering to Kubernetes security best practices for system hardening.

Answer

Set securityContext.capabilities.drop: ['ALL'] with no add

Answer

Leave capabilities unset to use the default set

Answer

Add only the necessary capabilities without dropping

Question 6

A security team wants to enforce that containers in a specific namespace cannot gain new capabilities. Which Pod security context field is used to achieve this?

Accepted Answer

allowPrivilegeEscalation: false. `allowPrivilegeEscalation: false` directly controls whether a process can gain more privileges than its parent, which is the mechanism by which containers acquire new capabilities (e.g., via `setuid` binaries or `file capabilities`). Setting this to `false` prevents privilege escalation within the container, effectively blocking the acquisition of new capabilities beyond those initially granted. This field is defined in the Pod Security Context and is a key control for minimizing microservice vulnerabilities.

Answer

capabilities.drop: ["ALL"]

Answer

privileged: false

Answer

runAsNonRoot: true

Question 7

Which TWO of the following are valid Pod Security Context settings to harden a container? (Select 2)

Accepted Answer

runAsNonRoot: true. Setting `runAsNonRoot: true` in the Pod Security Context forces the container to run with a user ID (UID) other than 0 (root). This is a fundamental hardening measure that prevents an attacker who gains code execution inside the container from having root privileges, thereby limiting the blast radius of a compromise. It is a recommended practice in the CIS Benchmark for Kubernetes and directly addresses the principle of least privilege.

Answer

privileged: true

Answer

runAsUser: 0

Answer

allowPrivilegeEscalation: true

Question 8

A security audit reveals that a Deployment uses an image with a mutable tag 'app:latest'. Which change ensures the image is immutable and traceable?

Accepted Answer

Use 'image: app@sha256:abc123...'. Using the image digest (e.g., `image: app@sha256:abc123...`) pins the container image to an immutable, content-addressable identifier. Unlike mutable tags, the digest is a cryptographic hash of the image manifest, ensuring that every pull returns the exact same image, which is critical for traceability and supply chain security.

Answer

Change tag to 'app:stable'

Answer

Set 'replicas: 1'

Answer

Add 'imagePullPolicy: Always'

Question 9

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?

Accepted Answer

Re-create the existing secrets. 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.

Answer

Restart the kube-apiserver

Answer

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

Answer

Nothing, the existing secrets are automatically encrypted

Question 10

Which TWO of the following are valid methods to enforce mTLS in an Istio service mesh? (Select 2)

Accepted Answer

Create a PeerAuthentication resource with mtls.mode: STRICT. A PeerAuthentication resource with `mtls.mode: STRICT` enforces mutual TLS at the service-to-service communication level within the Istio mesh. This setting ensures that all traffic between sidecar proxies uses mTLS, rejecting any plaintext connections, which directly minimizes the risk of unauthorized access or eavesdropping.

Answer

Create a ServiceEntry for internal services

Answer

Create a VirtualService with tls termination

Answer

Set global.mtls.enabled: true in IstioConfigMap

Question 11

Which tool is commonly used to generate a Software Bill of Materials (SBOM) for a container image?

Accepted Answer

syft. Syft is a CLI tool purpose-built for generating Software Bill of Materials (SBOMs) from container images and filesystems. It uses static analysis to extract package metadata (e.g., dpkg, RPM, APK, Python, Node.js) and outputs the SBOM in formats like CycloneDX or SPDX, which are the industry standards for supply chain transparency.

Answer

kubesec

Answer

trivy

Answer

cosign

Question 12

An admin runs 'kubectl run test-pod --image=nginx:latest' and the Pod is created but immediately enters 'CrashLoopBackOff'. 'kubectl describe pod test-pod' shows 'Back-off restarting failed container'. Which admission controller might cause this if misconfigured?

Accepted Answer

MutatingAdmissionWebhook. A MutatingAdmissionWebhook can modify Pod specifications (e.g., injecting sidecar containers, changing image names, or adding init containers) before the Pod is persisted. If the webhook misconfigures the Pod—such as replacing the image with a non-existent one or adding a failing init container—the container may fail to start, causing a CrashLoopBackOff. The 'Back-off restarting failed container' message indicates the container itself is failing, which aligns with a mutation that breaks the Pod's runtime behavior.

Answer

ValidatingAdmissionWebhook

Answer

PodSecurity

Answer

PersistentVolumeClaimResize

Question 13

A security policy requires that all pods drop ALL Linux capabilities and disable privilege escalation. Which YAML snippet correctly implements this in the pod's security context?

Accepted Answer

securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]. It explicitly drops all Linux capabilities with `capabilities: drop: ["ALL"]` and disables privilege escalation with `allowPrivilegeEscalation: false`. This satisfies the security policy requirement to remove all capabilities and prevent any process from gaining more privileges than its parent, which is essential for minimizing container breakout risks.

Answer

securityContext:
  privileged: false
  capabilities:
    drop: ["ALL"]

Answer

securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    add: ["NET_ADMIN"]

Answer

securityContext:
  capabilities:
    drop: ["ALL"]

Question 14

Which TWO of the following are best practices for minimizing microservice vulnerabilities in a Kubernetes cluster?

Accepted Answer

Enable mutual TLS (mTLS) for service-to-service communication using a service mesh.. Mutual TLS (mTLS) encrypts and authenticates all service-to-service traffic within the cluster, preventing eavesdropping, man-in-the-middle attacks, and unauthorized access. A service mesh like Istio or Linkerd transparently enforces mTLS without requiring application code changes, ensuring that only verified services can communicate. This directly minimizes the attack surface for microservice vulnerabilities by enforcing zero-trust network principles.

Answer

Run containers as root to avoid permission issues.

Answer

Allow all egress traffic from pods to simplify network management.

Answer

Use hostNetwork: true for pods to improve network performance.

Question 15

Which of the following seccomp profile types should be used to apply the container runtime's default seccomp profile?

Accepted Answer

RuntimeDefault. The `RuntimeDefault` seccomp profile type instructs the container runtime (e.g., containerd, CRI-O) to apply its own built-in default seccomp profile. This profile is defined by the runtime and typically blocks around 44 system calls that are considered dangerous or unnecessary for containers, providing a secure baseline without requiring a custom profile.

Answer

Unconfined

Answer

Default

Answer

Localhost