CKS Minimize Microservice Vulnerabilities Practice Test 10 — 15 Questions

Question 1

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 2

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 3

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 4

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 5

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 6

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 such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault provide centralized lifecycle management for secrets, including automated rotation, detailed audit logging, and fine-grained access policies. In Kubernetes, integrating these tools (via CSI drivers or operators) gives teams stronger governance than native Kubernetes Secrets, which lack built-in rotation and rich auditing. The primary benefit is therefore better control over rotation, auditing, and access policies.

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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

Question 14

You need to ensure that all pods in a cluster run with read-only root filesystems. Which Pod Security Standard (PSS) control field should be set to true?

Accepted Answer

securityContext.readOnlyRootFilesystem. The Pod Security Standard (PSS) control field `securityContext.readOnlyRootFilesystem` must be set to `true` at the pod or container security context level to enforce a read-only root filesystem. This setting prevents containers from writing to their root filesystem, reducing the attack surface by limiting the ability to drop malicious binaries or modify system files. It is a key control under the 'Restricted' PSS profile for minimizing microservice vulnerabilities.

Answer

spec.readOnlyRootFilesystem

Answer

securityContext.privileged: false

Answer

container.readOnly

Question 15

An administrator wants to enforce a policy that all containers must drop ALL capabilities and not allow privilege escalation. Which YAML snippet correctly implements this requirement in a PodSecurityPolicy-like manner using a security context? (Note: PodSecurityPolicy is deprecated; consider using a ValidatingAdmissionPolicy or OPA/Gatekeeper, but for this question choose the correct security context fields.)

Accepted Answer

securityContext: { allowPrivilegeEscalation: false, capabilities: { drop: ["ALL"] } }. It sets `allowPrivilegeEscalation: false` to prevent privilege escalation (e.g., via setuid binaries) and `capabilities: { drop: ["ALL"] }` to remove all Linux capabilities from the container. This combination enforces the requirement that containers start with no extra privileges and cannot gain more, aligning with the principle of least privilege in PodSecurityPolicy-like enforcement.

Answer

securityContext: { privileged: false, capabilities: { drop: ["ALL"] } }

Answer

securityContext: { allowPrivilegeEscalation: false, capabilities: { add: ["ALL"] } }

Answer

spec: { allowPrivilegeEscalation: false, capabilities: { drop: ["ALL"] } }