CKS Practice Test 39 — 15 Questions

Question 1

What is the default seccomp profile applied when a pod's security context has 'seccompProfile.type: RuntimeDefault'?

Accepted Answer

The container runtime's default seccomp profile, which blocks around 40 syscalls. When `seccompProfile.type: RuntimeDefault` is set in a pod's security context, the container runtime (e.g., containerd or CRI-O) applies its own default seccomp profile. This runtime default profile is a curated allowlist that blocks approximately 40 syscalls known to be dangerous or unnecessary for containers, providing a balance between security and compatibility. It is not the Docker default (which blocks ~300 syscalls) but a more permissive profile tailored to the runtime's container model.

Answer

The profile defined in /var/lib/kubelet/seccomp/default.json

Answer

Unconfined (no seccomp)

Answer

The Docker default profile, which blocks around 300 syscalls

Question 2

A cluster uses PodSecurity admission. A namespace has the label 'pod-security.kubernetes.io/enforce: baseline'. A user creates a pod that runs a container with 'privileged: true'. What happens?

Accepted Answer

The pod is rejected by the admission controller.. The PodSecurity admission controller enforces the configured security level based on the namespace label. The 'baseline' level prohibits privileged containers, so a pod with 'privileged: true' violates the policy. The admission controller rejects the pod immediately, preventing its creation.

Answer

The pod is created but flagged with a warning.

Answer

The pod is created successfully because privileged is allowed at baseline.

Answer

The pod is created but the privileged setting is ignored.

Question 3

A cluster administrator has configured EncryptionConfiguration to encrypt secrets at rest using a local key. After applying the configuration, the administrator creates a new secret. How can they verify that the secret is encrypted at rest?

Accepted Answer

Use etcdctl to read the secret directly from etcd and verify it is encrypted.. Encryption at rest is applied at the etcd storage layer, not at the Kubernetes API level. To verify that a secret is actually encrypted when stored, you must read it directly from etcd using etcdctl (with the appropriate endpoint and certificate flags). If the encryption configuration is working, the secret data will appear as base64-encoded ciphertext (e.g., starting with 'k8s:enc:aescbc:...') rather than plaintext base64 of the original secret data.

Answer

Run kubectl get secret -o yaml and check for an encryption annotation.

Answer

Use kubectl describe secret and look for 'Encrypted: true'.

Answer

Check the apiserver logs for encryption status messages.

Question 4

A cluster is using kubeadm and the control plane components are running as static pods. Where are the static pod manifests for the API server located by default?

Accepted Answer

/etc/kubernetes/manifests/. In a kubeadm-deployed cluster, the control plane components (API server, controller manager, scheduler) run as static pods. The kubelet watches a specific directory for pod manifests to create these static pods. By default, kubeadm places the manifests for the API server (and other control plane components) in /etc/kubernetes/manifests/. This directory is specified via the --pod-manifest-path or staticPodPath in the kubelet configuration.

Answer

/var/lib/kubelet/

Answer

/etc/kubernetes/admin.conf

Answer

/etc/kubernetes/

Question 5

Which kubectl command creates a validating webhook configuration that calls an external HTTPS endpoint for pod validation?

Accepted Answer

kubectl apply -f webhook.yaml. `kubectl apply -f webhook.yaml` is the standard way to create any Kubernetes resource, including a ValidatingWebhookConfiguration, from a YAML manifest. The manifest defines the webhook's client configuration, including the external HTTPS endpoint, CA bundle, and rules for pod validation. There is no dedicated `kubectl create` subcommand for webhooks; the resource must be defined declaratively in a YAML file.

Answer

kubectl create admission webhook --validate

Answer

kubectl run webhook --image=...

Answer

kubectl create validatingwebhookconfiguration --url=https://...

Question 6

Which TWO of the following are valid methods to restrict etcd access? (Choose two.)

Accepted Answer

Use TLS client certificates for authentication. Etcd supports mutual TLS (mTLS) authentication, where the client (e.g., kube-apiserver) presents a client certificate signed by the etcd CA. This ensures that only authenticated clients can communicate with etcd, effectively restricting access. Option C is correct because etcd has its own Role-Based Access Control (RBAC) system, which can be enabled to restrict read/write operations to specific users or roles, providing fine-grained access control.

Answer

Use firewall rules to restrict access to etcd port 2379

Answer

Use etcd's built-in password authentication

Answer

Set the --etcd-certfile flag on kube-apiserver

Question 7

Which flag should be set on the kube-apiserver to disable anonymous authentication?

Accepted Answer

--anonymous-auth=false. The `--anonymous-auth=false` flag explicitly disables anonymous authentication on the kube-apiserver. By default, anonymous requests are allowed (with a system:anonymous user), so setting this flag to false prevents unauthenticated users from accessing the API server. This is a key hardening measure to ensure only authenticated clients can interact with the cluster.

Answer

--enable-anonymous=false

Answer

--anonymous-enabled=false

Answer

--authentication-mode=Anonymous

Question 8

A pod is in a CrashLoopBackOff state. You run 'kubectl logs pod-name' and see: 'Error: failed to start container: exec: "/app": stat /app: no such file or directory'. What is the most likely cause?

Accepted Answer

