CKS Practice Test 47 — 15 Questions

Question 1

An audit policy is configured with the following rule:
- level: Metadata
  resources:
  - group: ""
    resources: ["secrets"]
What does this rule log for requests to the Secrets API?

Accepted Answer

Metadata about the request, excluding the body. The Metadata audit level logs request metadata — such as the user, timestamp, verb, resource, and namespace — but deliberately excludes the request and response bodies. This is precisely why Metadata is commonly applied to Secrets: it records who accessed which secret and when, without writing the secret contents into audit logs. The rule shown therefore produces metadata-only entries for Secrets API requests.

Answer

The full request and response body

Answer

Nothing, because secrets are excluded by default

Answer

The request body only

Question 2

You run 'kubectl auth can-i create pods --as=system:serviceaccount:default:sa1 -n default' and get 'no'. What does this mean?

Accepted Answer

The service account 'sa1' does not have permission to create pods in the default namespace. The command 'kubectl auth can-i create pods --as=system:serviceaccount:default:sa1 -n default' impersonates the service account 'sa1' to check if it has RBAC permissions to create pods in the 'default' namespace. A response of 'no' means that the current RBAC bindings (Role/ClusterRole and RoleBinding/ClusterRoleBinding) do not grant the 'create' verb on 'pods' resources to that service account. This is a direct authorization check against the Kubernetes RBAC system, not an indication of the service account's existence or general capability.

Answer

The command is invalid because 'system:serviceaccount' is not a valid user

Answer

The service account 'sa1' does not exist

Answer

The service account 'sa1' is not allowed to perform any actions

Question 3

An administrator wants to use OPA Gatekeeper to enforce that all pods have a resource limits section defined. Which of the following is the correct combination to implement this policy?

Accepted Answer

Create a ConstraintTemplate with a Rego policy that checks for 'spec.containers[*].resources.limits', then create a Constraint targeting pods.. OPA Gatekeeper enforces policies via two Kubernetes custom resources: a ConstraintTemplate that contains the Rego policy logic (here, checking that every container has spec.containers[*].resources.limits), and a Constraint that instantiates the template and scopes it to specific resources (e.g., Pods). Together they register a ValidatingWebhookConfiguration behind the scenes to reject noncompliant pods.

Answer

Create a NetworkPolicy to block pods without limits.

Answer

Create a MutatingWebhookConfiguration to add resource limits automatically.

Answer

Create a ValidatingWebhookConfiguration that calls an external service to validate pod limits.

Question 4

You need to detect when a container attempts to mount the host's Docker socket. Which Falco macro or condition would you use?

Accepted Answer

fd.name=/var/run/docker.sock. Falco rules reference file descriptors by their path in the fd.name field. The Docker daemon socket on a host is at /var/run/docker.sock, so a condition checking fd.name=/var/run/docker.sock detects a container opening that socket. This is the canonical path used in Falco rules for Docker socket access detection.

Answer

fd.name=/var/run/containerd.sock

Answer

fd.name=/var/run/docker

Answer

fd.name=/run/docker.sock

Question 5

An administrator wants to enable Kubernetes audit logging with the following requirements: log all requests at the Metadata level, but log all responses at the Request level. Which audit policy configuration achieves this?

Accepted Answer

Use separate rules with 'stages: ["RequestReceived"]' level Metadata, and 'stages: ["ResponseComplete"]' level Request. Audit policies allow setting different levels for different stages. To meet the requirement of logging requests at Metadata level and responses at Request level, you need separate rules for each stage. Option D does this by using two rules: one with stages: ['RequestReceived'] and level: Metadata, and another with stages: ['ResponseComplete'] and level: Request. This ensures that request events are logged at Metadata level and response events at Request level.

Answer

Set default level to Metadata and use a dynamic level based on request size

Answer

Use the --audit-log-maxbackup flag to adjust levels

Answer

Set default level to Metadata and use a rule with level: Request for specific resources

Question 6

A security team wants to detect any attempt to spawn an interactive shell inside a container. Which Falco rule condition would be appropriate?

Accepted Answer

container.id != host and evt.type = execve and proc.name = bash. Falco uses syscall events. The condition container.id != host and evt.type = execve and proc.name = bash detects a bash exec in a container, which is a common interactive shell.

Answer

container.id != host and evt.type = read and fd.name = /etc/shadow

Answer

evt.type = connect and container.id != host

Answer

proc.name = bash and evt.type = execve

Question 7

Which audit policy level logs all requests and responses, including the request body and response body?

Accepted Answer

RequestResponse. RequestResponse logs both the request object and the response object, including bodies. Request logs only the request object. Metadata logs only metadata. None logs nothing.

Answer

None

Answer

Request

Answer

Metadata

Question 8

What is the purpose of using a non-root user in a container image?

Accepted Answer

To reduce the attack surface and limit potential damage if the container is compromised. Running containers as a non-root user reduces the attack surface by ensuring that even if an attacker exploits a vulnerability in the application, they do not gain root privileges inside the container. This limits the potential damage, such as modifying system binaries, escaping the container via kernel exploits, or accessing host resources. In Kubernetes, this is enforced by setting `securityContext.runAsNonRoot: true` or specifying a non-root user in the Dockerfile with `USER` directive.

