CKS Minimize Microservice Vulnerabilities Practice Test 9 — 15 Questions

Question 1

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. Option C is correct. A RuntimeClass is required to define the container runtime (e.g., gVisor). Pods then specify `runtimeClassName` to use that runtime. Option A is not correct because RuntimeClass is not a pod spec field but a separate resource. Option B is not correct because a custom resource definition is not needed for built-in RuntimeClass. Option D is not correct because a new PodSecurityPolicy is not required.

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 2

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

Accepted Answer

Kata Containers use lightweight VMs to isolate containers. Option B is correct. Kata Containers use lightweight virtual machines to provide strong isolation, while gVisor uses a user-space kernel for sandboxing. Option A is true for gVisor, not Kata. Option C is not correct; both have overhead. Option D is not correct; both have similar integration complexity.

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 3

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. Option C is correct. A ValidatingWebhookConfiguration must define `rules` with `apiGroups`, `apiVersions`, `operations`, and `resources` to match requests. If the rules do not match the pod creation request, the webhook is not called. Option A is wrong because the webhook can be cluster-scoped. Option B is wrong because admission webhooks can be used with any pod. Option D is wrong because the webhook can have any failure policy.

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 4

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. Options A and D are correct. Setting `readOnlyRootFilesystem: true` in the container's securityContext enforces a read-only root filesystem. A mutating webhook can also add this setting automatically. Option B is incorrect because `runAsNonRoot` does not affect filesystem writability. Option C is incorrect because `securityContext.fsGroup` is about file ownership. Option E is incorrect because `emptyDir` volumes are writable but do not enforce a read-only root.

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 5

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. Options A, C, and D are required. A: An EncryptionConfiguration YAML file is needed. C: The kube-apiserver must be started with the `--encryption-provider-config` flag pointing to that file. D: The encryption provider must be specified (e.g., `aescbc`, `secretbox`). Option B is not required because the etcd cluster itself does not need modification for Kubernetes encryption; it just stores encrypted data. Option E is not required because rewriting secrets after encryption is optional; the encryption applies to new writes automatically.

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 6

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

Accepted Answer

Enabling encryption at rest for secrets. Options B and D are best practices. Option B: Using external secret managers provides rotation and auditing. Option D: Encryption at rest protects secrets stored in etcd. Option A is not a best practice because secrets can be exposed. Option C: Reducing the number of secrets does not directly improve security; proper management is better. Option E: The default `type: Opaque` is not secure; using encrypted secrets is better.

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 7

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 'readOnlyRootFilesystem' field in the security context of a container, when set to true, ensures the root filesystem is read-only. This is a common security hardening measure.

Answer

spec.readOnlyRootFilesystem

Answer

securityContext.privileged: false

Answer

container.readOnly

Question 8

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"] } }. The correct approach is to set 'allowPrivilegeEscalation: false' and 'capabilities.drop: ["ALL"]' under the container's securityContext. This ensures no privilege escalation and drops all capabilities.

Answer

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

Answer

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

Answer

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

Question 9

A security team wants to use OPA/Gatekeeper to enforce that all namespaces must have a label 'security-tier' with value 'high' or 'medium'. What is the correct approach?

Accepted Answer

Create a ConstraintTemplate with Rego that denies namespaces missing the label, then create a Constraint referencing that template.. The correct approach is to create a ConstraintTemplate that defines the Rego logic for checking the label, and then create a Constraint that uses that template. The Constraint is the actual policy object that specifies the enforcement scope (e.g., all namespaces).

Answer

Write a MutatingWebhookConfiguration that adds the label automatically.

Answer

Use kubectl label command with a --validate flag.

Answer

Create a ValidatingWebhookConfiguration that directly contains the Rego policy.

Question 10

You need to encrypt Kubernetes secrets at rest. Which resource should you configure?

Accepted Answer

EncryptionConfiguration. EncryptionConfiguration is the Kubernetes resource that defines how to encrypt resources at rest in etcd, including secrets. It is used with the kube-apiserver flag --encryption-provider-config.

Answer

EncryptionProvider

Answer

SecretEncryptionConfig

Answer

KMSProvider

Question 11

A pod runs with a service mesh sidecar (Istio). The team wants to enforce mutual TLS (mTLS) for all traffic between services in the 'production' namespace. Which resource should be applied?

Accepted Answer

PeerAuthentication with mode: STRICT in the namespace. A PeerAuthentication resource with mTLS mode set to STRICT enforces mutual TLS for all traffic within the namespace. This is an Istio security policy.

Answer

DestinationRule with trafficPolicy: tls: mode: ISTIO_MUTUAL

Answer

VirtualService with TLS settings

Answer

ServiceEntry with mTLS enabled

Question 12

An admin runs 'kubectl run test-pod --image=busybox --command -- sleep 3600' and then executes 'kubectl exec test-pod -- cat /var/run/secrets/kubernetes.io/serviceaccount/token'. The admin wants to prevent such access to the service account token. What is the correct action?

Accepted Answer

Set automountServiceAccountToken: false in the pod spec. Setting automountServiceAccountToken to false in the pod spec prevents automatic mounting of the service account token. This is a security best practice for pods that do not need to interact with the API server.

Answer

Remove the service account from the pod

Answer

Set securityContext.runAsNonRoot: true

Answer

Use a NetworkPolicy to block access to the API server

Question 13

Which command correctly creates a secret from a file named 'config.json'?

Accepted Answer

kubectl create secret generic my-secret --from-file=config.json. The 'kubectl create secret generic' command with '--from-file' flag creates a secret from a file. The syntax is 'kubectl create secret generic --from-file==' or just '--from-file=' where the key defaults to the filename.

Answer

kubectl create configmap my-secret --from-file=config.json

Answer

kubectl create secret tls my-secret --cert=config.json

Answer

kubectl create secret generic my-secret --from-literal=config.json

Question 14

You want to run a container with gVisor (runsc) runtime for sandboxing. Which resource is required to use a non-default runtime?

Accepted Answer

RuntimeClass resource. A RuntimeClass resource defines a container runtime (e.g., gVisor) that can be referenced in pod spec via 'runtimeClassName'. This is the standard way to use alternative runtimes in Kubernetes.

Answer

PodSecurityPolicy

Answer

ContainerRuntime resource

Answer

Node runtime configuration only

Question 15

An OPA/Gatekeeper ConstraintTemplate is written to enforce that all Deployments have the label 'app.kubernetes.io/name'. However, the Constraint does not deny Deployments without the label. What is the most likely cause?

Accepted Answer

The Rego rule does not set 'violation' to true when the label is missing. Gatekeeper ConstraintTemplates use Rego to define violation rules. A common mistake is to use 'violation' with a generic message but not actually deny the request. The Rego must contain a 'deny' rule or use the 'violation' keyword correctly. In Gatekeeper, the default Rego rule name is 'violation' and it must be set to true when a violation occurs. If the rule is empty or incorrectly written, it will not deny.

Answer

The Constraint is not bound to any namespaces

Answer

The Deployment has the label set but with a different value

Answer

Gatekeeper is not installed in the cluster