CKS Cluster Hardening Practice Test 1 — 15 Questions

Question 1

A security team wants to ensure that all pods in a namespace run with a restricted seccomp profile. Which Pod Security Standard admission controller mode should be used to enforce this without blocking necessary pods?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Enable the PodSecurity admission plugin with the 'restricted' policy and 'enforce' mode. The Pod Security Standards (PSS) define three policies: privileged, baseline, and restricted. The restricted policy enforces the most stringent security controls, including requiring a seccomp profile to be set to 'RuntimeDefault' or 'localhost/*'. Using the PodSecurity admission plugin with 'enforce' mode ensures that any pod failing the restricted policy is immediately rejected, guaranteeing that only compliant pods run in the namespace.

Answer

Use a mutating admission webhook to automatically add seccomp profiles

Answer

Enable the PodSecurity admission plugin with the 'baseline' policy and 'enforce' mode

Answer

Enable the PodSecurity admission plugin with the 'restricted' policy and 'warn' mode

Question 2

A cluster uses RBAC and a ServiceAccount 'monitor' in namespace 'observability'. The account needs to list pods in all namespaces. Which ClusterRole and binding should be created?

Accepted Answer

ClusterRole with 'list' on pods, ClusterRoleBinding. A ServiceAccount that needs to list pods across all namespaces requires a ClusterRole with the 'list' verb on pods, because ClusterRoles are not namespaced and can grant permissions cluster-wide. A ClusterRoleBinding is necessary to bind that ClusterRole to the ServiceAccount, as RoleBindings only apply within a single namespace and cannot grant cluster-scoped permissions.

Answer

Role with 'list' on pods, RoleBinding in observability

Answer

ClusterRole with 'get' on pods, ClusterRoleBinding

Answer

ClusterRole with 'list' on pods, RoleBinding in observability

Question 3

An administrator wants to prevent pods from running as root. Which SecurityContext field should be set at the pod level?

Accepted Answer

runAsNonRoot: true. Setting `runAsNonRoot: true` at the pod-level SecurityContext enforces that all containers in the pod must run with a non-root user (UID > 0). If a container image specifies a user with UID 0 (root) or does not specify a user, the container will fail to start, preventing privilege escalation from root access.

Answer

fsGroup: 2000

Answer

runAsGroup: 3000

Answer

runAsUser: 1000

Question 4

A company uses kube-bench to scan their cluster. The report shows a warning: 'Ensure that the --authorization-mode argument is set to Node,RBAC'. What is the best way to fix this?

Accepted Answer

Edit the kube-apiserver manifest to add --authorization-mode=Node,RBAC. Kube-bench checks that the API server's `--authorization-mode` includes both `Node` and `RBAC` in that order. The `Node` authorizer must come first to handle node-specific requests efficiently, followed by `RBAC` for user and service account authorization. Editing the kube-apiserver manifest (typically `/etc/kubernetes/manifests/kube-apiserver.yaml`) to add `--authorization-mode=Node,RBAC` ensures the static pod is automatically restarted by the kubelet with the correct configuration.

Answer

Add --authorization-mode=AlwaysDeny to the API server

Answer

Restart the API server with --authorization-webhook-config-file

Answer

Set --authorization-mode=RBAC only

Question 5

A pod is failing to start with: 'Error: container has runAsNonRoot and image will run as root'. The pod spec sets securityContext.runAsNonRoot: true. The container image is 'nginx:latest' which runs as root. Which change allows the pod to run while maintaining security?

Accepted Answer

Set runAsUser: 1000 in the container securityContext. Setting `runAsUser: 1000` in the container's securityContext overrides the default user (root) in the image, ensuring the container process runs as a non-root user (UID 1000). This satisfies the `runAsNonRoot: true` constraint at the pod level, which requires that the container's user ID is non-zero, while still maintaining security by not running as root.

Answer

Remove runAsNonRoot: true

Answer

Add a PodSecurityPolicy that allows root

Answer

Use a mutating webhook to change the image

Question 6

Which Kubernetes resource should be used to restrict egress traffic from pods?

Accepted Answer

NetworkPolicy with egress rules. NetworkPolicy with egress rules is the correct Kubernetes-native resource to restrict outbound traffic from pods. It uses label selectors, IP blocks, and port specifications to define which external destinations pods can reach, enforcing zero-trust network segmentation at the pod level.

Answer

PodSecurityPolicy

Answer

iptables rules on nodes

Answer

NetworkPolicy with ingress rules

Question 7

A cluster has a PodSecurityPolicy that requires 'RunAsAny' for the user. An administrator wants to enforce that all pods in namespace 'production' must run with a specific seccomp profile. Which approach is recommended given PSP is deprecated?

Accepted Answer

Enable PodSecurity admission with 'restricted' policy in enforce mode. PodSecurity admission (the replacement for PSP) allows enforcing a 'restricted' policy that mandates a seccomp profile (e.g., RuntimeDefault) at the namespace level. This directly meets the requirement without relying on deprecated PSPs, and the 'enforce' mode ensures pods violating the policy are rejected.

