CKS Multiple Select — 50 Questions

Question 1

Which THREE of the following are features of container sandboxing solutions like gVisor or Kata Containers?

Accepted Answer

They are compatible with the OCI runtime specification. Both gVisor and Kata Containers implement the OCI (Open Container Initiative) runtime specification, which allows them to be used as drop-in replacements for runc. This compatibility ensures that container images and tools like containerd can interface with these sandboxed runtimes without modification, as they expose the same runtime lifecycle commands (create, start, delete).

Answer

They improve container performance over native runc

Answer

They use the host kernel directly for all system calls

Question 2

Which TWO of the following are valid ways to securely manage secrets in Kubernetes? (Choose two.)

Accepted Answer

Mount Kubernetes Secrets as volumes into the pod.. Mounting Kubernetes Secrets as volumes into the pod ensures that secret data is stored in the pod's filesystem as files, which are created with in-memory tmpfs to avoid writing to disk. This approach leverages Kubernetes' native secret handling, where the secret data is base64-decoded and presented as plaintext files, and access can be controlled via RBAC and PodSecurityPolicies. It also supports automatic rotation when secrets are updated, provided the pod is restarted or the volume is remounted.

Answer

Use environment variables from the pod spec referencing Secret keys.

Answer

Pass secrets as command-line arguments to the container.

Answer

Store secrets in ConfigMaps with base64 encoded data.

Question 3

Which TWO container sandboxing technologies are supported in Kubernetes via RuntimeClass? (Choose two)

Accepted Answer

gVisor (runsc). gVisor (runsc) is a container sandboxing technology that provides a user-space kernel for containers, isolating them from the host kernel. Kubernetes supports gVisor via RuntimeClass, allowing pods to be scheduled with the 'runsc' runtime for enhanced security.

Answer

Docker

Answer

containerd

Answer

runc

Question 4

Which TWO of the following are valid methods to securely manage secrets in Kubernetes?

Accepted Answer

Use Kubernetes Secrets with encryption at rest enabled. Kubernetes Secrets can be encrypted at rest using a KMS provider (e.g., AWS KMS, Azure Key Vault, or GCP Cloud KMS) configured via the EncryptionConfiguration resource. This ensures that Secret data is encrypted in etcd, protecting it from unauthorized access if the etcd database is compromised. Encryption at rest is a critical security control for secrets in Kubernetes.

Answer

Store secrets in ConfigMaps and use them in pods

Answer

Commit secrets to a private Git repository

Answer

Store secrets directly in the application code

Question 5

Which TWO of the following are valid ways to enforce that a container runs as a non-root user?

Accepted Answer

Set runAsNonRoot: true in the pod securityContext. Setting `runAsNonRoot: true` in the pod's `securityContext` explicitly instructs the kubelet to validate that the container's user ID is not 0 (root) before starting the container. If the container attempts to run as root, the kubelet will refuse to start it, providing a strong enforcement mechanism at the Kubernetes level.

Answer

Set the container image to use a root user

Answer

Use a PodSecurityPolicy (PSP)

Answer

Set runAsUser: 0 in the container securityContext

Question 6

Which TWO of the following are valid methods to verify the integrity of a container image? (Select 2)

Accepted Answer

Compare the image SHA digest with a known good digest. Container images are identified by a content-addressable digest (SHA256 hash) that uniquely represents the image manifest. Verifying that the SHA digest of a pulled image matches a known good digest from a trusted source ensures the image has not been tampered with or altered in transit, as any change to the image layers or configuration would result in a different digest.

Answer

Use trivy image to check for vulnerabilities

Answer

Use docker history to view layers

Answer

Use kubectl describe pod to check image details

Question 7

Which two of the following are correct ways to enforce least privilege for service accounts? (Choose two.)

Accepted Answer

