CKS Practice Test 5 — 10 Questions

Question 1

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 2

You need to ensure that all pods in a namespace have the label 'security: high' added automatically upon creation. Which admission controller should you use?

Accepted Answer

MutatingWebhookConfiguration. A MutatingWebhookConfiguration intercepts pod creation requests and can automatically add the label 'security: high' to pods in a namespace. This admission controller mutates the object before it is persisted, ensuring all pods receive the label without manual intervention.

Answer

PodSecurityPolicy (deprecated)

Answer

ResourceQuota

Answer

ValidatingAdmissionPolicy

Question 3

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 4

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 5

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 6

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 7

An admin runs 'kubectl run nginx --image=nginx' and the pod fails with 'ImagePullBackOff'. The cluster has an OPA/Gatekeeper constraint that only allows images from 'myregistry.io'. How can the admin quickly test the restriction?

Accepted Answer

Use an image from 'myregistry.io/nginx:latest'. The OPA/Gatekeeper constraint explicitly restricts allowed images to those from 'myregistry.io'. By specifying an image from that registry (e.g., 'myregistry.io/nginx:latest'), the admin can quickly verify that the constraint permits compliant images. This tests the policy's intended behavior without altering or bypassing the constraint.

Answer

Delete the OPA constraint

Answer

Add a label 'allowlist=true' to the pod

Answer

Use 'kubectl run nginx --image=nginx --validate=false'

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