CKS Minimize Microservice Vulnerabilities Practice Test 8 — 15 Questions

Question 1

Which command can be used to view the current set of admission webhooks in the cluster?

Accepted Answer

kubectl get validatingwebhookconfigurations. Admission webhooks in Kubernetes are configured via `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` resources. The command `kubectl get validatingwebhookconfigurations` retrieves all validating admission webhooks currently registered in the cluster, which is the standard way to list them.

Answer

kubectl get webhooks

Answer

kubectl get webhookconfigurations

Answer

kubectl get admissionwebhooks

Question 2

Which TWO of the following are recommended practices for securing container images and runtime?

Accepted Answer

Set runAsNonRoot to true in securityContext. Setting `runAsNonRoot: true` in the securityContext ensures that the container's entrypoint runs with a user ID other than 0 (root), reducing the risk of container escape if an attacker gains code execution. Setting `readOnlyRootFilesystem: true` makes the container's filesystem read-only, preventing attackers from modifying critical system files or binaries. Both are key hardening practices recommended by Kubernetes security best practices.

Answer

Run containers as root inside the container for easier management

Answer

Mount the docker socket inside the container for debugging

Answer

Use the latest tag for all images

Question 3

Which THREE of the following are characteristics of container sandboxing runtimes like gVisor and Kata Containers?

Accepted Answer

They require setting spec.runtimeClassName in the pod spec. Container sandboxing runtimes like gVisor and Kata Containers are not the default runtime in Kubernetes. To use them, you must specify the runtime class name in the pod spec via `spec.runtimeClassName`. This field references a `RuntimeClass` resource that defines which container runtime (e.g., `gvisor`, `kata`) should be used for that pod, overriding the default runc runtime.

Answer

They eliminate the need for seccomp profiles

Answer

They share the host kernel directly

Question 4

Which TWO of the following are valid approaches to manage secrets in a Kubernetes cluster?

Accepted Answer

Mount secrets as volumes in pods. Kubernetes allows secrets to be mounted as volumes in pods, which is a secure approach as the secret data is stored in tmpfs (RAM-backed filesystem) and not written to disk on the node. This method avoids exposing secrets in environment variables that can be leaked through process dumps or logs, and it supports automatic updates when secrets are modified.

Answer

Pass secrets as environment variables

Answer

Embed secrets directly in the pod YAML definition

Answer

Store secrets as plain text in ConfigMap

Question 5

You need to enforce that all pods in the 'production' namespace run with read-only root filesystems. Which OPA Gatekeeper resource do you create first?

Accepted Answer

A ConstraintTemplate containing a Rego policy that checks for readOnlyRootFilesystem: true. OPA Gatekeeper requires a ConstraintTemplate first to define the Rego policy logic that checks for `readOnlyRootFilesystem: true`. The ConstraintTemplate is a custom resource that tells Gatekeeper what rule to enforce; without it, you cannot create a Constraint to apply the policy to the 'production' namespace. This follows the Gatekeeper workflow: template → constraint → enforcement via admission webhooks.

Answer

A ConfigMap containing the Rego policy, then reference it in a custom admission controller

Answer

A Constraint resource that enforces the readOnlyRootFilesystem rule

Answer

A ValidatingWebhookConfiguration that points to the Gatekeeper service

Question 6

A security auditor requires that all pods in a cluster must not run as root. Which Pod Security Standard (PSS) and enforcement mode should be applied at the namespace level?

Accepted Answer

Restricted profile with enforce mode. The Restricted profile is the only Pod Security Standard that prohibits running containers as root by enforcing the 'MustRunAsNonRoot' security context constraint. Applying it in 'enforce' mode ensures that any pod violating this rule is immediately rejected at admission time, which directly meets the auditor's requirement.

Answer

Baseline profile with enforce mode

Answer

Baseline profile with warn mode

Answer

Privileged profile with audit mode

Question 7

You need to encrypt secrets at rest in a Kubernetes cluster. What must be configured?

Accepted Answer

Create an EncryptionConfiguration object in the cluster and pass it to kube-apiserver via --encryption-provider-config. Kubernetes encrypts secrets at rest by defining an EncryptionConfiguration object that specifies which encryption providers (e.g., AES-CBC, secretbox, or KMS) to use, and then passing the configuration file to the kube-apiserver via the `--encryption-provider-config` flag. This ensures that when the API server writes secrets to etcd, they are encrypted before storage, and decrypted on read, meeting the requirement for encrypting secrets at rest.

Answer

Set the environment variable ENCRYPT_SECRETS=true on the kube-controller-manager

