CKS Minimize Microservice Vulnerabilities Practice Test 6 — 15 Questions

Question 1

Which of the following is NOT a valid method to enforce pod security standards in a Kubernetes cluster?

Accepted Answer

Using OPA/Gatekeeper with the built-in PSS templates. OPA/Gatekeeper does not have built-in Pod Security Standards (PSS) templates; it enforces custom policies defined in Rego, not the predefined PSS profiles (privileged, baseline, restricted). While Gatekeeper can be used to implement PSS-like controls, it requires writing custom constraint templates, whereas the built-in PSS templates are a feature of Pod Security Admission (PSA), not OPA/Gatekeeper. Therefore, stating that OPA/Gatekeeper uses 'built-in PSS templates' is incorrect.

Answer

Using Pod Security Policy (PSP) if still available in the cluster

Answer

Using a mutating webhook to apply security contexts

Answer

Using Pod Security Admission (PSA) with labels on namespaces

Question 2

To encrypt secrets at rest, which file must be modified on the control plane nodes?

Accepted Answer

/etc/kubernetes/manifests/kube-apiserver.yaml. To enable encryption of secrets at rest in Kubernetes, you must modify the kube-apiserver manifest file at `/etc/kubernetes/manifests/kube-apiserver.yaml` on control plane nodes. This file is a static Pod manifest that defines the API server's startup flags, including `--encryption-provider-config`, which points to an EncryptionConfiguration YAML file specifying the encryption providers (e.g., `aescbc`, `secretbox`) and keys. The API server is the component that writes and reads secrets from etcd, so it is the only place where encryption-at-rest configuration is applied.

Answer

/etc/kubernetes/scheduler.conf

Answer

/etc/kubernetes/etcd.yaml

Answer

/etc/kubernetes/kubelet.conf

Question 3

You need to ensure that all pods in a namespace can only communicate via mTLS. In Istio, which resource should you apply?

Accepted Answer

PeerAuthentication with mode: STRICT. PeerAuthentication with mode: STRICT is the correct resource to enforce mTLS for all pods in a namespace. It configures the Istio sidecar proxy to require mutual TLS for all inbound and outbound traffic within the mesh, rejecting any plaintext connections. This ensures that all inter-pod communication is encrypted and authenticated using X.509 certificates, aligning with the goal of minimizing microservice vulnerabilities.

Answer

DestinationRule with tls: ISTIO_MUTUAL

Answer

PeerAuthentication with mode: DISABLE

Answer

PeerAuthentication with mode: PERMISSIVE

Question 4

A Gatekeeper Constraint is not blocking pods that violate the policy. The constraint references a ConstraintTemplate that has been successfully created. What is the most likely cause?

Accepted Answer

The Constraint has 'enforcementAction: dryrun'. When a Gatekeeper Constraint has `enforcementAction: dryrun`, it logs violations but does not block pod creation or updates. This is the most likely cause because the constraint is correctly configured and the ConstraintTemplate exists, but the enforcement action is set to dryrun instead of the default `deny`.

Answer

The Constraint is missing the 'match' field

Answer

The Constraint is in a different namespace than the pods

Answer

The ConstraintTemplate is missing the 'violation' rule

Question 5

Which container runtime is specifically designed for sandboxing containers with a lightweight kernel?

Accepted Answer

gVisor (runsc). gVisor (runsc) is a container runtime that provides a lightweight kernel written in Go, which intercepts system calls from the container and handles them in user space. This creates a strong sandbox between the container and the host kernel, making it specifically designed for sandboxing containers with a lightweight kernel, unlike standard runtimes that share the host kernel directly.

Answer

Docker

Answer

containerd

Answer

runc

Question 6

Which TWO of the following are valid arguments for the kubectl command to create a secret from a file? (Select TWO)

Accepted Answer

--from-file. Options D and E are correct because both --from-file and --from-env-file are valid arguments for the kubectl create secret command when creating a secret from a file. --from-file reads the entire file content and uses the filename as the key. --from-env-file reads a file containing key=value lines, which is suitable for environment variable-style secrets. Option B (--from-literal) is incorrect because it specifies key-value pairs directly on the command line, not from a file. Option A (--dry-run) is a flag, not an argument for specifying secret data. Option C (--from-yaml) is not a valid argument for kubectl create secret.

Answer

--dry-run

Answer

--from-literal

Answer

--from-yaml

Question 7

Which THREE of the following are valid approaches to enforce that all pods in a cluster run with a read-only root filesystem? (Select THREE)

Accepted Answer

Deploy a ValidatingWebhookConfiguration that checks for readOnlyRootFilesystem: true. Option A is correct because a ValidatingWebhookConfiguration can intercept pod CREATE/UPDATE admission requests and reject any pod whose containers do not set securityContext.readOnlyRootFilesystem: true, thereby enforcing the requirement cluster-wide. Option C is correct because the Pod Security Admission 'restricted' profile mandates that every container sets securityContext.readOnlyRootFilesystem to true (among other hardening controls), so labeling namespaces with pod-security.kubernetes.io/enforce=restricted blocks non-compliant pods. Option D is correct because a MutatingWebhookConfiguration can patch incoming pod specs to inject readOnlyRootFilesystem: true into each container's securityContext, ensuring all admitted pods run with a read-only root filesystem. Option B is not correct because a Gatekeeper policy that drops all capabilities addresses Linux capabilities, not the read-only root filesystem setting. Option E is not correct because a NetworkPolicy only controls pod ingress/egress traffic and has no effect on container filesystem mutability.