Set automountServiceAccountToken: false in Pod spec for pods that do not need API access. Setting `automountServiceAccountToken: false` in the Pod spec prevents the automatic mounting of the service account token into the container. This enforces least privilege by ensuring that pods which do not require API access cannot inadvertently use the token to authenticate to the Kubernetes API server, reducing the attack surface.

Answer

Add multiple ClusterRoleBindings to a single service account to ensure it has access to all resources

Answer

Use the default service account for all workloads

Answer

Grant cluster-admin ClusterRole to the service account for simplicity

Question 8

Which THREE of the following are best practices for securing a Kubernetes cluster using OPA Gatekeeper? (Choose three.)

Accepted Answer

Enforce that containers set runAsNonRoot: true.. Enforcing `runAsNonRoot: true` via OPA Gatekeeper ensures that containers run with a non-root user ID, mitigating the risk of privilege escalation attacks. This aligns with the Kubernetes Pod Security Standards (PSS) 'restricted' profile and is a key control for minimizing microservice vulnerabilities.

Answer

Allow privileged containers for system-critical workloads.

Answer

Allow containers to use hostNetwork for easier service discovery.

Question 9

Which TWO resources can be used to implement RBAC in Kubernetes?

Accepted Answer

ClusterRole. A is correct because ClusterRole is a Kubernetes RBAC resource that defines a set of permissions (rules) that are not namespaced, allowing cluster-wide access. RBAC in Kubernetes uses Role and ClusterRole objects to specify allowed verbs (e.g., get, list, create) on resources (e.g., pods, secrets), and they are bound to subjects via RoleBinding or ClusterRoleBinding.

Answer

NetworkPolicy

Answer

PodSecurityPolicy

Answer

ServiceAccount

Question 10

Which TWO of the following are effective measures to harden the Kubernetes API server against unauthorized access?

Accepted Answer

Enable the NodeRestriction admission controller. The NodeRestriction admission controller limits the Node and Pod objects a kubelet can modify, preventing compromised nodes from accessing or modifying resources beyond their own. This is a key hardening measure because it enforces the principle of least privilege directly within the API server's admission chain, reducing the blast radius of a node compromise.

Answer

Set --anonymous-auth=true to allow all users

Answer

Enable audit logging to detect unauthorized attempts

Answer

Disable all authentication mechanisms and rely on network policies

Question 11

Which TWO are valid stages in a Kubernetes audit event? (Select 2)

Accepted Answer

RequestReceived. 'RequestReceived' is one of the defined stages in the Kubernetes audit event lifecycle. When an audit policy is configured, the kube-apiserver records an audit event at the 'RequestReceived' stage after it has received the request but before it has been processed by the admission controllers or the resource handler. This stage captures the raw request as it arrives.

Answer

PreProcessing

Answer

None

Answer

PostProcessing

Question 12

Which THREE of the following are correct statements about seccomp in Kubernetes? (Select 3)

Accepted Answer

Seccomp can be configured using the securityContext.seccompProfile field. The `securityContext.seccompProfile` field in a Pod or container spec allows you to configure seccomp profiles directly in the Kubernetes API. This field supports values like `RuntimeDefault`, `Localhost`, and `Unconfined`, enabling fine-grained control over system call filtering without requiring manual profile loading on the node.

Answer

Seccomp profiles can only be applied to privileged containers

Answer

Seccomp can only restrict system calls, not allow them

Question 13

Which TWO of the following are valid Pod Security Standard levels? (Select 2)

Accepted Answer

privileged. The Pod Security Standards (PSS) define three levels: privileged, baseline, and restricted. The privileged level is the most permissive, allowing known privilege escalations and is intended for system-level workloads that require unrestricted access to host resources. It is explicitly listed in the Kubernetes documentation as one of the three valid PSS levels.

Answer

medium

Answer

high

Answer

default

Question 14

Which THREE of the following are valid flags for enabling admission plugins on the API server?

Accepted Answer

