CKS Timed Hard Questions — 25 Difficult Questions

Question 1

You need to detect any unexpected outbound connections from pods in the 'production' namespace. Which Falco rule condition is MOST appropriate?

Accepted Answer

evt.type=connect and container.id != host and not fd.snet in ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8"). It uses the `connect` syscall to detect outbound connection attempts from containers (excluding the host) and filters out private IP ranges (RFC 1918 and loopback) to flag only unexpected external destinations. This directly matches the requirement to detect unexpected outbound connections from pods in the 'production' namespace.

Answer

evt.type=sendto and fd.sip != "0.0.0.0"

Answer

container.id != host and evt.type=accept

Answer

proc.name = curl and evt.type=connect

Question 2

After setting up etcd encryption at rest using EncryptionConfiguration with aescbc, which resource stores the encryption key?

Accepted Answer

The EncryptionConfiguration file itself. When etcd encryption at rest is configured via an EncryptionConfiguration file, the encryption key is defined within that file itself under the 'keys' field for the specified provider (e.g., aescbc). The EncryptionConfiguration file is passed to the kube-apiserver via the --encryption-provider-config flag, and the key material is read from this file at startup. No separate Secret or ConfigMap stores the key; the file is the authoritative source.

Answer

A ConfigMap in the etcd namespace

Answer

A Secret in the kube-system namespace

Answer

An annotation on the etcd pod

Question 3

You have configured Kyverno to enforce that all Pods must have an image from a trusted registry. However, a newly created Pod is not being rejected even though it uses an untrusted image. What is the most likely reason?

Accepted Answer

The Kyverno webhook is not invoked because the failure policy is set to Ignore or the resource is not matched by the policy's rules. Kyverno operates as a dynamic admission controller via a MutatingAdmissionWebhook or ValidatingAdmissionWebhook. If the webhook's failure policy is set to `Ignore`, the webhook will not block the Pod creation when it fails to invoke, and the Pod will be admitted. Additionally, if the policy's rules do not match the Pod (e.g., due to incorrect resource selection or namespace exclusion), the webhook will not be triggered, allowing untrusted images through.

Answer

Kyverno is not an admission controller; it only mutates resources

Answer

The Kyverno policy requires an external registry to compare images, which is unavailable

Answer

The Pod was created by a Deployment controller, which bypasses admission control

Question 4

Which THREE of the following are valid methods to restrict access to the Kubernetes Dashboard? (Choose three.)

Accepted Answer

Use a ClusterIP service and only allow access via kubectl proxy. Using a ClusterIP service restricts the Dashboard to internal cluster access only. Access is then granted exclusively through `kubectl proxy`, which creates a local proxy server that authenticates the user via their kubeconfig context, ensuring that only authenticated and authorized users can reach the Dashboard without exposing it to the network.

Answer

Expose the Dashboard via a NodePort service to the internet

Answer

Deploy the Dashboard with a hostNetwork: true configuration

Question 5

Developer A runs 'cosign verify --key cosign.pub myregistry/myimage:tag' and receives an error: 'No signatures found'. Developer B previously ran 'cosign sign --key cosign.key myregistry/myimage:tag'. What is the most likely cause of the verification failure?

Accepted Answer

The signing command failed to push the signature to the registry. The error 'No signatures found' indicates that the verification process could not locate any signature associated with the image in the registry. Since Developer B attempted to sign the image with 'cosign sign', the most likely cause is that the signing command failed to push the signature artifact (typically stored as a separate tag like 'myimage:sha256-<digest>.sig' in the same registry) to the registry. Without the signature being successfully uploaded, the 'cosign verify' command finds nothing to validate against the provided public key.

Answer

The image tag does not exist in the registry

Answer

Developer B used a different private key to sign than the public key used for verification

Answer

Developer A used the public key instead of the private key

Question 6

An etcd cluster is configured with TLS. You need to enforce that only the API server can read and write to etcd. Which method should you use?

Accepted Answer

Configure etcd RBAC with a role that grants readwrite access only to the API server's client certificate CN. Etcd supports Role-Based Access Control (RBAC) that can restrict access based on the Common Name (CN) in the client certificate. By creating a role with readwrite access and binding it only to the API server's client certificate CN, you ensure that only the API server can read and write to etcd, while other clients are denied.

Answer

Set etcd's --peer-client-cert-auth flag to true

Answer

Set etcd's --client-cert-auth flag to false

Answer

Use a NetworkPolicy to restrict access to etcd port 2379

Question 7

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 8

A cluster has been compromised due to a container running with privileged escalation. The team wants to prevent any container from gaining new privileges. Which configuration should be applied?

Accepted Answer

Set securityContext.allowPrivilegeEscalation: false. Setting `securityContext.allowPrivilegeEscalation: false` directly prevents a container from gaining new privileges beyond those it was initially granted, such as through setuid binaries or the `NO_NEW_PRIVS` flag. This is the exact control needed to block privilege escalation attacks, as it forces the kernel to deny any request for elevated privileges, even if the binary has the setuid bit set.

