CKS Minimize Microservice Vulnerabilities Practice Test 11 — 15 Questions

Question 1

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 2

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

Question 3

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. PeerAuthentication with mode: STRICT enforces mutual TLS at the service mesh level by requiring all traffic within the namespace to use TLS certificates for both sides of the connection. This is the correct Istio resource to enforce mTLS for all services in the 'production' namespace, as it sets a namespace-wide policy that overrides any permissive defaults.

Answer

DestinationRule with trafficPolicy: tls: mode: ISTIO_MUTUAL

Answer

VirtualService with TLS settings

Answer

ServiceEntry with mTLS enabled

Question 4

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: false` in the pod spec prevents the automatic mounting of the service account token into the container's filesystem. By default, Kubernetes mounts a token at `/var/run/secrets/kubernetes.io/serviceaccount/token`, which can be read via `kubectl exec` as shown. Disabling this mount blocks direct access to the token from within the pod, mitigating the risk of token theft or misuse.

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 5

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

Accepted Answer

kubectl create secret generic my-secret --from-file=config.json. `kubectl create secret generic` with `--from-file=config.json` reads the file content and stores it as a key-value pair in the Secret, where the key defaults to the filename ('config.json') and the value is the raw file data. This is the standard method for creating a generic Secret from a file in Kubernetes.

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 6

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. In Kubernetes, to use a non-default runtime like gVisor (runsc), you must define a RuntimeClass resource that references the runtime handler (e.g., 'runsc') configured on the node. The RuntimeClass acts as a bridge between the Pod spec and the node's container runtime configuration, allowing the scheduler to select the appropriate runtime for sandboxing. Without a RuntimeClass, the default runtime (typically runc) is used, which does not provide the same isolation level.

Answer

PodSecurityPolicy

Answer

ContainerRuntime resource

Answer

Node runtime configuration only

Question 7

Which kubectl command creates a validating webhook configuration that calls an external HTTPS endpoint for pod validation?

Accepted Answer

kubectl apply -f webhook.yaml. `kubectl apply -f webhook.yaml` is the standard way to create any Kubernetes resource, including a ValidatingWebhookConfiguration, from a YAML manifest. The manifest defines the webhook's client configuration, including the external HTTPS endpoint, CA bundle, and rules for pod validation. There is no dedicated `kubectl create` subcommand for webhooks; the resource must be defined declaratively in a YAML file.

Answer

kubectl create admission webhook --validate

Answer

kubectl run webhook --image=...

Answer

kubectl create validatingwebhookconfiguration --url=https://...

Question 8

You are using External Secrets Operator to sync secrets from HashiCorp Vault. The operator is deployed but secrets are not being created. Which resource defines the mapping between Vault secrets and Kubernetes secrets?

Accepted Answer

ExternalSecret. The ExternalSecret resource is the core custom resource definition (CRD) in the External Secrets Operator (ESO) that defines the mapping between a secret stored in an external provider (like HashiCorp Vault) and a Kubernetes Secret. It specifies which remote secret path and key to fetch, and how to transform that data into the desired Kubernetes Secret object. Without an ExternalSecret, the operator has no instruction to create or sync any Kubernetes Secret.

Answer

ClusterSecretStore

Answer

VaultSecret

Answer

SecretStore

Question 9

Which TWO of the following are valid Pod Security Context settings to harden a container? (Select 2)

Accepted Answer

runAsNonRoot: true. Setting `runAsNonRoot: true` in the Pod Security Context forces the container to run with a user ID (UID) other than 0 (root). This is a fundamental hardening measure that prevents an attacker who gains code execution inside the container from having root privileges, thereby limiting the blast radius of a compromise. It is a recommended practice in the CIS Benchmark for Kubernetes and directly addresses the principle of least privilege.

Answer

privileged: true

Answer

runAsUser: 0

Answer

allowPrivilegeEscalation: true

Question 10

You need to enforce that all containers in a namespace run with a read-only root filesystem. Which OPA Gatekeeper resource would you use to define the policy?

Accepted Answer

ConstraintTemplate. A ConstraintTemplate in OPA Gatekeeper defines the reusable policy logic (Rego rules) that enforces a specific constraint, such as requiring containers to run with a read-only root filesystem. The ConstraintTemplate is then instantiated by a Constraint resource to apply the policy to a namespace. Without the ConstraintTemplate, there is no policy definition to enforce.

Answer

Constraint

Answer

ValidatingWebhookConfiguration

Answer

ConfigMap

Question 11

You are deploying an application that needs to access a database password stored in a Kubernetes Secret. To minimize risk, you should mount the Secret as a volume rather than using environment variables. Which of the following is the primary security benefit of using mounted volumes over environment variables?

Accepted Answer

Environment variables can be leaked through commands like 'env' or 'cat /proc/1/environ', while mounted files are only accessible if the container has a shell and reads the file.. Environment variables are inherited by all processes in the container and can be read via commands like `env` or by accessing `/proc/1/environ` from any process, even without a shell. In contrast, secrets mounted as volumes are only accessible to processes that explicitly read the file path, and only if the container has a shell or the process has file system access. This reduces the attack surface by limiting exposure to processes that need the secret.

Answer

Mounted volumes are not visible in /proc, making them inaccessible to other processes.

Answer

Environment variables are stored in etcd in plaintext, while volumes are encrypted at rest.

Answer

Mounted volumes automatically rotate the secret when the Secret object is updated.

Question 12

In Kubernetes, you need to enforce a default deny-all network policy for pods in a specific namespace to ensure pods cannot communicate unless explicitly allowed by policy. Which resource should you create?

Accepted Answer

NetworkPolicy. A NetworkPolicy is the Kubernetes resource that controls network traffic to and from pods. A default deny-all policy can be created by selecting all pods (e.g., using an empty podSelector) and omitting ingress/egress rules. ResourceQuota and LimitRange manage compute/resource usage, not network traffic, and RuntimeClass selects a container runtime configuration rather than enforcing network policy.

Answer

ResourceQuota

Answer

LimitRange

Answer

RuntimeClass

Question 13

You have enabled encryption at rest for Kubernetes Secrets by configuring an EncryptionConfiguration object and restarting the API server. After the configuration, you create a new Secret. However, when you retrieve the Secret using 'kubectl get secret mysecret -o yaml', the 'data' field still shows base64-encoded plaintext. Is the Secret encrypted at rest?

Accepted Answer

Yes, because encryption at rest applies to the storage layer (etcd), not the API response.. Encryption at rest in Kubernetes protects data when it is stored in etcd, the underlying key-value store. The API server decrypts the data transparently when serving it via the API, so the base64-encoded plaintext visible in `kubectl get secret -o yaml` is the decrypted output, not the raw encrypted data. The EncryptionConfiguration object ensures that new or updated Secrets are encrypted before being written to etcd, but the API response always shows the plaintext after decryption.

Answer

No, because only Secrets in namespaces with a specific annotation are encrypted.

Answer

Yes, but only if the Secret was created after the API server restart.

Answer

No, because the data is still visible in the API response.

Question 14

You want to run a workload in a sandboxed container using gVisor. You have created a RuntimeClass named 'gvisor' that references the 'runsc' handler. Which of the following Pod specs correctly uses this RuntimeClass?

Accepted Answer

apiVersion: v1
kind: Pod
metadata:
  name: sandbox-pod
spec:
  runtimeClassName: gvisor
  containers:
  - name: app
    image: nginx. The `runtimeClassName` field in the Pod spec is the standard Kubernetes API field used to specify a RuntimeClass for a Pod. The RuntimeClass named 'gvisor' must be defined in the cluster with a handler 'runsc', and setting `runtimeClassName: gvisor` in the Pod spec instructs the kubelet to use the gVisor runtime (runsc) to run the containers in a sandboxed environment, minimizing microservice vulnerabilities.

Answer

apiVersion: v1
kind: Pod
metadata:
  name: sandbox-pod
  annotations:
    runtimeClass: gvisor
spec:
  containers:
  - name: app
    image: nginx

Answer

apiVersion: v1
kind: Pod
metadata:
  name: sandbox-pod
spec:
  nodeSelector:
    runtime: gvisor
  containers:
  - name: app
    image: nginx

Answer

apiVersion: v1
kind: Pod
metadata:
  name: sandbox-pod
spec:
  runtimeClass:
    name: gvisor
  containers:
  - name: app
    image: nginx

Question 15

You have a Pod that uses a ServiceAccount token mounted via a projected volume. You want to ensure that the token has an expiration time and that the pod is not using a long-lived token. What is the most secure way to mount the token?

Accepted Answer

Use a projected volume with 'serviceAccountToken' and set 'expirationSeconds'. Using a projected volume with `serviceAccountToken` and setting `expirationSeconds` allows you to explicitly control the token's lifetime, ensuring it is short-lived and automatically rotated. This is the most secure approach as it prevents the use of long-lived tokens that could be compromised. The default service account token is a long-lived token with no expiration, which violates the principle of minimizing credential exposure.

Answer

Mount the default service account token at /var/run/secrets/kubernetes.io/serviceaccount

Answer

Set automountServiceAccountToken: false and manually mount a Secret containing a token

Answer

Use a ConfigMap to inject the token