CKS Practice Test 38 — 15 Questions

Question 1

You need to ensure that all pods in a namespace can only communicate via mTLS. In Istio, which resource should you apply?

Accepted Answer

PeerAuthentication with mode: STRICT. PeerAuthentication with mode: STRICT is the correct resource to enforce mTLS for all pods in a namespace. It configures the Istio sidecar proxy to require mutual TLS for all inbound and outbound traffic within the mesh, rejecting any plaintext connections. This ensures that all inter-pod communication is encrypted and authenticated using X.509 certificates, aligning with the goal of minimizing microservice vulnerabilities.

Answer

DestinationRule with tls: ISTIO_MUTUAL

Answer

PeerAuthentication with mode: DISABLE

Answer

PeerAuthentication with mode: PERMISSIVE

Question 2

A DevOps engineer wants to enforce that all container images running in the cluster are signed using Cosign. Which Kubernetes admission controller is designed for this purpose?

Accepted Answer

ImagePolicyWebhook. The ImagePolicyWebhook admission controller is specifically designed to enforce that container images meet certain criteria, such as being signed with Cosign, by querying an external webhook service that validates image signatures before admitting a pod. It intercepts pod creation requests and checks the image references against a configured policy, making it the correct choice for this Cosign-based image signing enforcement scenario.

Answer

MutatingAdmissionWebhook

Answer

PodSecurityPolicy (deprecated)

Answer

ValidatingAdmissionWebhook

Question 3

What is the default seccomp profile for Kubernetes containers when no seccompProfile is specified?

Accepted Answer

RuntimeDefault. When no `seccompProfile` is specified in the Pod or container security context, Kubernetes applies the `RuntimeDefault` seccomp profile by default. This profile is defined by the container runtime (e.g., containerd or CRI-O) and blocks a specific set of syscalls that are considered dangerous or unnecessary for containers, while allowing normal application operations. This default behavior was introduced in Kubernetes 1.19 and became the default for all pods in Kubernetes 1.22, enhancing security without requiring explicit configuration.

Answer

Localhost

Answer

No profile is applied

Answer

Unconfined

Question 4

Which command can be used to view the current set of admission webhooks in the cluster?

Accepted Answer

kubectl get validatingwebhookconfigurations. Admission webhooks in Kubernetes are configured via `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` resources. The command `kubectl get validatingwebhookconfigurations` retrieves all validating admission webhooks currently registered in the cluster, which is the standard way to list them.

Answer

kubectl get webhooks

Answer

kubectl get webhookconfigurations

Answer

kubectl get admissionwebhooks

Question 5

A cluster has enabled the NodeRestriction admission controller. A developer is trying to create a pod with hostNetwork: true but is getting an error. What is the most likely reason?

Accepted Answer

The error is unrelated to NodeRestriction; the issue is likely a missing PodSecurityPolicy or Pod Security Admission that denies hostNetwork. The NodeRestriction admission controller only limits node self-updates to kubelet nodes, preventing them from modifying their own labels, taints, or other node objects. It does not block pods with `hostNetwork: true`. The error is most likely caused by a missing PodSecurityPolicy or Pod Security Admission (PSA) that denies pods with `hostNetwork: true`, as these are the mechanisms that enforce host namespace restrictions.

Answer

The NodeRestriction admission controller blocks pods with hostNetwork

Answer

The nodeSelector on the pod conflicts with NodeRestriction

Answer

The developer lacks RBAC permissions to create pods

Question 6

Which THREE of the following are recommended practices for securing Kubernetes Dashboard?

Accepted Answer

Disable anonymous access to Dashboard. The Kubernetes Dashboard, by default, may allow unauthenticated access if not explicitly configured. Disabling anonymous access ensures that all requests to the Dashboard are authenticated, preventing unauthorized users from viewing or manipulating cluster resources. This is typically done by setting the `--enable-skip-login` flag to false or configuring the Dashboard deployment to require authentication tokens.

Answer

Expose Dashboard via NodePort service on all nodes

Answer

Create a ClusterRole with full cluster admin access for Dashboard

Question 7

A cluster administrator wants to ensure that pods cannot modify node objects. Which admission plugin should be enabled?

Accepted Answer

NodeRestriction. The NodeRestriction admission plugin limits the kubelet's ability to modify node and pod objects to only those nodes it is authorized to manage. This prevents a compromised or misconfigured kubelet from modifying arbitrary node objects, enforcing the principle of least privilege. Option D is correct because it directly addresses the requirement to restrict node object modifications.

Answer

PodSecurityPolicy

Answer

NodeAffinity

Answer

PodNodeSelector

Question 8

An administrator wants to ensure that containers in a pod cannot run with any Linux capabilities except the minimal required for the container runtime. The pod is subject to the 'restricted' Pod Security Standard. Which capability configuration should be set in the pod's security context?

Accepted Answer

