CKS Minimize Microservice Vulnerabilities Practice Test 6 — 15 Questions

Question 1

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 2

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 3

Which TWO container sandboxing technologies are supported in Kubernetes via RuntimeClass? (Choose two)

Accepted Answer

gVisor (runsc). gVisor (runsc) is a container sandboxing technology that provides a user-space kernel for containers, isolating them from the host kernel. Kubernetes supports gVisor via RuntimeClass, allowing pods to be scheduled with the 'runsc' runtime for enhanced security.

Answer

Docker

Answer

containerd

Answer

runc

Question 4

Which field must be set in a Pod's security context to prevent the container from running as the root user?

Accepted Answer

runAsNonRoot: true. The `runAsNonRoot: true` field in a Pod's security context enforces that the container's entrypoint cannot run as UID 0 (root). If the container image attempts to run as root, the container runtime (e.g., containerd) will reject the container from starting, ensuring compliance with the principle of least privilege and mitigating root-based container escapes.

Answer

runAsUser: 1000

Answer

readOnlyRootFilesystem: true

Answer

allowPrivilegeEscalation: false

Question 5

An administrator deploys a Gatekeeper ConstraintTemplate with the following Rego policy:

package k8srequiredlabels
deny[{"msg": msg}] {
  input.request.kind.kind == "Pod"
  not input.request.object.metadata.labels["security-tier"]
  msg := "Pod must have label 'security-tier'"
}

After creating the Constraint, a user creates a Pod without the 'security-tier' label. What is the expected behavior?

Accepted Answer

The pod creation is denied with a message. The Gatekeeper ConstraintTemplate defines a Rego policy that denies any Pod creation request that lacks the 'security-tier' label. When the user creates a Pod without this label, the admission webhook evaluates the policy and returns a denial message 'Pod must have label 'security-tier'', preventing the Pod from being created. Gatekeeper operates as a validating admission webhook, so it rejects the request before the object is persisted in etcd.

Answer

The pod is created and the label is automatically added

Answer

Only the first pod without the label is denied; subsequent ones are allowed

Answer

The pod is created but logged as a violation

Question 6

You are configuring an Istio service mesh for mTLS between services. Which resource defines the TLS mode for traffic between services in a namespace?

Accepted Answer

PeerAuthentication. PeerAuthentication is the correct resource because it defines the TLS mode (e.g., STRICT, PERMISSIVE, DISABLE) for mTLS between services within a namespace in Istio. It enforces the authentication policy for workloads, ensuring that all traffic between them uses mutual TLS as specified. This directly controls the TLS mode for inter-service communication at the namespace or mesh level.

Answer

ServiceEntry

Answer

VirtualService

Answer

DestinationRule

Question 7

A cluster administrator wants to ensure that all Secrets are encrypted at rest using AES-CBC with a key managed by the local Kubernetes API server. Which configuration is required?

Accepted Answer

Set --encryption-provider-config flag to a file containing EncryptionConfiguration with 'aescbc' provider. The `--encryption-provider-config` flag on the kube-apiserver points to a YAML file containing an `EncryptionConfiguration` resource. Within that configuration, specifying the `aescbc` provider enables AES-CBC encryption for Secrets at rest, with the encryption key managed locally by the API server. This is the only option that satisfies the requirement for AES-CBC encryption with a locally managed key.

Answer

Enable etcd encryption by setting --experimental-encryption-provider-config

Answer

Use Secret resource's 'data' field with base64 encoding

Answer

Set --encryption-provider-config flag to a file containing EncryptionConfiguration with 'identity' provider

Question 8

A security team wants to enforce that containers in a specific namespace cannot gain new capabilities. Which Pod security context field is used to achieve this?

Accepted Answer

allowPrivilegeEscalation: false. `allowPrivilegeEscalation: false` directly controls whether a process can gain more privileges than its parent, which is the mechanism by which containers acquire new capabilities (e.g., via `setuid` binaries or `file capabilities`). Setting this to `false` prevents privilege escalation within the container, effectively blocking the acquisition of new capabilities beyond those initially granted. This field is defined in the Pod Security Context and is a key control for minimizing microservice vulnerabilities.

Answer

capabilities.drop: ["ALL"]

Answer

privileged: false

Answer

runAsNonRoot: true

Question 9

A developer asks you to run a container with gVisor runtime. The cluster has a RuntimeClass named 'gvisor' defined. Which field must be added to the Pod spec to use gVisor?

Accepted Answer