Answer

Create a new PSP with seccomp profile and assign it to the namespace

Answer

Set seccomp profile in the kubelet configuration

Answer

Use a mutating admission webhook to add seccomp profile

Question 8

Which TWO of the following are valid ways to restrict access to the Kubernetes API server?

Accepted Answer

Use webhook token authentication. Webhook token authentication (Option B) is a valid method to restrict API server access because it delegates token validation to an external service via a webhook, allowing custom authentication logic. This is a supported authentication strategy in Kubernetes, enabling fine-grained control over who can access the API server.

Answer

Use static token file

Answer

Enable NodeRestriction admission plugin

Answer

Enable anonymous access

Question 9

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 10

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 11

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 12

You are the security engineer for a multi-tenant Kubernetes cluster. The cluster uses kubeadm and runs Kubernetes v1.24. Each tenant has a dedicated namespace. A new tenant, 'acme-corp', requires that all pods in their namespace run with a read-only root filesystem and must not be able to escalate privileges. They also need to run a legacy container that must listen on a port below 1024. The cluster currently uses PodSecurityPolicy (PSP) but is planning to migrate to Pod Security Admission (PSA). The legacy container needs to run as non-root with the NET_BIND_SERVICE capability to bind to port 80. You need to configure security policies for the 'acme-corp' namespace without affecting other tenants. Which approach best meets these requirements while following Kubernetes best practices?

Accepted Answer

Use OPA/Gatekeeper to create a ConstraintTemplate that requires readOnlyRootFilesystem and allows only NET_BIND_SERVICE capability, then apply it to acme-corp namespace. OPA/Gatekeeper allows fine-grained, namespace-scoped policy enforcement that can require readOnlyRootFilesystem and restrict capabilities to only NET_BIND_SERVICE, meeting all requirements without affecting other tenants. Pod Security Admission (PSA) does not support custom capability restrictions or readOnlyRootFilesystem enforcement natively, and PSP is deprecated in Kubernetes v1.24 and being removed, making it unsuitable for new configurations. Gatekeeper’s ConstraintTemplate provides the flexibility to enforce these specific security contexts while following best practices for policy-as-code.

Answer

Enable Pod Security Admission with the 'baseline' policy in enforce mode for acme-corp namespace, and add a mutating webhook to set readOnlyRootFilesystem

Answer

Use Pod Security Admission with the 'privileged' policy and rely on the legacy container's securityContext

Answer

Create a new PSP that allows NET_BIND_SERVICE and requires readOnlyRootFilesystem, then bind it to the acme-corp namespace via RoleBinding

Question 13

Arrange the steps to enable and configure audit logging in Kubernetes.

Accepted Answer

1. Create audit policy file, 2. Mount policy file to API server, 3. Add audit flags to API server, 4. Restart API server, 5. Verify audit logs. Audit logging requires a policy file, mounting it, adding flags, restarting, and verifying logs.

Answer

1. Add audit flags to API server, 2. Create audit policy file, 3. Mount policy file to API server, 4. Restart API server, 5. Verify audit logs

Answer

1. Create audit policy file, 2. Add audit flags to API server, 3. Mount policy file to API server, 4. Restart API server, 5. Verify audit logs

Answer

1. Create audit policy file, 2. Mount policy file to API server, 3. Restart API server, 4. Add audit flags to API server, 5. Verify audit logs

Question 14

Match each Kubernetes security tool or feature to its purpose.

Accepted Answer

Pod Security Admission: Enforces pod security standards at admission time. Correct matches: Pod Security Admission enforces pod security standards; Network Policies control traffic; RBAC governs API access; kube-bench performs CIS checks. Common confusion arises from swapping definitions between PSA and Network Policies.

Answer

Pod Security Admission: Controls network traffic between pods

Answer

Network Policies: Enforces pod security standards

Question 15

A developer created a ClusterRole 'pod-reader' with rules to get, list, and watch pods, and bound it to a user. The user reports they cannot list pods in namespace 'test', although the same commands work in the 'default' namespace. What is the most likely cause?

Accepted Answer

The ClusterRole was bound with a namespace-scoped RoleBinding in 'default' instead of a ClusterRoleBinding. The ClusterRole was bound with a namespace-scoped RoleBinding (created in the 'default' namespace) rather than a cluster-scoped ClusterRoleBinding. A RoleBinding can reference a ClusterRole, but it only grants those permissions inside the RoleBinding's own namespace — which is why access works in 'default' but not in 'test'. Binding the ClusterRole with a ClusterRoleBinding would grant pod access in every namespace. Option A is wrong because a ClusterRoleBinding (not a RoleBinding) is what grants cluster-wide access. Option B is wrong because human users do not need ServiceAccounts. Option D is wrong because the scenario states the ClusterRole includes the 'list' verb.

Answer

The ClusterRole must be bound with a RoleBinding

Answer

The user needs a ServiceAccount

Answer

The pod-reader ClusterRole is missing 'list' verb