Answer

To improve performance

Answer

To comply with Kubernetes requirements

Answer

To allow the container to bind to privileged ports

Question 9

In Kubernetes, you need to enforce a default deny-all network policy for pods in a specific namespace to ensure pods cannot communicate unless explicitly allowed by policy. Which resource should you create?

Accepted Answer

NetworkPolicy. A NetworkPolicy is the Kubernetes resource that controls network traffic to and from pods. A default deny-all policy can be created by selecting all pods (e.g., using an empty podSelector) and omitting ingress/egress rules. ResourceQuota and LimitRange manage compute/resource usage, not network traffic, and RuntimeClass selects a container runtime configuration rather than enforcing network policy.

Answer

ResourceQuota

Answer

LimitRange

Answer

RuntimeClass

Question 10

You are tasked with reducing the attack surface on a Kubernetes node. Which of the following actions is LEAST effective for hardening the node itself?

Accepted Answer

Drop the NET_RAW capability from all containers running on the node. The least effective for hardening the node itself because dropping NET_RAW from containers is a container-level security control (e.g., via Pod Security Standards or seccomp), not a node-level hardening measure. Node hardening focuses on the host OS and Kubernetes components, not container capabilities. While it reduces attack surface for containers, it does not directly secure the node's kernel, services, or network access.

Answer

Restrict SSH access to the node using firewall rules

Answer

Disable unnecessary system services (e.g., telnet, rsh) on the node

Answer

Apply the latest security patches to the host kernel

Question 11

You deploy the Kubernetes Dashboard using the official YAML manifests. Which of the following is the MOST secure approach to expose the Dashboard?

Accepted Answer

Use 'kubectl proxy' to access it locally. The most secure approach is to use 'kubectl proxy' because it creates a local HTTP proxy between your workstation and the Kubernetes API server, authenticating your requests using your kubeconfig credentials. This ensures the Dashboard is never exposed to the network, eliminating any attack surface from external or internal cluster access. All traffic is tunneled through the API server, which enforces RBAC and audit logging.

Answer

Create a NodePort Service to expose it on a port

Answer

Expose it with a LoadBalancer Service

Answer

Use an Ingress with a public DNS

Question 12

Which admission plugin should be enabled on the kube-apiserver to restrict kubelet permissions and prevent nodes from modifying their own Node objects?

Accepted Answer

NodeRestriction. The NodeRestriction admission plugin limits the kubelet's permissions to only modify labels, annotations, and status on its own Node object, preventing a compromised or misconfigured node from altering other Node objects or escalating privileges. This is a critical hardening measure for cluster setup, as it enforces the principle of least privilege on kubelet API access.

Answer

ServiceAccount

Answer

AlwaysPullImages

Answer

PodSecurityPolicy

Question 13

A security auditor requires that all container images used in the cluster are scanned for vulnerabilities before deployment. The team uses a private registry with image signing. Which solution enforces that only signed and scanned images are deployed?

Accepted Answer

Use Cosign to sign images and deploy a webhook that verifies signatures.. Cosign is a tool for signing container images, and deploying a validating webhook (e.g., the cosigned admission controller) enforces that only images with valid signatures are admitted. This directly meets the requirement to deploy only signed and scanned images, as the webhook verifies the signature before the pod is created.

Answer

Run Trivy in a CronJob to scan images and update a ConfigMap with allowed images.

Answer

Use OPA Gatekeeper to verify that the image comes from the private registry.

Answer

Enable Binary Authorization on the cluster to enforce image attestation.

Question 14

Which flag on the kubelet helps ensure it runs securely by enforcing kernel defaults?

Accepted Answer

--protect-kernel-defaults. The `--protect-kernel-defaults` flag on the kubelet ensures that the node's kernel parameters are set to secure defaults, preventing container escapes or privilege escalations that could exploit weak kernel settings. This flag enforces the kubelet's built-in kernel validator, which checks that critical sysctls (e.g., `net.ipv4.ip_forward`, `kernel.panic`) are set to safe values, and fails to start if they are not. It is a key hardening measure for cluster nodes, directly addressing kernel-level security.

Answer

--read-only-port=0

Answer

--security-context

Answer

--kernel-security

Question 15

A pod is stuck in Pending state. You run 'kubectl describe pod' and see the event: '0/3 nodes are available: 3 Insufficient cpu'. What is the likely cause?

Accepted Answer

The pod's CPU request exceeds the available CPU capacity on all nodes. The event '0/3 nodes are available: 3 Insufficient cpu' directly indicates that the scheduler attempted to place the pod on each of the three nodes but found that none had enough allocatable CPU to satisfy the pod's CPU request. This means the sum of CPU requests across all pods on each node, plus the new pod's request, exceeds the node's capacity. The pod remains in Pending state because no node can accommodate its resource requirements.

Answer

The pod's image pull policy is set to Always and the registry is unreachable

Answer

The cluster has a taint that the pod does not tolerate

Answer

The scheduler is misconfigured and not running