CKS Practice Test 31 — 15 Questions

Question 1

Match each Kubernetes command to its function related to security.

Accepted Answer

kubectl auth can-i: Check if a user can perform a specific action. The correct matches are: 'kubectl auth can-i' checks permissions, 'kubectl certificate approve' handles CSRs, 'kubectl describe clusterrole' shows role details, and 'kubectl create serviceaccount' creates service accounts. Common confusions include mixing the functions of permission checking and resource creation.

Answer

kubectl auth can-i: Create a new service account

Answer

kubectl certificate approve: Display details of a ClusterRole

Question 2

Which of the following is NOT a valid priority level in a Falco rule?

Accepted Answer

HIGH. Falco rules support priority levels as defined in the syslog severity standard. The valid priorities are: EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFORMATIONAL, and DEBUG. 'HIGH' is not a valid priority in Falco; the correct equivalent is 'ERROR' or 'CRITICAL' depending on severity. Therefore, option B is not a valid priority level.

Answer

NOTICE

Answer

CRITICAL

Answer

WARNING

Question 3

Which THREE flags should be set on the kubelet to comply with the CIS Benchmark for worker node security?

Accepted Answer

--anonymous-auth=false. The CIS Benchmark for Kubernetes requires disabling anonymous authentication on the kubelet by setting `--anonymous-auth=false`. This ensures that all requests to the kubelet are authenticated, preventing unauthenticated access to the kubelet API, which could allow an attacker to execute commands or retrieve sensitive node information.

Answer

--authentication-token-webhook=false

Answer

--read-only-port=10255

Question 4

You need to configure Kubernetes audit logging to log all requests at the Metadata level for a specific namespace. Which audit policy level should you use?

Accepted Answer

Metadata. The Metadata audit level logs request metadata (who, when, what resource, verb, etc.) but not the request or response body. This is exactly what is needed to log all requests at the Metadata level for a specific namespace. The other levels either log too much (Request, RequestResponse) or nothing (None).

Answer

Request

Answer

None

Answer

RequestResponse

Question 5

Which TWO of the following are best practices for securing container images?

Accepted Answer

Use minimal base images like distroless. Minimal base images like distroless reduce the attack surface by eliminating unnecessary packages, libraries, and shell access. This aligns with the principle of least functionality, making it harder for attackers to exploit vulnerabilities or execute arbitrary commands within the container. Distroless images typically contain only the application and its runtime dependencies, significantly lowering the risk of privilege escalation or lateral movement.

Answer

Always use the latest tag

Answer

Run containers as root

Answer

Run containers in privileged mode

Question 6

Which THREE of the following are valid methods to enforce pod security standards in a Kubernetes cluster?

Accepted Answer

Use Kyverno policy engine. Kyverno is a Kubernetes-native policy engine that can enforce pod security standards by validating, mutating, and generating resources based on policies written as Kubernetes custom resources. It integrates with the Kubernetes API server via dynamic admission webhooks, allowing it to reject non-compliant pod specs before they are persisted.

Answer

Run kube-bench on the cluster

Answer

Manual review of all pod specs

Question 7

To ensure a container's filesystem is read-only, which field should be set to 'true' in the container spec?

Accepted Answer

securityContext.readOnlyRootFilesystem. The `securityContext.readOnlyRootFilesystem` field, when set to `true`, mounts the container's root filesystem as read-only. This prevents any writes to the container's filesystem, enhancing security by making it immutable. It is the correct field to ensure a read-only filesystem.

Answer

securityContext.runAsNonRoot

Answer

container.fsGroup

Answer

podSpec.containers.readonly

Question 8

Which TWO of the following are valid audit policy levels in Kubernetes? (Choose two.)

Accepted Answer

RequestResponse. In Kubernetes audit policy, the valid audit levels are None, Metadata, Request, and RequestResponse, so option A (RequestResponse) is correct because it logs the request metadata and body plus the response metadata and body, providing the most complete audit record. Option E (Metadata) is also correct because it logs only the request metadata (such as the user, timestamp, resource, and verb) without request or response bodies, which is one of the officially supported audit levels. The unmarked options do not belong: Verbose is not a Kubernetes audit level, Response is not a standalone audit level (response logging is part of RequestResponse), and All is not a valid audit policy level in Kubernetes.

