CKS Practice Test 17 — 15 Questions

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

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 2

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 3

Which flag enables the NodeRestriction admission plugin on the API server?

Accepted Answer

--enable-admission-plugins=NodeRestriction. The `--enable-admission-plugins` flag is the correct parameter to activate admission controllers in the kube-apiserver. The NodeRestriction plugin limits the Node and Pod objects a kubelet can modify, enforcing the principle of least privilege. Option A correctly uses this flag with the plugin name.

Answer

--admission-control=NodeRestriction

Answer

--kubelet-restriction=NodeRestriction

Answer

--node-restriction=true

Question 4

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 5

A cluster uses Kubernetes v1.24 with Pod Security Admission enabled. The cluster administrator wants to enforce that all pods in the 'production' namespace run with the 'restricted' policy level, but some existing deployments use privileged containers. Which approach ensures that only new pods violating the policy are rejected, while existing pods continue to run?

Accepted Answer

Add the namespace label 'pod-security.kubernetes.io/enforce=restricted' and leave existing pods unchanged; new pods violating the policy will be rejected.. Pod Security Admission (PSA) in Kubernetes v1.24 enforces policies via namespace labels. Setting `pod-security.kubernetes.io/enforce=restricted` on the 'production' namespace will reject any new pod that violates the restricted policy, but existing pods are not re-evaluated and continue running. This behavior is by design: PSA evaluates pods at creation or update time, not retroactively, so existing workloads are unaffected.

Answer

Patch existing deployments to remove privileged containers, then add the label 'pod-security.kubernetes.io/enforce=restricted' to the namespace.

Answer

Create a PodSecurityPolicy that restricts privileged containers and bind it to all service accounts in the namespace.

Answer

Set the namespace label 'pod-security.kubernetes.io/enforce=restricted' and use the 'inform' mode to allow existing pods.

Question 6

You have a Kyverno policy that validates image registries. The policy should allow only images from `myregistry.example.com`. Which Kyverno rule field should be used to check the image registry?

Accepted Answer

imageRegistry. The `imageRegistry` field in a Kyverno policy rule is specifically designed to validate image registries by matching the registry hostname against a pattern. In this case, setting `imageRegistry: "myregistry.example.com/*"` ensures only images from that registry are allowed, blocking others at admission time.

Answer

mutate

Answer

resources

Answer

generate

Question 7

You are asked to ensure that a specific Kubernetes dashboard (e.g., kubernetes-dashboard) is not publicly accessible. The dashboard is deployed in the 'kube-system' namespace. Which NetworkPolicy should you apply?

Accepted Answer

NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Ingress], ingress: []. A NetworkPolicy with an empty `ingress` array (i.e., `ingress: []`) explicitly denies all inbound traffic to the selected pods. This ensures that the kubernetes-dashboard pod in the kube-system namespace is not publicly accessible, as no ingress rules are defined to allow any source. By default, if no NetworkPolicy selects a pod, all traffic is allowed; applying this policy changes the default to deny for ingress.

Answer

NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Ingress], ingress: [{from: [{namespaceSelector: {matchLabels: {}}}]}]

Answer

NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Ingress], ingress: [{from: [{podSelector: {matchLabels: {app: kubernetes-dashboard}}}]}]

Answer

NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Egress], egress: [{to: [{podSelector: {}}]}]

Question 8

You are tasked with securing a Kubernetes cluster. You want to ensure that the kubelet only serves APIs that are explicitly allowed and that it does not allow anonymous requests. Which kubelet configuration flags should you set?

Accepted Answer

--anonymous-auth=false and --authorization-mode=Webhook. Setting `--anonymous-auth=false` disables anonymous requests to the kubelet, and `--authorization-mode=Webhook` delegates authorization decisions to an external service (e.g., the API server), allowing fine-grained control over which APIs the kubelet serves. This combination ensures that only authenticated, authorized requests are processed, aligning with the principle of least privilege.

Answer

--anonymous-auth=false and --authorization-mode=RBAC

Answer

--anonymous-auth=true and --authorization-mode=ABAC

Answer

--anonymous-auth=false and --authorization-mode=AlwaysAllow

Question 9

An administrator wants to prevent the kubelet from serving anonymous requests. Which flag should be set on the kubelet?

Accepted Answer

