CKS Practice Exam 56 — 20 Questions

Question 1

A security scan report shows that a container image has several high-severity CVEs. The team wants to implement automated scanning in CI/CD pipeline. Which tool would you recommend for scanning container images in a CI pipeline?

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

Accepted Answer

Trivy. Trivy is a comprehensive, open-source vulnerability scanner specifically designed for container images, filesystems, and Git repositories. It integrates seamlessly into CI/CD pipelines, detects high-severity CVEs by cross-referencing image layers against multiple vulnerability databases (e.g., NVD, Red Hat, Alpine), and provides actionable remediation advice. This makes it the correct choice for automated scanning of container images in a CI pipeline.

Answer

Syft

Answer

Checkov

Answer

Kubesec

Question 2

An administrator wants to ensure that only images from a trusted registry 'myregistry.io' can run in the cluster. Which admission controller should be configured?

Accepted Answer

ImagePolicyWebhook. The ImagePolicyWebhook admission controller enforces that only images from a trusted registry (e.g., 'myregistry.io') can run. It does this by querying an external webhook to validate the image source against a policy. Options A, B, and D are incorrect: NodeRestriction restricts node API access, MutatingAdmissionWebhook can mutate pods but is not specifically designed for image registry control, and PodSecurity handles pod security contexts, not image source validation.

Answer

NodeRestriction

Answer

MutatingAdmissionWebhook

Answer

PodSecurity

Question 3

Which TWO of the following tools can be used to generate or analyze SBOMs? (Select 2)

Accepted Answer

Syft. Syft is a CLI tool specifically designed to generate Software Bill of Materials (SBOMs) from container images and filesystems. It supports multiple output formats such as CycloneDX and SPDX, making it a direct choice for SBOM generation. Trivy, while primarily a vulnerability scanner, also includes built-in SBOM generation and analysis capabilities, allowing users to output SBOMs in CycloneDX or SPDX formats and to scan existing SBOMs for vulnerabilities.

Answer

Cosign

Answer

Kubesec

Answer

Checkov

Question 4

An organization wants to implement supply chain security by signing all container images and verifying them before deployment. Which combination of tools is appropriate?

Accepted Answer

Cosign and Kyverno. Cosign is the tool for signing container images and storing signatures in an OCI-compliant registry, while Kyverno is a Kubernetes admission controller that can enforce policies to verify those signatures before allowing pod deployment. Together, they implement the full supply chain security workflow: signing images at build time and verifying them at deploy time via Kyverno's `verifyImages` rule.

Answer

Snyk and OPA

Answer

Trivy and Syft

Answer

Clair and Notary

Question 5

Which TWO of the following are effective methods to harden the kubelet against unauthorized access?

Accepted Answer

Enable --authentication-token-webhook. To harden the kubelet's own HTTPS endpoint, enable --authentication-token-webhook to validate bearer tokens via the Kubernetes TokenReview API, and configure --client-ca-file with --tls-cert-file to require and validate client certificates. NodeRestriction is an admission controller that limits what the kubelet can modify in the API server; it does not protect the kubelet endpoint from unauthorized access.

Answer

Set --read-only-port=10255

Answer

Enable the NodeRestriction admission controller

Answer

Set --anonymous-auth=true

Question 6

You have enabled encryption at rest for Kubernetes Secrets by configuring an EncryptionConfiguration object and restarting the API server. After the configuration, you create a new Secret. However, when you retrieve the Secret using 'kubectl get secret mysecret -o yaml', the 'data' field still shows base64-encoded plaintext. Is the Secret encrypted at rest?

Accepted Answer

Yes, because encryption at rest applies to the storage layer (etcd), not the API response.. Encryption at rest in Kubernetes protects data when it is stored in etcd, the underlying key-value store. The API server decrypts the data transparently when serving it via the API, so the base64-encoded plaintext visible in `kubectl get secret -o yaml` is the decrypted output, not the raw encrypted data. The EncryptionConfiguration object ensures that new or updated Secrets are encrypted before being written to etcd, but the API response always shows the plaintext after decryption.

Answer

No, because only Secrets in namespaces with a specific annotation are encrypted.

Answer

Yes, but only if the Secret was created after the API server restart.

Answer

No, because the data is still visible in the API response.

Question 7

Which of the following is a recommended Dockerfile best practice to improve container security?

Accepted Answer

