CKS Minimize Microservice Vulnerabilities Practice Test 8 — 15 Questions

Question 1

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 2

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"] } }

Question 3

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 4

An administrator wants to prevent pods from using secrets as environment variables and enforce that secrets are only mounted as volumes. Which admission controller could be used to achieve this?

Accepted Answer

MutatingWebhookConfiguration. A MutatingWebhookConfiguration can intercept Pod creation requests and mutate them to enforce that Secrets are only mounted as volumes, not used as environment variables. This admission controller allows you to define a webhook that modifies the Pod spec before it is persisted, enabling custom validation and mutation logic beyond built-in controllers.

Answer

NetworkPolicy

Answer

PodSecurityPolicy (deprecated)

Answer

ValidatingWebhookConfiguration

Question 5

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 6

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 7

Which TWO of the following are valid methods to securely manage secrets in Kubernetes? (Select 2)

Accepted Answer

Use an external secrets manager like HashiCorp Vault with a CSI driver or operator. Using an external secrets manager like HashiCorp Vault with a CSI driver or operator allows secrets to be stored and managed outside the cluster, reducing the attack surface. The CSI driver mounts secrets as volumes directly into pods without storing them in etcd, and the operator can synchronize secrets from Vault to Kubernetes Secret objects securely. This approach follows the principle of least privilege and enables dynamic secret rotation without pod restarts.

Answer

Store secrets directly in container images as files

Answer

Store secrets in ConfigMaps

Answer

Pass secrets as environment variables from a Secret resource

Question 8

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 9

Which THREE of the following are valid ways to enforce mTLS in an Istio service mesh? (Select 3)

Accepted Answer

DestinationRule with trafficPolicy.tls.mode set to ISTIO_MUTUAL. A DestinationRule with `trafficPolicy.tls.mode` set to `ISTIO_MUTUAL` explicitly enforces mutual TLS for traffic to a specific host or subset, overriding the mesh-wide default. This ensures that both the client and server present certificates, providing strong identity-based authentication and encryption.

Answer

AuthorizationPolicy with deny rules for non-mTLS traffic

Answer

NetworkPolicy with ingress rules to allow only TLS traffic

Question 10

Which field in a PodSecurityContext ensures that the container cannot gain privileges beyond its parent process?

Accepted Answer

allowPrivilegeEscalation. `allowPrivilegeEscalation` directly controls whether a process can gain more privileges than its parent process, such as via setuid binaries or file capabilities. When set to `false` in the PodSecurityContext, it ensures that no child process can obtain elevated privileges, which is a key security control to prevent privilege escalation attacks within a container.

Answer

privileged

Answer

readOnlyRootFilesystem

Answer

runAsNonRoot

Question 11

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 12

An administrator creates a Pod with the following securityContext:
securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
The container image has a binary that requires read/write access to /data, which is an emptyDir volume mounted by the Pod. The container fails to start with 'Permission denied' when writing to /data. What is the most likely cause?

Accepted Answer

The container is running as user 1000, but the volume is owned by root (uid 0) and the fsGroup 2000 does not give write permission.. The `emptyDir` volume is created with default permissions of 755 (rwxr-xr-x), owned by root. The `fsGroup: 2000` changes the group ownership of the volume to GID 2000, but does **not** change the file permissions. User 1000 runs the container and has supplementary group 2000 from the `fsGroup` setting, so it is a member of group 2000. However, the group permission on the volume is `r-x` (read and execute only), which does **not** grant write access. As a result, writing to `/data` fails with 'Permission denied'. To fix this, the pod should either set appropriate permissions (e.g., via an init container) or adjust the `fsGroupChangePolicy` if the permissions are already correct. Option D correctly identifies this issue.

Answer

The container's base image has a restrictive umask that overrides the pod's security context.

Answer

The fsGroup is set but the volume's fsGroupChangePolicy is missing.

Answer

The emptyDir volume is not writable by default; it needs to be explicitly configured.

Question 13

In an Istio service mesh, you want to enforce mutual TLS (mTLS) between services in a specific namespace. Which resource should you create to set the default mTLS mode to STRICT for all workloads in that namespace?

Accepted Answer

PeerAuthentication. A PeerAuthentication resource in Istio defines the mutual TLS (mTLS) mode for workloads within a namespace. By setting the `mtls.mode` to `STRICT`, you enforce that all service-to-service communication in that namespace must use mTLS, rejecting any plain-text HTTP traffic. This is the correct resource for setting a namespace-wide default mTLS policy.

Answer

VirtualService

Answer

ServiceEntry

Answer

DestinationRule

Question 14

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 15

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