Answer

Use a Gatekeeper policy to drop all capabilities

Answer

Apply a NetworkPolicy that denies egress

Question 8

A developer creates a Deployment with the following container spec:

```yaml
containers:
- name: app
  image: myapp:latest
  env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password
```

Which of the following is a security concern with this approach?

Accepted Answer

The secret is exposed in the container environment variables, which can be accessed via /proc or logs if the container is compromised.. Injecting secrets as environment variables exposes them in the container's process environment, which can be read from /proc/self/environ or /proc/1/environ by any process running in the container. If the container is compromised, an attacker can easily extract the secret from the environment, and it may also leak into logs or error messages. Kubernetes secrets should be mounted as files (e.g., via volumes) to reduce exposure, as environment variables are more accessible to malicious code.

Answer

The secret is not encrypted at rest in etcd.

Answer

The secret name 'db-secret' is too generic.

Answer

The secret is not base64 encoded.

Question 9

An administrator wants to use OPA Gatekeeper to enforce that all pods have a resource limits section defined. Which of the following is the correct combination to implement this policy?

Accepted Answer

Create a ConstraintTemplate with a Rego policy that checks for 'spec.containers[*].resources.limits', then create a Constraint targeting pods.. OPA Gatekeeper enforces policies via two Kubernetes custom resources: a ConstraintTemplate that contains the Rego policy logic (here, checking that every container has spec.containers[*].resources.limits), and a Constraint that instantiates the template and scopes it to specific resources (e.g., Pods). Together they register a ValidatingWebhookConfiguration behind the scenes to reject noncompliant pods.

Answer

Create a NetworkPolicy to block pods without limits.

Answer

Create a MutatingWebhookConfiguration to add resource limits automatically.

Answer

Create a ValidatingWebhookConfiguration that calls an external service to validate pod limits.

Question 10

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 11

Which kubectl command creates a secret named 'mysecret' from a file called 'credentials.json'?

Accepted Answer

kubectl create secret generic mysecret --from-file=credentials.json. `kubectl create secret generic` is the command to create a generic (opaque) secret from a file. The `--from-file` flag reads the contents of `credentials.json` and stores them as the secret's data, using the filename as the key by default. This is the standard method for injecting sensitive file-based data into a Kubernetes secret.

Answer

kubectl apply -f credentials.json

Answer

kubectl create configmap mysecret --from-file=credentials.json

Answer

kubectl create secret tls mysecret --cert=credentials.json

Question 12

A pod is configured with securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000

The volume mounted at /data is owned by user 1000 and group 2000. The container process inside the pod writes to /data. Which statement about file ownership is true?

Accepted Answer

Files created in /data will be owned by user 1000 and group 2000.. The `fsGroup: 2000` in the pod's securityContext causes Kubernetes to recursively change the group ownership of the volume to group 2000 and enable a setgid bit on the mount directory. When the container process (running as user 1000) writes new files to /data, those files inherit the group ownership of the directory (2000) due to the setgid bit, while the user ownership remains 1000 (the runAsUser). Thus, new files are owned by user 1000 and group 2000.

Answer

Files created in /data will be owned by root:root because of the volume mount.

Answer

Files created in /data will be owned by user 1000 and group 3000.

Answer

Files created in /data will be owned by user 1000 and group 1000.

Question 13

An administrator needs to encrypt secrets at rest in etcd. Which of the following steps is required?

Accepted Answer

Create an EncryptionConfiguration resource and pass it to the kube-apiserver via the --encryption-provider-config flag.. Kubernetes does not have a native `kubectl encrypt secrets` command, and etcd itself does not handle encryption configuration directly. Instead, encryption at rest is configured by creating an `EncryptionConfiguration` YAML resource that defines providers (e.g., `aescbc`, `secretbox`) and passing it to the `kube-apiserver` via the `--encryption-provider-config` flag. The API server then transparently encrypts secrets before writing them to etcd and decrypts them on read.

Answer

Use kubectl encrypt secrets command.

Answer

Modify the etcd configuration to enable encryption.

Answer

Set the environment variable ENCRYPT_SECRETS=true on all nodes.

Question 14

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 15

An administrator wants to use gVisor to sandbox containers in a Kubernetes cluster. Which resource must be created to enable this?

Accepted Answer

RuntimeClass with handler: runsc. To use gVisor as a container runtime sandbox in Kubernetes, you must create a RuntimeClass resource with the handler set to 'runsc'. This tells the kubelet which runtime handler to use when running pods that reference this RuntimeClass, enabling gVisor's user-space kernel (runsc) to intercept and sandbox system calls.

Answer

DaemonSet to install gVisor on nodes

Answer

PodSecurityPolicy with gVisor enabled

Answer

SecurityContext with runtime: gvisor