Use a non-root user with USER directive. Running containers as root is a major security risk; if an attacker compromises the container, they gain root access to the container and potentially the host via kernel exploits. The USER directive in a Dockerfile switches the container's runtime user to a non-root user (e.g., USER 1000), reducing the blast radius by limiting privileges within the container. This aligns with the principle of least privilege and is a recommended best practice in the CKS exam for supply chain security.

Answer

Hardcode secrets in environment variables in the Dockerfile

Answer

Run the container as root to simplify permission management

Answer

Copy the entire host filesystem into the image

Question 8

A developer wants to sign a container image using Cosign. Which command should they run after building and pushing the image to a registry?

Accepted Answer

cosign sign myrepo/myapp:latest. The `cosign sign` command is used to sign a container image and attach the signature to the image in the registry. After building and pushing the image, running `cosign sign myrepo/myapp:latest` generates a digital signature using a private key and stores it as an OCI artifact (e.g., `sha256-...sig`) in the same registry, enabling later verification of the image's integrity and origin.

Answer

cosign verify myrepo/myapp:latest

Answer

cosign attest myrepo/myapp:latest

Answer

cosign generate-key-pair

Question 9

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

Accepted Answer

crictl logs . `crictl logs ` 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.

Answer

crictl exec <container-id>

Answer

crictl inspect <container-id>

Answer

crictl ps

Question 10

You want to scan a container image for vulnerabilities before deploying it. Which command uses the Trivy tool to scan an image?

Accepted Answer

trivy image nginx:latest. Trivy uses the `image` subcommand to scan a container image for vulnerabilities. The correct syntax is `trivy image <image_name>`, which pulls the image (if not already present) and scans its OS packages and application dependencies against known vulnerability databases. Option B is correct because it follows this exact syntax.

Answer

trivy check nginx:latest

Answer

trivy fs nginx:latest

Answer

trivy scan nginx:latest

Question 11

You have a requirement to encrypt secrets at rest in etcd. Which resource and apiVersion should be used?

Accepted Answer

EncryptionConfiguration with apiVersion apiserver.config.k8s.io/v1. The Kubernetes API server uses an `EncryptionConfiguration` resource with `apiVersion apiserver.config.k8s.io/v1` to define how secrets and other resources are encrypted at rest in etcd. This resource specifies providers (e.g., `aescbc`, `secretbox`) and keys, and is loaded via the `--encryption-provider-config` flag on the API server. The `v1` version is the stable, production-ready API version for this configuration.

Answer

EtcdEncryption with apiVersion apiserver.config.k8s.io/v1beta1

Answer

EncryptionConfig with apiVersion v1

Answer

SecretEncryption with apiVersion v1

Question 12

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

Accepted Answer

kms. 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.

Answer

identity

Answer

base64

Question 13

Which TWO of the following are valid AppArmor profile modes?

Accepted Answer

Complain. 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.

Answer

Audit

Answer

Disable

Answer

Permissive

Question 14

Which THREE of the following security context settings help mitigate container breakout attacks? (Select 3)

Accepted Answer

readOnlyRootFilesystem: true. Option A (readOnlyRootFilesystem: true) is correct because mounting the container's root filesystem read-only prevents an attacker who gains code execution from writing malicious binaries, scripts, or modifying system files needed to escalate or persist during a breakout attempt. Option C (allowPrivilegeEscalation: false) is correct because it sets the kernel's no_new_privs flag on the container process, blocking setuid/setgid binaries and file capabilities from granting the process more privileges than its parent — a key vector for escaping to the host. Option E (runAsNonRoot: true) is correct because it forces the container to run as a non-root UID, so even if the process escapes the container boundary it lacks root privileges on the host, dramatically reducing the impact of a breakout. Option B (privileged: true) is not correct because privileged containers get all Linux capabilities and direct device access, which is precisely what enables breakouts rather than mitigating them. Option D (capabilities: add: ['NET_ADMIN']) is not correct because adding NET_ADMIN expands the container's kernel attack surface (e.g., manipulating network interfaces, iptables), increasing breakout risk instead of reducing it.

Answer

privileged: true

Answer

capabilities: add: ['NET_ADMIN']

Question 15

A security engineer needs to verify that a container image pulled from a private registry was signed by the organization's authorized build pipeline before allowing it to run in the cluster. The signatures are stored alongside the image in the OCI registry. Which command should the engineer use to perform this verification?

Accepted Answer

cosign verify --key cosign.pub registry.example.com/app:1.2.3. To verify an image's signature in an OCI registry, cosign verify is the correct command. It uses the public key to validate the signature, ensuring the image was signed by the trusted private key. This step is critical in a supply chain security workflow to prevent running unauthorized or tampered images.