--anonymous-auth=false. The `--anonymous-auth=false` flag explicitly disables anonymous authentication on the kubelet, preventing unauthenticated requests from being processed. By default, anonymous authentication is enabled (`--anonymous-auth=true`), which allows any unauthenticated user to make requests to the kubelet API. Setting this flag to `false` ensures that only authenticated clients can interact with the kubelet, directly addressing the requirement to block anonymous requests.

Answer

--client-ca-file=/etc/kubernetes/pki/ca.crt

Answer

--authorization-mode=Webhook

Answer

--authentication-token-webhook=true

Question 10

A security policy requires that all container images must be signed using Cosign. Which admission controller enforces signature verification at pod creation time?

Accepted Answer

ImagePolicyWebhook. The ImagePolicyWebhook admission controller is the correct choice because it is specifically designed to enforce image signature verification at pod creation time. It intercepts pod creation requests and queries an external webhook (e.g., a Cosign-based policy engine) to validate that the container image has a valid cryptographic signature before allowing the pod to be admitted. This directly meets the requirement for Cosign-based signature enforcement.

Answer

MutatingAdmissionWebhook

Answer

ValidatingAdmissionWebhook

Answer

ResourceQuota

Question 11

An admin runs 'kubectl describe pod secure-pod' and sees 'seccompProfile: RuntimeDefault' under the container's security context. Which seccomp profile is being used?

Accepted Answer

The container runtime's default seccomp profile is applied. When `seccompProfile` is set to `RuntimeDefault` in a container's security context, Kubernetes instructs the container runtime (e.g., containerd, CRI-O) to apply its own default seccomp profile. This profile is typically a restrictive set of syscalls that blocks dangerous or unnecessary system calls while allowing common operations. It is not a custom profile from the node's filesystem, nor does it disable seccomp or set it to unconfined.

Answer

A custom seccomp profile from '/var/lib/kubelet/seccomp/' is used

Answer

The container runtime's seccomp profile is set to 'Unconfined'

Answer

Seccomp is disabled for this container

Question 12

An admin runs 'crictl ps' on a node and sees multiple containers. Which command should they use to view the logs of a specific container?

Accepted Answer

crictl logs <container-id>. `crictl logs` is the dedicated command to retrieve container logs from the container runtime interface (CRI), fetching stdout and stderr output from the specified container, which is essential for debugging and monitoring containerized workloads on a Kubernetes node.

Answer

crictl exec <container-id> logs

Answer

crictl inspect <container-id>

Answer

crictl ps -a <container-id>

Question 13

Which stage of the Kubernetes API request processing should be audited to capture the final response sent to the client?

Accepted Answer

ResponseComplete. The `ResponseComplete` stage in Kubernetes audit logging captures the moment when the complete HTTP response has been sent to the client. This stage includes the final response body, headers, and status code, providing a full record of what the client actually received. Auditing at this stage is essential for compliance and forensic analysis, as it logs the definitive outcome of the API request.

Answer

ResponseStarted

Answer

Panic

Answer

RequestReceived

Question 14

Which flag must be set on the API server to enable audit logging?

Accepted Answer

--audit-log-path=/var/log/audit.log. The `--audit-log-path` flag is the mandatory parameter that enables audit logging in the kube-apiserver. Without specifying a file path for the audit log, the API server will not write any audit events, even if other audit-related flags are set. This flag tells the API server where to persist the audit log entries, effectively activating the audit logging feature.

Answer

--audit-log-maxage=30

Answer

--audit-log-format=json

Answer

--audit-policy-file=/etc/kubernetes/audit-policy.yaml

Question 15

An administrator runs 'kube-bench run --targets=master' and sees a failing check for 'Ensure that the --audit-log-path argument is set'. What is the correct remediation?

Accepted Answer

Add '--audit-log-path=/var/log/audit.log' to the kube-apiserver. The kube-bench check for 'Ensure that the --audit-log-path argument is set' specifically targets the kube-apiserver component, as it is the primary component that handles API requests and should log them for audit purposes. The correct remediation is to add '--audit-log-path=/var/log/audit.log' to the kube-apiserver's startup arguments, which enables writing audit logs to a specified file path. This ensures that all API server requests are recorded for security monitoring and compliance.

Answer

Add '--audit-policy-file=/etc/kubernetes/audit-policy.yaml' to the API server

Answer

Add '--audit-log-path=/var/log/audit.log' to the kube-controller-manager

Answer

Add '--audit-log-maxsize=100' to the API server