Answer

Set securityContext.runAsUser: 1000

Answer

Set securityContext.readOnlyRootFilesystem: true

Answer

Drop all capabilities with securityContext.capabilities.drop: ["ALL"]

Question 9

A pod in namespace 'ns1' has automountServiceAccountToken: false. However, the container still has a mounted service account token at /var/run/secrets/kubernetes.io/serviceaccount. What is the most likely cause?

Accepted Answer

The automountServiceAccountToken field is set in the container spec instead of the pod spec. The `automountServiceAccountToken` field is a pod-level setting. If it is set to `false` in the pod spec, the kubelet will not automatically mount the service account token. However, if the field is mistakenly set inside a container spec (which is not a valid field for containers), the pod-level setting is ignored, and the default behavior (mounting the token) applies. This is why the token still appears mounted despite the intention to disable it.

Answer

The kubelet is configured to always mount tokens

Answer

The namespace has a default automountServiceAccountToken: true

Answer

The pod is using a custom service account with automountServiceAccountToken: true

Question 10

You are deploying a ValidatingWebhookConfiguration. The webhook server is running in the 'webhook' namespace, service name 'svc', port 443. Which clientConfig should you specify?

Accepted Answer

clientConfig:
  service:
    namespace: webhook
    name: svc
    path: /validate. A ValidatingWebhookConfiguration's clientConfig must reference the Kubernetes service that fronts the webhook server, specifying the service's namespace, name, and the path to the validation endpoint. Since the webhook server runs in the 'webhook' namespace with service name 'svc' on port 443, the service reference must use namespace: webhook and name: svc, with path: /validate. Kubernetes automatically resolves the service to its cluster-internal DNS name and uses the service's HTTPS port (443) when a service reference is provided.

Answer

clientConfig:
  url: https://webhook.svc.cluster.local:443/validate

Answer

clientConfig:
  service:
    namespace: webhook
    name: webhook
    path: /validate

Answer

clientConfig:
  service:
    namespace: default
    name: svc
    path: /validate

Question 11

A security scanner reports that the Kubernetes dashboard is publicly accessible. Which recommended action should be taken?

Accepted Answer

Delete the dashboard deployment and use kubectl proxy to access it. The Kubernetes Dashboard is a powerful administrative tool that should never be exposed to the public internet. Deleting the dashboard deployment and using `kubectl proxy` to access it locally is the recommended action because it eliminates the attack surface entirely and ensures that access is restricted to the machine running the kubectl command, leveraging the API server's built-in authentication and authorization.

Answer

Expose the dashboard as a NodePort service for easy access

Answer

Configure firewall rules to restrict access to the dashboard's ClusterIP

Answer

Enable authentication on the dashboard

Question 12

A security auditor wants to ensure that no container in the cluster has the CAP_SYS_ADMIN capability. Which of the following is the most effective way to enforce this cluster-wide?

Accepted Answer

Implement a mutating admission webhook that automatically drops CAP_SYS_ADMIN from all pods. A mutating admission webhook intercepts Pod creation requests and can automatically modify the pod spec to drop CAP_SYS_ADMIN before the pod is persisted. This approach works cluster-wide, is not deprecated like PodSecurityPolicy, and does not require modifying node-level components or relying on namespace-level enforcement that only warns or rejects but does not automatically drop capabilities.

Answer

Add a PodSecurityPolicy that drops CAP_SYS_ADMIN

Answer

Modify the kubelet to disallow CAP_SYS_ADMIN

Answer

Configure each namespace with 'pod-security.kubernetes.io/enforce: restricted'

Question 13

A pod is scheduled on a node that has the AppArmor profile 'my-profile' loaded in complain mode. The pod annotation specifies 'localhost/my-profile' but the container is running without the profile being enforced. What is the most likely cause?

Accepted Answer

The profile is in complain mode, not enforce mode. AppArmor profiles can operate in either 'enforce' or 'complain' mode. When a profile is loaded in complain mode, violations are logged but not blocked, so the container runs without enforcement. The pod annotation 'localhost/my-profile' correctly references the profile, but the profile itself is not set to enforce mode, which is why the container is running without the profile being enforced.

Answer

The pod must run as privileged to use AppArmor

Answer

The annotation is missing the 'localhost/' prefix

Answer

The profile is not loaded on the node

Question 14

A ClusterRoleBinding grants cluster-admin to a service account in the 'kube-system' namespace. What is the best way to audit this for least privilege?

Accepted Answer

Review the permissions granted by cluster-admin and create a custom Role with only necessary permissions, then bind it.. The cluster-admin ClusterRole grants superuser access across all namespaces, which violates the principle of least privilege. The best practice is to review the specific permissions required by the service account, create a custom Role with only those necessary permissions, and bind it via a RoleBinding or ClusterRoleBinding scoped appropriately. This minimizes the attack surface and aligns with Kubernetes RBAC hardening guidelines.

Answer

