CKS Minimize Microservice Vulnerabilities Practice Test 12 — 15 Questions

Question 1

A security engineer wants to enable mutual TLS (mTLS) between services in an Istio service mesh. Which Istio resource should be used to define the mTLS mode for the entire mesh?

Accepted Answer

PeerAuthentication with mTLS mode set to STRICT. PeerAuthentication is the Istio resource specifically designed to define the authentication policy for workloads, including the mTLS mode. Setting `mTLS.mode: STRICT` in a PeerAuthentication policy enforces mutual TLS for all traffic within the mesh, ensuring that every service-to-service connection requires a valid client certificate. This is the correct resource for mesh-wide mTLS enforcement, as it operates at the authentication layer rather than the traffic routing layer.

Answer

DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

Answer

VirtualService with tls configuration

Answer

ServiceEntry with mTLS enabled

Question 2

Which of the following is a valid way to drop all capabilities from a container?

Accepted Answer

securityContext:
  capabilities:
    drop: ["ALL"]. In Kubernetes, the `securityContext.capabilities.drop` field is used to explicitly remove Linux capabilities from a container. Dropping `ALL` removes every capability, ensuring the container runs with the least privilege possible, which is a key security best practice for minimizing microservice vulnerabilities.

Answer

securityContext:
  dropCapabilities: true

Answer

securityContext:
  privileged: false

Answer

securityContext:
  capabilities:
    remove: ["ALL"]

Question 3

Which TWO of the following are correct about container sandboxing technologies? (Select TWO)

Accepted Answer

Kata Containers run containers in lightweight VMs, providing hardware-level isolation.. Kata Containers provide hardware-level isolation by running each container or pod in a lightweight VM with its own guest kernel using KVM. Option B is correct because gVisor implements a user-space kernel (called Sentry) that intercepts system calls, providing a kernel-level sandbox without dedicated VMs. Option C is incorrect because Kata Containers use a guest kernel, not the host kernel. Option D is incorrect because gVisor does not run containers in separate VMs; it runs as a kernel within the user space. Option E is incorrect because although RuntimeClass is commonly used to select non-default runtimes in Kubernetes, the statement is not universally required; it is a mechanism but not a strict requirement for using these technologies, making the claim that both 'require' RuntimeClass too absolute and thus false.

Answer

Kata Containers use the host kernel for system calls.

Answer

gVisor runs containers in separate VMs for each pod.

Answer

Both gVisor and Kata Containers require RuntimeClass to be used in Kubernetes.

Question 4

You are configuring encryption at rest for Kubernetes secrets. After creating an EncryptionConfiguration with aescbc provider, which additional step is required to enable encryption?

Accepted Answer

Restart the kube-apiserver with --encryption-provider-config flag. The EncryptionConfiguration resource defines how Kubernetes should encrypt data at rest, but it is not automatically applied. The kube-apiserver must be restarted with the `--encryption-provider-config` flag pointing to the configuration file so that it reads and enforces the encryption settings for all subsequent writes to etcd. Without this flag, the apiserver ignores the EncryptionConfiguration entirely.

Answer

Apply the EncryptionConfiguration as a ConfigMap

Answer

Restart the kube-scheduler

Answer

Recreate all secrets in the cluster

Question 5

A pod uses a Secret mounted as a volume. The Secret is updated. How can the pod consume the updated values without restarting?

Accepted Answer

The mounted volume is automatically updated over time. When a Secret is mounted as a volume in Kubernetes, the kubelet periodically syncs the secret data from the API server and updates the files in the volume. This means the pod can consume the updated values without needing a restart, as the files are refreshed automatically (with a default sync period of around 60 seconds). Option C correctly identifies this behavior.

Answer

Use a sidecar container that watches for changes and reloads the application

Answer

Update the pod spec to reference a new Secret version

Answer

Delete and recreate the pod

Question 6

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 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 [CORRECT]. 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 [wrong]

Answer

Store them as environment variables in the Pod spec [wrong]

Answer

Store them as labels on Pods [wrong]

Question 9

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 10

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 }

Question 11

Which command creates a validating webhook configuration that checks all pods in the cluster?

Accepted Answer

kubectl create validatingwebhookconfiguration my-webhook --from-file=webhook.yaml. `kubectl create validatingwebhookconfiguration` is the specific command to create a ValidatingWebhookConfiguration resource from a YAML file, which can be configured to intercept and validate pod creation requests across the cluster. This resource allows you to define a webhook that checks all pods before they are admitted, enforcing custom validation logic.

Answer

kubectl create mutatingwebhookconfiguration my-webhook --from-file=webhook.yaml

Answer

kubectl run webhook --image=webhook

Answer

kubectl apply -f webhook.yaml --validating

Question 12

You need to drop all Linux capabilities from a container. Which YAML snippet is correct?

Accepted Answer

securityContext: { capabilities: { drop: ["ALL"] } }. In Kubernetes, to drop Linux capabilities from a container, you must use the `capabilities.drop` field inside `securityContext`. Option D correctly nests `capabilities` under `securityContext`. Option B is incorrect because it places `capabilities` directly under the container spec without the `securityContext` wrapper, which is not valid in most Kubernetes API versions. Options A and C use invalid keywords (`remove` and `none`). Therefore, only Option D is correct.

Answer

capabilities: { remove: ["ALL"] }

Answer

capabilities: { drop: ["ALL"] }

Answer

capabilities: { none: true }

Question 13

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

Accepted Answer

Mount secrets as volumes in the pod. Mounting secrets as volumes ensures that sensitive data is stored in the in-memory tmpfs filesystem, which is never written to disk and is automatically removed when the pod is deleted. This approach also allows for automatic updates of secret values when the Secret object is modified, without requiring a pod restart, and provides better access control through filesystem permissions.

Answer

Use environment variables in the pod spec to pass secrets

Answer

Embed secrets as literals in the pod YAML file

Answer

Store them in ConfigMaps

Question 14

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.. OPA/Gatekeeper enforces policies via a two-part model: a ConstraintTemplate defines the Rego logic (e.g., denying a namespace if it lacks the required label), and a Constraint instantiates that template with specific parameters (e.g., 'security-tier' with values 'high' or 'medium'). This decouples policy definition from enforcement, allowing Gatekeeper's admission webhook to reject non-compliant resources at creation or update time.

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 15

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

Accepted Answer

EncryptionConfiguration. Kubernetes uses an `EncryptionConfiguration` object to configure encryption at rest for secrets and other resources in etcd. This YAML-based resource defines which providers (e.g., `aescbc`, `kms`, `secretbox`) are used to encrypt data before it is written to the underlying storage. The API server reads this configuration from a file specified via the `--encryption-provider-config` flag, enabling transparent encryption and decryption of resource data.

Answer

EncryptionProvider

Answer

SecretEncryptionConfig

Answer

KMSProvider