Answer

Use a MutatingWebhookConfiguration to encrypt secrets before storage

Answer

Enable the 'SecretEncryption' feature gate on all control plane components

Question 8

Which of the following is a best practice for storing sensitive data like passwords in Kubernetes?

Accepted Answer

Store them in Secrets and mount them as volumes. Kubernetes Secrets are designed to store sensitive data such as passwords, API keys, and certificates. Mounting a Secret as a volume ensures the data is written to a tmpfs in-memory filesystem (not to disk), reducing the risk of exposure via host filesystem access. This approach also avoids leaking secrets through environment variable dumps or logs, and supports automatic rotation when the Secret is updated.

Answer

Store them in ConfigMaps

Answer

Store them as environment variables in the Pod spec

Answer

Store them as labels on Pods

Question 9

You want to run a container with gVisor for sandboxing. After installing gVisor and creating a RuntimeClass named 'gvisor', which Pod configuration enables it?

Accepted Answer

Set spec.runtimeClassName: gvisor. The `spec.runtimeClassName` field in a Pod spec is the standard Kubernetes mechanism to select a specific container runtime for that Pod. When a RuntimeClass named 'gvisor' is created, setting `spec.runtimeClassName: gvisor` instructs the kubelet to use the gVisor runtime (runsc) to run the Pod's containers, providing an additional sandboxing layer for security.

Answer

Set spec.nodeSelector with 'gvisor: true'

Answer

Define an environment variable RUNTIME=gvisor in the container

Answer

Add an annotation 'container.runtime: gvisor' to the Pod

Question 10

You have created a ValidatingWebhookConfiguration to reject pods without resource limits. When you try to create a pod without limits, it is created successfully. What is the most likely reason?

Accepted Answer

The webhook service is not running or is unreachable. The most likely reason a pod without resource limits is created successfully despite a ValidatingWebhookConfiguration is that the webhook service itself is not running or is unreachable. When the API server cannot contact the webhook endpoint, the default behavior (failurePolicy: Ignore) allows the request to proceed, so the pod is created without validation. If the webhook were functioning correctly, it would reject the pod; thus, the failure to reject indicates a connectivity or service issue.

Answer

The webhook is not matching the namespace labels

Answer

The webhook is configured with failurePolicy: Fail

Answer

The pod is being created by a controller like a Deployment

Question 11

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 12

Which flag enables the PodSecurity admission plugin in kube-apiserver?

Accepted Answer

--enable-admission-plugins=PodSecurity. The PodSecurity admission plugin is enabled in kube-apiserver by passing the `--enable-admission-plugins=PodSecurity` flag. This flag activates the built-in Pod Security Admission (PSA) controller, which replaced the deprecated PodSecurityPolicy (PSP) in Kubernetes v1.25. The plugin enforces the Pod Security Standards (baseline, restricted, privileged) at the namespace level based on labels.

Answer

--admission-control=PodSecurity

Answer

--feature-gates=PodSecurity=true

Answer

--pod-security-policy=true

Question 13

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 14

Which TWO actions help minimize vulnerabilities in microservices by securing secrets? (Choose two)

Accepted Answer

Mount Secrets as volumes instead of environment variables. Mounting secrets as volumes is more secure than using environment variables. When secrets are injected as environment variables, they can be exposed through the process environment (e.g., via `/proc/self/environ` or `env` command) and are more likely to be accidentally logged or leaked. Mounting as a volume ensures the secret is only available as a file in the container's filesystem, and the secret data is not visible in the process list or environment dumps, reducing the attack surface.

Answer

Base64 encode the secret in the YAML manifest

Answer

Set the secret as a label on the pod

Answer

Store secrets in ConfigMaps to leverage ConfigMap encryption

Question 15

Which ONE of the following is a valid Rego policy construct used in OPA Gatekeeper ConstraintTemplates to enforce security policies?

Accepted Answer

violation[{"msg": msg}] { condition }. In OPA Gatekeeper ConstraintTemplates, the only Rego construct that directly triggers a constraint violation is `violation[{"msg": msg}] { condition }`. When the condition evaluates to true, Gatekeeper generates a violation message. The `allow` and `deny` rules are not standard constructs for enforcing constraints in Gatekeeper; they are general Rego rules used in other OPA contexts but not within ConstraintTemplates to report violations. Options D (`audit`) and E (`warn`) are also not valid Rego constructs for Gatekeeper constraints.

Answer

allow { condition }

Answer

deny[{"msg": msg}] { condition }

Answer

audit { condition }

Answer

warn[{"msg": msg}] { condition }