Use 'kubectl auth can-i --list' to check the service account's permissions.

Answer

Delete the ClusterRoleBinding immediately.

Answer

Run 'kubectl get clusterrolebindings' to list all bindings.

Question 15

You are a platform engineer at a financial services company. The production cluster runs a set of microservices that handle sensitive customer data. The cluster has been configured with Pod Security Standards (PSS) enforced via OPA/Gatekeeper. Recently, the security team identified that a new deployment of the `payment-processing` microservice is running with the `seccomp` profile set to `Unconfined`. This violates the company policy that requires all containers to use a runtime default seccomp profile. The deployment YAML does not explicitly set any security context for seccomp. The cluster's nodes are running containerd 1.6 with default seccomp profile enabled. The OPA constraint template checks that `securityContext.seccompProfile.type` is set to `RuntimeDefault` or `Localhost`. However, the deployment passes the OPA validation. What is the most likely reason the deployment is not being rejected by OPA, and how should you fix it?

Accepted Answer

The OPA constraint only checks pod-level `securityContext`, but the deployment uses container-level settings.. The OPA constraint template checks `securityContext.seccompProfile.type` at the pod level, but the deployment does not set any security context at the pod level. The seccomp profile is only set at the container level (or defaults to `Unconfined` by the runtime), and the OPA constraint does not inspect container-level `securityContext`. This mismatch allows the deployment to pass validation even though the container is running with an unconfined seccomp profile.

Answer

The seccomp profile must be set via an admission controller, not OPA.

Answer

OPA/Gatekeeper is not properly installed or the constraint is not active.

Answer

The cluster's nodes do not support seccomp, so the profile is ignored.

Question 16

You want to allow only images from a specific registry (e.g., myregistry.io) to be deployed in your cluster. Which tool or approach is best suited for this requirement?

Accepted Answer

Use OPA/Gatekeeper to create a constraint that checks the image registry. OPA/Gatekeeper allows you to define a ConstraintTemplate and a Constraint that validates the image registry in pod specs via a Rego rule. This approach enforces admission control at the API server level, rejecting any pod that references an image from an unauthorized registry before it is persisted in etcd.

Answer

Set up a NetworkPolicy to block traffic from other registries

Answer

Configure an ImagePolicyWebhook

Answer

Modify the kubelet configuration to only pull from a specific registry

Question 17

Which THREE of the following are recommended practices for minimizing microservice vulnerabilities related to container security?

Accepted Answer

Set securityContext.runAsNonRoot: true. Setting `securityContext.runAsNonRoot: true` forces the container to run with a user ID (UID) other than 0 (root). This is a critical defense-in-depth measure because if an attacker exploits a vulnerability in the application or runtime, they will not gain root privileges on the host, limiting the blast radius. It enforces the principle of least privilege at the container level, and Kubernetes will reject the pod if the container image attempts to run as root.

Answer

Set high CPU requests to ensure performance

Answer

Expose secrets as environment variables for convenience

Question 18

An admin has created an EncryptionConfiguration to encrypt secrets at rest in etcd. After applying the configuration and restarting the kube-apiserver, existing secrets are still stored in plaintext. What is the most likely reason?

Accepted Answer

Existing secrets are not automatically encrypted; they need to be rewritten by reading and writing them back. Kubernetes does not automatically encrypt existing secrets stored in etcd when an EncryptionConfiguration is applied. The encryption configuration only affects data written after the kube-apiserver is restarted; previously stored secrets remain in plaintext until they are read and rewritten (e.g., by running `kubectl get secret <name> -o yaml | kubectl replace -f -`). This behavior is by design, as the API server encrypts data on write, not retroactively.

Answer

The encryption provider is set to 'identity' which does not encrypt

Answer

The kube-apiserver was not restarted after applying the configuration

Answer

The EncryptionConfiguration has a syntax error that caused it to be ignored

Question 19

An etcd cluster uses TLS for peer and client communication. Which command correctly tests connectivity to an etcd member with client certificate authentication?

Accepted Answer

etcdctl --endpoints=https://10.0.0.1:2379 --cacert=/etc/etcd/ca.crt --cert=/etc/etcd/etcd-client.crt --key=/etc/etcd/etcd-client.key endpoint health. It provides all three required TLS components for mutual TLS (mTLS) authentication: the CA certificate (`--cacert`) to verify the server's identity, the client certificate (`--cert`) for the client's identity, and the client key (`--key`) to prove possession of the private key. The `endpoint health` command then performs a TLS handshake and checks the etcd member's health over HTTPS. Without any of these three, the connection will fail due to certificate validation errors or missing client authentication.

Answer

etcdctl --endpoints=https://10.0.0.1:2379 --cert=/etc/etcd/etcd-client.crt endpoint health

Answer

etcdctl --endpoints=https://10.0.0.1:2379 --cacert=/etc/etcd/ca.crt endpoint health

Answer

etcdctl --endpoints=http://10.0.0.1:2379 endpoint health

Question 20

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.