CKS Minimize Microservice Vulnerabilities Practice Test 7 — 15 Questions

Question 1

Which TWO of the following are secure practices for managing secrets in Kubernetes? (Select TWO.)

Accepted Answer

Use a CSI driver to mount secrets as volumes. The CSI (Container Storage Interface) driver for secrets allows secrets to be mounted as volumes without storing them in etcd or exposing them in environment variables. This approach leverages the CSI driver's ability to fetch secrets from external providers (e.g., HashiCorp Vault) on-demand, ensuring secrets are never persisted in Kubernetes objects and reducing the attack surface. It also supports rotation without pod restarts, as the volume content can be updated dynamically.

Answer

Store secrets as environment variables

Answer

Embed secrets in container images

Answer

Store secrets in a ConfigMap

Question 2

A security admin wants to ensure that no container in a specific namespace runs as root. Which Gatekeeper ConstraintTemplate and Constraint configuration should be used?

Accepted Answer

ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot != true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`. Ly defines a ConstraintTemplate with a Rego rule that denies if `runAsNonRoot` is not set to true, ensuring that containers are explicitly configured to run as non-root. The Constraint matches all Pods in the namespace. Option A is incorrect because it denies when `runAsNonRoot` is true, which would allow root containers. Option C checks capabilities, which is unrelated. Option D checks if `runAsUser` is 0, which is less comprehensive and does not enforce the `runAsNonRoot` field.

Answer

ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot == true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

Answer

ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.capabilities.drop != "ALL" }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

Answer

ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsUser == 0 }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

Question 3

Which of the following is the correct kubectl command to view the OPA Gatekeeper ConstraintTemplates in the cluster?

Accepted Answer

kubectl get constrainttemplates. OPA Gatekeeper registers its constraints as custom resources in Kubernetes, and the standard `kubectl get constrainttemplates` command retrieves all ConstraintTemplate resources from the cluster. This works because Gatekeeper uses the Kubernetes API aggregation layer, making ConstraintTemplates a top-level resource type that kubectl can query directly.

Answer

kubectl get gatekeeper-constrainttemplates

Answer

kubectl describe opa constrainttemplate

Answer

kubectl get crd -o name | grep constraint

Question 4

An admin wants to enforce that all pods in a namespace use a read-only root filesystem except for a specific deployment that needs to write to a temporary directory. Which approach best meets this requirement?

Accepted Answer

Use a Gatekeeper Constraint that denies pods with readOnlyRootFilesystem not set to true, but add an exception label on the specific deployment's namespace or pod, and modify the Constraint to skip pods with that label. Gatekeeper (OPA/Gatekeeper) allows you to define a Constraint that denies pods without `readOnlyRootFilesystem: true`, and you can add an exception label on the specific deployment's pod template. By modifying the Constraint to skip pods with that label (using a `labelSelector` or `excludedNamespaces` in the Constraint's spec), you enforce the policy for all pods except the exempted deployment, meeting the requirement without manual patching or legacy PSPs.

Answer

Set a default readOnlyRootFilesystem: true via a mutating webhook, and then manually patch the specific deployment after creation

Answer

Modify the PodSecurityPolicy to allow readOnlyRootFilesystem: false for the specific deployment's service account

Answer

Set readOnlyRootFilesystem: true in the deployment's pod template and add an emptyDir volume for the temporary directory

Question 5

Which field in a Pod's securityContext prevents privilege escalation by the container?

Accepted Answer

allowPrivilegeEscalation. `allowPrivilegeEscalation` controls whether a process can gain more privileges than its parent process. In a Pod's securityContext, setting this field to `false` prevents the container from performing privilege escalation, such as via setuid binaries or system calls like `setuid(0)`. This directly mitigates a common attack vector where an attacker exploits a container process to gain root access.

Answer

capabilities.add: ["SYS_ADMIN"]

Answer

runAsNonRoot

Answer

privileged

Question 6

A security admin wants to ensure all pods in a cluster drop ALL Linux capabilities. Which of the following YAML snippets should be added to a PodSecurityPolicy (assuming PSP is enabled) or a pod spec?

Accepted Answer

capabilities:
  drop: ["ALL"]. Dropping all Linux capabilities from a container is achieved by specifying `drop: ["ALL"]` in the PodSecurityPolicy or pod security context. This ensures the container runs with no capabilities, following the principle of least privilege. The correct syntax uses a YAML list (array) for the `drop` field, not a string.

Answer

capabilities:
  drop: "ALL"

Answer

capabilities:
  drop:
  - "NET_RAW"

Answer

capabilities:
  add: ["ALL"]

Question 7

An admin has created an EncryptionConfiguration to encrypt secrets at rest in etcd. After applying the configuration and restarting the kube-apiserver, existing secrets are still stored in plaintext. What is the most likely reason?

Accepted Answer

Existing secrets are not automatically encrypted; they need to be rewritten by reading and writing them back. Kubernetes does not automatically encrypt existing secrets stored in etcd when an EncryptionConfiguration is applied. The encryption configuration only affects data written after the kube-apiserver is restarted; previously stored secrets remain in plaintext until they are read and rewritten (e.g., by running `kubectl get secret <name> -o yaml | kubectl replace -f -`). This behavior is by design, as the API server encrypts data on write, not retroactively.

Answer

The encryption provider is set to 'identity' which does not encrypt

Answer

The kube-apiserver was not restarted after applying the configuration

Answer

The EncryptionConfiguration has a syntax error that caused it to be ignored

Question 8

What is the primary benefit of using external secret managers (e.g., HashiCorp Vault) in Kubernetes?

Accepted Answer

They provide better control over secret rotation, auditing, and access policies. External secret managers like HashiCorp Vault provide features such as secret rotation, auditing, and fine-grained access policies, which are primary benefits. Option A is incorrect because even with external secret managers, secrets are often still stored in etcd unless encrypted at rest. Option B is incorrect because while they improve security, they do not prevent all unauthorized access; misconfigurations can still occur. Option D is incorrect because Kubernetes Secrets are still used as a reference; external managers complement rather than fully replace them.

Answer

They ensure that secrets are never stored in etcd

Answer

They prevent all unauthorized access to secrets

Answer

They eliminate the need for Kubernetes Secrets entirely

Question 9

An administrator wants to enforce mutual TLS (mTLS) between all services in an Istio service mesh. Which resource should be configured?

Accepted Answer

PeerAuthentication. PeerAuthentication is the correct resource because it defines the TLS mode for traffic between services within the Istio mesh. By setting the mode to STRICT, mTLS is enforced, requiring all service-to-service communication to use mutual TLS. This is the Istio-native way to enable mTLS at the mesh or namespace level.

Answer

AuthorizationPolicy

Answer

ServiceEntry

Answer

VirtualService

Question 10

A cluster administrator wants to run some workloads in a sandboxed environment using gVisor. Which Kubernetes resource must be created first to allow pods to request the gVisor runtime?

Accepted Answer

Create a RuntimeClass resource that specifies the gVisor runtime handler. C is correct because in Kubernetes, a RuntimeClass resource must be created to define a container runtime configuration, such as gVisor. This resource specifies a runtime handler (e.g., 'runsc') that the container runtime uses to run pods in a sandboxed environment. Pods can then reference this RuntimeClass via the `runtimeClassName` field in their spec to request the gVisor runtime.

Answer

Create a new PodSecurityPolicy that allows the gVisor runtime

Answer

Create a custom resource definition for the runtime

Answer

Add a `runtimeClass` field to the pod spec

Question 11

Which of the following is a characteristic of Kata Containers compared to gVisor?

Accepted Answer

Kata Containers use lightweight VMs to isolate containers. Kata Containers use lightweight virtual machines (VMs) to provide strong hardware-enforced isolation for containers. Each container runs inside its own minimal VM with a separate kernel, offering security comparable to a VM while maintaining container-like performance and orchestration. This is the defining characteristic that distinguishes Kata Containers from gVisor.

Answer

Kata Containers require no additional configuration in Kubernetes

Answer

Kata Containers have lower overhead than gVisor

Answer

Kata Containers provide a user-space kernel that intercepts system calls

Question 12

An admin has deployed a ValidatingWebhookConfiguration that denies pods with `runAsNonRoot: false`. After creating a pod that does not set `runAsNonRoot` at all, the pod is created successfully. Why did the webhook not deny it?

Accepted Answer

The webhook configuration's rules do not match the pod create operation. A is correct because the ValidatingWebhookConfiguration's `rules` define which API operations (e.g., create, update) and resources (e.g., pods) trigger the webhook. If the rules do not include the `create` operation for pods, the webhook will not intercept the pod creation request, so the pod is created without validation. The pod's security context (missing `runAsNonRoot`) is irrelevant if the webhook never fires.

Answer

The webhook's failure policy is set to Ignore

Answer

The webhook is only applied to pods in a specific namespace

Answer

The webhook only applies to pods created with a specific service account

Question 13

Which TWO of the following are valid ways to enforce that containers run with a read-only root filesystem?

Accepted Answer

Using a MutatingWebhookConfiguration that adds `readOnlyRootFilesystem: true` to all containers. A MutatingWebhookConfiguration can intercept Pod creation requests and automatically add the `readOnlyRootFilesystem: true` field to every container's securityContext, enforcing a read-only root filesystem without requiring manual changes to Pod specs. Option E is correct because setting `readOnlyRootFilesystem: true` directly in the container's securityContext is the explicit Kubernetes API field that makes the container's root filesystem read-only, preventing writes to the filesystem layer.

Answer

Setting `runAsNonRoot: true` in the pod's securityContext

Answer

Using an emptyDir volume mounted at /

Answer

Setting `fsGroup: 1000` in the pod's securityContext

Question 14

Which THREE of the following are required to configure encryption of secrets at rest in Kubernetes?

Accepted Answer

Specifying an encryption provider such as `aescbc` in the EncryptionConfiguration. The `aescbc` encryption provider is one of the supported providers in Kubernetes for encrypting secrets at rest. Specifying it in the `EncryptionConfiguration` tells the kube-apiserver which encryption algorithm to use when writing data to etcd. Without a provider like `aescbc`, secrets are stored in plaintext in etcd.

Answer

Running `kubectl get secrets --all-namespaces -o yaml | kubectl apply -f -` to rewrite existing secrets

Answer

Modifying the etcd configuration to enable encryption at rest

Question 15

Which TWO of the following are best practices for securing secrets in Kubernetes?

Accepted Answer

Enabling encryption at rest for secrets. Kubernetes stores secrets in etcd by default without encryption. Enabling encryption at rest (via the EncryptionConfiguration resource with a provider like AES-CBC or KMS) ensures that secret data is encrypted before being written to etcd, protecting it from unauthorized access to the underlying storage. This is a fundamental security control required for compliance and defense-in-depth.

Answer

Storing secrets as environment variables

Answer

Using the default secret type (Opaque) for all secrets

Answer

Limiting the number of secrets in the cluster