The container image is missing the /app executable. The error message 'exec: "/app": stat /app: no such file or directory' indicates that the container runtime (e.g., containerd) cannot find the executable specified in the container's ENTRYPOINT or CMD. This occurs when the container image does not include the /app binary or script at that path, causing the container to fail immediately on start and enter CrashLoopBackOff. Option D correctly identifies that the container image is missing the /app executable.

Answer

The pod is out of memory

Answer

The container's working directory is incorrect

Answer

The pod has a liveness probe that is failing

Question 9

Which of the following is a best practice when writing a Dockerfile for a containerized application?

Accepted Answer

Use a minimal base image such as distroless or alpine. Using a minimal base image like distroless or alpine reduces the attack surface by eliminating unnecessary packages, libraries, and utilities that could be exploited. This aligns with the principle of least privilege and minimizes the number of Common Vulnerabilities and Exposures (CVEs) in the container, which is critical for supply chain security in Kubernetes environments.

Answer

Run the application as the root user for file permissions

Answer

Hardcode credentials in the Dockerfile for convenience

Answer

Use the latest tag for the base image to get the newest features

Question 10

Which TWO of the following are secure practices for managing secrets in Kubernetes? (Select TWO.)

Accepted Answer

Use a CSI driver to mount secrets as volumes. The CSI (Container Storage Interface) driver for secrets allows secrets to be mounted as volumes without storing them in etcd or exposing them in environment variables. This approach leverages the CSI driver's ability to fetch secrets from external providers (e.g., HashiCorp Vault) on-demand, ensuring secrets are never persisted in Kubernetes objects and reducing the attack surface. It also supports rotation without pod restarts, as the volume content can be updated dynamically.

Answer

Store secrets as environment variables

Answer

Embed secrets in container images

Answer

Store secrets in a ConfigMap

Question 11

A team needs to set up a highly available Kubernetes control plane across three availability zones. What is the minimum number of etcd members required to achieve fault tolerance against one zone failure?

Accepted Answer

3. For a highly available Kubernetes control plane across three availability zones, the etcd cluster must tolerate the loss of one entire zone. With three etcd members, one per zone, the cluster requires a majority (2) to form quorum. If one zone fails, the remaining two members still constitute a majority, ensuring continued operation. This matches the minimum odd number greater than one that provides fault tolerance against a single failure.

Answer

5

Answer

1

Answer

7

Question 12

Which TWO practices improve supply chain security for container images? (Select two.)

Accepted Answer

Scanning images for CVEs before deployment. Scanning images for CVEs before deployment is a core supply chain security practice because it identifies known vulnerabilities in the base image and installed packages before the container enters production. Tools like Trivy, Grype, or Clair compare the image's package inventory against vulnerability databases (e.g., NVD, OSV), allowing teams to reject or patch images with critical flaws. This proactive measure prevents attackers from exploiting unpatched software in the runtime environment.

Answer

Storing secrets in the Dockerfile

Answer

Using the 'latest' tag for easy updates

Answer

Running containers as root

Question 13

Which TWO of the following are recommended actions to harden service account security in a Kubernetes cluster? (Select TWO)

Accepted Answer

Avoid granting cluster-admin ClusterRole to service accounts. Granting the cluster-admin ClusterRole to a service account provides unrestricted superuser access across the entire cluster, violating the principle of least privilege. The CKS exam emphasizes that service accounts should be bound only to the minimal RBAC permissions required for their function, and cluster-admin should never be used for routine workloads.

Answer

Delete all service accounts except the default one

Answer

Use a single service account for all workloads

Answer

Grant cluster-admin to all service accounts for simplicity

Question 14

Which THREE of the following are best practices for securing the software supply chain in a CI/CD pipeline?

Accepted Answer

Sign images with Cosign after building. Option A is correct because signing images with Cosign (part of the Sigstore project) after building produces a cryptographic signature that allows downstream consumers and admission controllers to verify image provenance and integrity, preventing tampered or unauthorized images from being deployed. Option B is correct because generating a Software Bill of Materials (SBOM) for each image provides a machine-readable inventory of components and dependencies, enabling rapid vulnerability triage and license/compliance auditing when new CVEs emerge. Option C is correct because scanning container images with Trivy detects known CVEs in OS packages and application dependencies before the image is promoted, catching vulnerabilities early in the CI/CD pipeline. Option D is incorrect because best practice favors minimal base images (e.g., distroless or Alpine) to reduce attack surface, not bloated images with unnecessary libraries. Option E is incorrect because storing secrets in a Dockerfile as build args embeds them in image layers and build history, exposing them to anyone who can pull the image; secrets should instead come from a vault or secret manager at runtime.

Answer

Use a non-minimal base image to ensure all libraries are available

Answer

Store secrets in the Dockerfile as build args

Question 15

A cluster uses a custom mutating admission webhook that adds a sidecar container to all pods. After an upgrade, the webhook crashes and pods cannot be created. What is the best way to prevent this scenario in future?

Accepted Answer

Set the webhook's failurePolicy to Ignore. Setting the webhook's failurePolicy to Ignore ensures that if the webhook fails (e.g., crashes or times out), the API server will bypass the webhook and allow the pod creation to proceed. This prevents a single point of failure from blocking all pod creation, which is critical for cluster availability. The default failurePolicy is Fail, which would cause the entire admission request to fail if the webhook is unreachable.

Answer

Run multiple replicas of the webhook

Answer

Disable admission webhooks in the cluster

Answer

Create a validating webhook as a backup