capabilities:
  drop: ["ALL"]. The 'restricted' Pod Security Standard (PSS) requires that all Linux capabilities be dropped except those essential for the container runtime (e.g., CAP_NET_BIND_SERVICE is allowed by default in some runtimes, but the standard explicitly mandates dropping all capabilities). Option A correctly uses `drop: ["ALL"]` to remove every capability, ensuring the container runs with the minimal set required by the runtime, which aligns with the PSS 'restricted' profile. This approach enforces the principle of least privilege by preventing the container from gaining any unnecessary kernel privileges.

Answer

capabilities:
  drop: ["NET_RAW", "CHOWN"]

Answer

capabilities:
  add: ["NET_BIND_SERVICE"]

Answer

capabilities:
  add: ["ALL"]

Question 9

A security scanner reports that a microservice container image contains a critical vulnerability (CVE-2024-1234) in a system library. The team cannot immediately rebuild the image. What is the most effective temporary mitigation at the Kubernetes level?

Accepted Answer

Apply a custom seccomp profile that blocks the vulnerable syscall. A custom seccomp (secure computing mode) profile can restrict the system calls (syscalls) a container is allowed to make. By blocking the specific vulnerable syscall exploited by CVE-2024-1234, you can prevent the vulnerability from being triggered at runtime without rebuilding the image. This is a temporary, Kubernetes-native mitigation that directly addresses the attack vector at the syscall level.

Answer

Apply a NetworkPolicy to block egress traffic from the Pod

Answer

Apply an AppArmor profile to the Pod

Answer

Use a PodSecurityPolicy to drop all capabilities

Question 10

To disable service account token automount for a pod, which field should be set to false in the pod spec?

Accepted Answer

automountServiceAccountToken. In Kubernetes, the `automountServiceAccountToken` field in the Pod spec, when set to `false`, prevents the automatic mounting of the service account token (a JWT) into the pod's containers. This is a security hardening measure to reduce the attack surface, as the token could be used to authenticate to the Kubernetes API server if compromised. The default behavior is `true`, meaning the token is automatically mounted unless explicitly disabled.

Answer

serviceAccountToken

Answer

automountToken

Answer

enableServiceAccountToken

Question 11

A cluster has been hardened by setting --anonymous-auth=false and enabling RBAC. However, kube-bench still reports a failure for the kubelet check 'Ensure that the --anonymous-auth argument is set to false'. What could be the reason?

Accepted Answer

The kubelet configuration file does not set --anonymous-auth=false. The kubelet can have its authentication settings configured either via command-line arguments or via a KubeletConfiguration file. If the kubelet configuration file does not explicitly set `authentication.anonymous.enabled` to `false`, the kubelet may still allow anonymous access even if the `--anonymous-auth=false` argument is passed on the command line, because the configuration file takes precedence over command-line flags. kube-bench checks the effective configuration, so if the file overrides the flag, the check fails.

Answer

The API server is running with --authorization-mode=AlwaysAllow

Answer

The kubelet is using a self-signed certificate

Answer

The NodeRestriction admission plugin is not enabled

Question 12

Which TWO of the following are tools for image signing and verification? (Select TWO)

Accepted Answer

Cosign. Cosign is correct because it is a tool specifically designed for container image signing and verification, leveraging Sigstore's keyless signing capabilities and integration with OCI registries. It enables developers to sign images using ephemeral keys and verify signatures against transparency logs, ensuring supply chain integrity.

Answer

Trivy

Answer

kubesec

Answer

Syft

Question 13

A DevOps engineer wants to ensure that a container image is signed and the signature is verified before deployment. Which Cosign command verifies an image signature?

Accepted Answer

cosign verify. The `cosign verify` command is used to check the signature of a container image against the public key that was used to sign it. This ensures the image's integrity and authenticity before deployment, which is a core requirement of the CKS Supply Chain Security domain.

Answer

cosign sign

Answer

cosign check

Answer

cosign attest

Question 14

A security audit reveals that the etcd datastore is not encrypted at rest. Which resource should be created to enable encryption of secrets at rest?

Accepted Answer

EncryptionConfiguration. To enable encryption of secrets at rest in Kubernetes, you must create an EncryptionConfiguration resource. This resource defines which encryption providers (e.g., AES-CBC, secretbox) to use and how to encrypt resources stored in etcd. The kube-apiserver reads this configuration via the --encryption-provider-config flag and applies it to all resources in the specified resource group, such as secrets.

Answer

EtcdEncryption

Answer

EncryptionConfig

Answer

SecretEncryption

Question 15

A security engineer wants to enable mutual TLS (mTLS) between services in an Istio service mesh. Which Istio resource should be used to define the mTLS mode for the entire mesh?

Accepted Answer

PeerAuthentication with mTLS mode set to STRICT. PeerAuthentication is the Istio resource specifically designed to define the authentication policy for workloads, including the mTLS mode. Setting `mTLS.mode: STRICT` in a PeerAuthentication policy enforces mutual TLS for all traffic within the mesh, ensuring that every service-to-service connection requires a valid client certificate. This is the correct resource for mesh-wide mTLS enforcement, as it operates at the authentication layer rather than the traffic routing layer.

Answer

DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

Answer

VirtualService with tls configuration

Answer

ServiceEntry with mTLS enabled