--enable-admission-plugins=AlwaysPullImages. `--enable-admission-plugins=AlwaysPullImages` is the valid flag to enable the AlwaysPullImages admission plugin on the kube-apiserver. This flag accepts a comma-separated list of plugin names, and AlwaysPullImages is a built-in admission controller that forces every new Pod to pull images again, even if they already exist on the node, enhancing security by ensuring only authorized images are used.

Answer

--plugin-dir=/admission

Answer

--admission-control=NodeRestriction

Question 15

Which TWO of the following are recommendations from the CIS Kubernetes Benchmark?

Accepted Answer

Enable audit logging. The CIS Kubernetes Benchmark recommends enabling audit logging to record all API server requests, which is essential for security monitoring and forensic analysis. It also recommends disabling anonymous authentication to ensure that all requests are authenticated, preventing unauthenticated access to the cluster.

Answer

Use TokenReview API for authentication

Answer

Set --protect-kernel-defaults=false on kubelet

Answer

Enable the insecure port for kubelet

Question 16

Which THREE of the following are recommended measures to reduce the attack surface of Kubernetes nodes?

Accepted Answer

Disable unnecessary system services on nodes. Disabling unnecessary system services on Kubernetes nodes reduces the number of running processes and open ports that could be exploited by an attacker. Services like telnet, rsh, or unused SNMP daemons provide additional attack vectors. This aligns with the principle of minimalism in system hardening, as recommended by the CIS Kubernetes Benchmark.

Answer

Open all ports on nodes to allow easy debugging

Answer

Run all containers as root user

Question 17

Which THREE of the following are required to secure etcd in a Kubernetes cluster?

Accepted Answer

Require client certificate authentication. Etcd requires client certificate authentication to verify the identity of clients (such as kube-apiserver) connecting to it. Without mutual TLS (mTLS), an attacker could impersonate a legitimate client and read or modify cluster state, including secrets and configuration data.

Answer

Configure RBAC for etcd

Answer

Allow anonymous access for monitoring

Question 18

Which TWO of the following are valid arguments for the kubectl command to create a secret from a file? (Select TWO)

Accepted Answer

--from-file. Options D and E are correct because both --from-file and --from-env-file are valid arguments for the kubectl create secret command when creating a secret from a file. --from-file reads the entire file content and uses the filename as the key. --from-env-file reads a file containing key=value lines, which is suitable for environment variable-style secrets. Option B (--from-literal) is incorrect because it specifies key-value pairs directly on the command line, not from a file. Option A (--dry-run) is a flag, not an argument for specifying secret data. Option C (--from-yaml) is not a valid argument for kubectl create secret.

Answer

--dry-run

Answer

--from-literal

Answer

--from-yaml

Question 19

Which TWO AppArmor modes are available? (Select 2)

Accepted Answer

enforce. AppArmor provides exactly two operational modes for a profile: enforce (option A) and complain (option B). In enforce mode, the profile's rules are actively applied and any access that violates the policy is denied and logged, which is the default mode for loaded profiles. In complain mode, violations are not blocked but are instead logged as complaints, allowing administrators to test and refine a profile before enforcing it. The other options are not AppArmor modes: audit (C) is not a mode but rather a logging facility/flag, allow (D) is not an AppArmor mode (it resembles SELinux terminology or a policy rule action), and unconfined (E) describes a process with no profile attached, not a selectable profile mode.

Answer

audit

Answer

allow

Answer

unconfined

Question 20

You are asked to secure a set of microservices running in a Kubernetes cluster. Which TWO of the following practices help minimize vulnerabilities in microservices?

Accepted Answer

Ensure containers run with a non-root user.. Running containers with a non-root user (via the `securityContext.runAsNonRoot: true` field or a specific `runAsUser` directive) prevents privilege escalation and limits the blast radius of a container compromise. This aligns with the principle of least privilege, a core mitigation against container breakout attacks in Kubernetes.

Answer

Manually inject sidecar proxies into every pod to enforce mTLS.

Answer

Run containers in privileged mode to allow them to perform necessary system calls.

Answer

Store secrets directly in container images for easy access.