Answer

Verbose

Answer

Response

Answer

All

Question 9

Match each Kubernetes admission controller to its role in security.

Accepted Answer

NodeRestriction: Limits the permissions of kubelet nodes to prevent unauthorized operations.. Admission controllers intercept requests to the API server and can enforce security policies.

Answer

NodeRestriction: Controls automounting of service account tokens to pods.

Answer

PodSecurity: Limits the permissions of kubelet nodes.

Question 10

What is the effect of setting 'hostPID: true' in a pod's spec?

Accepted Answer

The container runs in the host's PID namespace.. Setting 'hostPID: true' in a pod's spec allows the container to share the host node's PID namespace, meaning the container can see and interact with all processes running on the host, not just those within its own PID namespace. This is a privileged-level setting that bypasses the default process isolation provided by Kubernetes and Linux namespaces.

Answer

The container runs with the host's IPC namespace.

Answer

The container can access the host's network interfaces.

Answer

The container can mount the host's filesystem.

Question 11

To enforce Pod Security Standards at the namespace level, which admission plugin must be enabled on the API server?

Accepted Answer

PodSecurity. Pod Security Standards (PSS) are enforced at the namespace level using the PodSecurity admission plugin, which was introduced in Kubernetes v1.23 and graduated to stable in v1.25. This plugin evaluates pods against the predefined security levels (privileged, baseline, restricted) based on labels on the namespace, replacing the deprecated PodSecurityPolicy.

Answer

SecurityContextDeny

Answer

NodeRestriction

Answer

PodSecurityPolicy

Question 12

Match each etcd security configuration to its description.

Accepted Answer

Client certificate authentication: Requires clients to present a valid certificate signed by a trusted CA.. In this matching exercise, each etcd security configuration should be paired with its correct description. Common confusions arise between client-to-server TLS and peer-to-peer TLS due to similar wording. Client-to-server TLS secures communication between clients and the cluster, while peer-to-peer TLS secures inter-member communication. Client certificate authentication and RBAC are distinct security features.

Answer

Client-to-server TLS: Encrypts communication between etcd members.

Answer

Peer-to-peer TLS: Encrypts communication between etcd clients and the cluster.

Question 13

Match each Kubernetes security component to its description.

Accepted Answer

RBAC: Role-based access control for managing permissions.. RBAC controls permissions, Pod Security Admission enforces pod security, Network Policies manage traffic, and ServiceAccounts provide identity. Distractors confuse these functions.

Answer

RBAC: Encrypts data at rest.

Answer

ServiceAccount: Manages network rules.

Question 14

A security policy requires that all ServiceAccounts in a namespace do not automatically mount their tokens. How can this be achieved at the namespace level?

Accepted Answer

Set automountServiceAccountToken: false in the ServiceAccount definition. Setting `automountServiceAccountToken: false` in the ServiceAccount definition applies the setting to all pods that use that ServiceAccount, effectively enforcing the policy at the namespace level when the default or all ServiceAccounts are configured this way. This is the correct approach because the ServiceAccount's `automountServiceAccountToken` field controls token mounting for pods referencing it, overriding any pod-level setting unless explicitly set in the pod spec.

Answer

Set automountServiceAccountToken: false in each pod spec

Answer

Use a PodSecurityPolicy to deny token mounting

Answer

Delete the default ServiceAccount

Question 15

A developer wants to verify the signature of a container image before deploying it. Which command should they use along with Cosign?

Accepted Answer

cosign verify. The `cosign verify` command is used to check the cryptographic signature of a container image against a public key, ensuring the image's integrity and authenticity. This is the correct tool for a developer who needs to confirm that the image has not been tampered with and was signed by a trusted entity before deployment.

Answer

cosign generate-key-pair

Answer

cosign sign

Answer

cosign attest