spec.runtimeClassName: gvisor. The `runtimeClassName` field is a top-level field in the Pod spec (i.e., `spec.runtimeClassName`) that specifies the name of the RuntimeClass resource to use for running the Pod's containers. In this case, setting `spec.runtimeClassName: gvisor` instructs the kubelet to use the gVisor runtime (via the 'gvisor' RuntimeClass) for all containers in the Pod, enabling a sandboxed kernel for enhanced isolation.

Answer

spec.containers[0].runtimeClassName: gvisor

Answer

metadata.runtimeClassName: gvisor

Answer

spec.runtimeClass: gvisor

Question 10

A pod's container tries to read environment variables that contain database credentials. The cluster has an external secrets manager (HashiCorp Vault) integrated via a sidecar. Which approach is MOST secure for exposing secrets to the container?

Accepted Answer

Mount the secrets as a volume using a CSI driver. Mounting secrets via a CSI driver (e.g., the HashiCorp Vault CSI provider) allows secrets to be retrieved on-demand from the external secrets manager and presented as a volume to the pod. This approach avoids storing secrets in etcd, eliminates the need for a sidecar, and ensures that secrets are never written to disk or exposed in environment variables, which can be leaked through logs or `/proc` files.

Answer

Set the secrets as environment variables using the 'env' field

Answer

Embed the secrets directly in the container image

Answer

Use a ConfigMap to store the secrets

Question 11

An OPA Gatekeeper ConstraintTemplate uses a Rego rule that denies pods without a specific label. The Constraint is created but pods without the label are still being allowed. What is the MOST likely cause?

Accepted Answer

The Constraint object has not been created. The most likely cause is that the Constraint object has not been created. In OPA Gatekeeper, a ConstraintTemplate defines the Rego rule logic, but it is only a template. To enforce the policy, you must create a Constraint resource that instantiates the template and specifies parameters (e.g., the required label). Without the Constraint, the Rego rule is never evaluated against admission requests, so pods without the label are allowed.

Answer

The Rego policy has a syntax error

Answer

Gatekeeper is not installed in the cluster

Answer

The namespace is excluded via Gatekeeper configuration

Question 12

Which kubectl command lists all MutatingWebhookConfigurations in the cluster?

Accepted Answer

kubectl get mutatingwebhookconfigurations. `kubectl get mutatingwebhookconfigurations` is the standard Kubernetes command to list all MutatingWebhookConfiguration resources. These resources are part of the admission webhook mechanism, which intercepts API requests to mutate objects before they are persisted. The resource name is case-sensitive and must match the exact API resource name `mutatingwebhookconfigurations` (or the short form `mutatingwebhookconfiguration`).

Answer

kubectl get webhooks

Answer

kubectl list webhooks

Answer

kubectl get mutating-webhooks

Question 13

A cluster has EncryptionConfiguration with aescbc provider. After rotating the encryption key, what must be done to re-encrypt existing Secrets with the new key?

Accepted Answer

Use 'kubectl get secrets --all-namespaces -o yaml | kubectl replace -f -'. After rotating the encryption key in the EncryptionConfiguration, existing Secrets are still encrypted with the old key. To re-encrypt them with the new key, you must read all Secrets and write them back using 'kubectl get secrets --all-namespaces -o yaml | kubectl replace -f -'. This triggers the API server to encrypt the data with the new key (the first provider in the list) during the write operation.

Answer

Delete and recreate all Secrets

Answer

Restart the API server

Answer

Run 'kubectl encrypt secrets --key new-key'

Question 14

Which TWO of the following are valid ways to enforce that containers cannot run as root in a Kubernetes cluster? (Select TWO.)

Accepted Answer

Create a Gatekeeper Constraint that requires runAsNonRoot. Gatekeeper, using the Open Policy Agent (OPA) framework, can enforce custom policies via ConstraintTemplates. A Constraint requiring `runAsNonRoot: true` in the Pod security context ensures containers cannot run as root, providing a flexible, admission-time control that works across all namespaces.

Answer

Use a NetworkPolicy to block root containers

Answer

Set the kubelet flag --run-non-root

Answer

Use a ServiceAccount to restrict root

Question 15

Which THREE of the following are true about Istio PeerAuthentication? (Select THREE.)

Accepted Answer

It can be used to enable mTLS for all workloads in a namespace. Istio PeerAuthentication defines the mutual TLS (mTLS) mode for traffic between services within a mesh. When applied at the namespace level, it enforces the specified mTLS mode (e.g., STRICT) for all workloads in that namespace, ensuring that all inter-service communication uses TLS certificates for identity and encryption.

Answer

It configures how traffic is routed between services

Answer

It requires a DestinationRule to define the TLS settings