Answer

cosign sign --key cosign.key registry.example.com/app:1.2.3

Answer

cosign attach signature --signature sig.json registry.example.com/app:1.2.3

Answer

cosign generate-key-pair

Question 16

A security team is hardening a cluster where the kube-apiserver is started with the flag --authorization-mode=Node,RBAC. A penetration test reveals that kubelet authentication is using anonymous requests and the webhook authorizer is not enabled. To ensure that kubelet API requests are authenticated and authorized, which combination of kubelet configuration changes should be applied?

Accepted Answer

Set authentication.anonymous.enabled=false and authorization.mode=Webhook in the kubelet config file.. The correct configuration disables anonymous authentication and sets the kubelet authorization mode to Webhook. This forces all kubelet API requests to be authenticated and then authorized by the API server, eliminating anonymous access and ensuring only authorized actions are allowed. This directly remediates the penetration test finding and is a fundamental step in cluster hardening.

Answer

Set authentication.webhook.enabled=true and authorization.mode=Node in the kubelet config file.

Answer

Set authentication.x509.clientCAFile to a valid CA and authorization.mode=AlwaysAllow in the kubelet config file.

Answer

Set authentication.anonymous.enabled=true and authorization.mode=AlwaysAllow in the kubelet config file.

Question 17

A Pod must be prevented from reading or writing to its container root filesystem. The application only writes to an emptyDir mount at /tmp. Which securityContext field should be set in the Pod specification to enforce this at the container level?

Accepted Answer

readOnlyRootFilesystem: true. The readOnlyRootFilesystem field in the container securityContext mounts the root filesystem as read-only, directly preventing writes. Other securityContext fields such as privileged, allowPrivilegeEscalation, and runAsNonRoot improve container isolation but do not restrict filesystem writability. Mounting a writable emptyDir at /tmp allows the application to continue writing to the required path while the rest of the root filesystem remains immutable.

Answer

runAsNonRoot: true

Answer

privileged: false

Answer

allowPrivilegeEscalation: false

Question 18

A Kubernetes cluster uses containerd as the container runtime. The security team wants to restrict a specific container so it cannot create raw network packets. The container image runs as root and the Pod specification does not drop any capabilities. Which Linux capability should be dropped from the container's securityContext to prevent raw packet creation while still allowing binding to privileged ports?

Accepted Answer

NET_RAW. The NET_RAW capability is what allows a process to create raw sockets and craft raw network packets. Dropping NET_RAW from the container's securityContext removes this ability while preserving NET_BIND_SERVICE so the container can still bind to privileged ports. This is the least-privilege approach: it targets exactly the unwanted capability without removing unrelated networking permissions.

Answer

NET_BIND_SERVICE

Answer

SYS_ADMIN

Answer

NET_ADMIN

Question 19

A platform team runs a multi-tenant cluster and wants to enforce that all newly created Pods in the 'payments' namespace must run as non-root and must drop all Linux capabilities. The team decides to use a Pod Security Admission (PSA) label on the namespace. Which label value should they apply to the namespace to enforce these restrictions while still allowing other namespaces to remain unrestricted?

Accepted Answer

pod-security.kubernetes.io/enforce: restricted. Pod Security Admission enforces one of three levels: privileged, baseline, or restricted. The restricted level is the only one that requires non-root execution and dropping all capabilities. Setting the enforce label to restricted on the payments namespace blocks non-compliant Pods there while leaving other namespaces without the label unrestricted, which satisfies the multi-tenant requirement.

Answer

pod-security.kubernetes.io/enforce: baseline

Answer

pod-security.kubernetes.io/audit: restricted

Answer

pod-security.kubernetes.io/enforce: privileged

Question 20

A security engineer needs to verify that a container image stored in a private OCI registry has not been tampered with before allowing it to run in a production cluster. The image was signed using Cosign with a key pair. The engineer has the public key. Which command should the engineer use to verify the signature?

Accepted Answer

cosign verify --key cosign.pub registry.example.com/app:1.0. To verify a Cosign signature on a container image, the cosign verify command is used with the public key and the image reference. This checks the signature against the image digest. The other options either use the wrong subcommand, an invalid flag, or an unnecessary insecure flag that does not contribute to signature verification.

Answer

cosign verify --key cosign.pub --registry-token $(cat token) registry.example.com/app:1.0

Answer

cosign verify --key cosign.pub --insecure registry.example.com/app:1.0

Answer

cosign verify-blob --key cosign.pub registry.example.com/app:1.0