CKS Practice Test 37 — 15 Questions

Question 1

You need to configure a NetworkPolicy that allows egress traffic only to an external database at IP 10.0.0.5 on port 5432, and denies all other egress. Which policy BEST achieves this?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.5/32
    ports:
    - port: 5432. The correct policy uses an ipBlock with cidr 10.0.0.5/32 and port 5432, which precisely allows egress only to that single external database IP on the PostgreSQL port. Because policyTypes includes Egress and the egress rule is the only one, all other egress traffic is implicitly denied. This matches the requirement exactly.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
    ports:
    - port: 5432

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: db

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress: []

Question 2

You need to enforce that all images deployed in the cluster are signed by a trusted key. Which Kubernetes admission control mechanism would you use?

Accepted Answer

ImagePolicyWebhook. The ImagePolicyWebhook admission controller is specifically designed to enforce that container images are signed by a trusted key. It intercepts Pod creation requests and validates the image signatures against a configured webhook endpoint, rejecting unsigned or untrusted images. This directly addresses the requirement for supply chain security by ensuring only cryptographically verified images are deployed.

Answer

ResourceQuota

Answer

NetworkPolicy

Answer

PodSecurityPolicy

Question 3

A ValidatingWebhookConfiguration is not working as expected. The webhook server is running and accessible. What is a common misconfiguration that would cause the webhook to not be called?

Accepted Answer

The 'clientConfig.service.namespace' does not match the namespace of the webhook service. The ValidatingWebhookConfiguration's `clientConfig.service.namespace` field must exactly match the namespace where the webhook's Kubernetes Service object resides. If this namespace is misconfigured, the API server cannot resolve the service endpoint to call the webhook, causing the webhook to be silently skipped or fail to be invoked.

Answer

The webhook server uses HTTP instead of HTTPS

Answer

The webhook service is of type ClusterIP

Answer

The webhook server returns a 502 status code

Question 4

Which of the following is the correct command to load an AppArmor profile from a file named 'my-profile'?

Accepted Answer

apparmor_parser my-profile. The correct command to load an AppArmor profile from a file is `apparmor_parser my-profile`. The `apparmor_parser` tool is used to load, replace, or remove AppArmor profiles into the kernel. When invoked without flags, it loads the profile from the specified file into the kernel's AppArmor security module, enforcing the defined access controls.

Answer

apparmor_load my-profile

Answer

apparmor_parser -R my-profile

Answer

systemctl start apparmor my-profile

Question 5

Which TWO of the following are best practices for hardening Kubernetes Dashboard?

Accepted Answer

Grant minimal RBAC permissions to Dashboard service account. The Kubernetes Dashboard should run with the least privilege necessary. Granting minimal RBAC permissions to the Dashboard's service account follows the principle of least privilege, reducing the attack surface if the Dashboard is compromised. The default installation often creates a service account with excessive permissions, which should be scoped down to only what the Dashboard needs to function.

Answer

Use HTTP to avoid certificate management

Answer

Use the default service account with cluster-admin binding

Answer

Enable anonymous access for simplicity

Question 6

You need to enable audit logging for the Kubernetes API server. Which two flags must be set?

Accepted Answer

--audit-log-path and --audit-policy-file. To enable audit logging in the Kubernetes API server, you must specify both an audit policy file (using --audit-policy-file) to define which events should be logged and at what level, and a log file path (using --audit-log-path) to specify where the audit logs should be written. Without the policy file, the API server does not know which requests to audit; without the log path, the audit events have no output destination.

Answer

--audit-log-path and --audit-log-maxage

Answer

--audit-policy-file and --audit-log-maxbackup

Answer

--audit-log-path and --authorization-mode=RBAC

Question 7

Which kubectl command checks the CIS Benchmark compliance of a cluster node using the kube-bench tool?

Accepted Answer

kubectl apply -f job.yaml. Kube-bench runs as a Kubernetes Job, and the standard way to execute it against a cluster node is to apply a Job YAML manifest that runs the aquasec/kube-bench image. This Job performs CIS Benchmark checks on the node where it is scheduled, and the results are output to the Job's logs. The `kubectl apply -f job.yaml` command deploys the pre-configured Job, which is the recommended method for running kube-bench in a cluster context.

Answer

kubectl kube-bench

Answer

kubectl run kube-bench --image=aquasec/kube-bench

Answer

kube-bench run --targets=node

Question 8

You need to restrict access to etcd so that only the API server can communicate with it. Which method should you use?

Accepted Answer

Configure etcd with TLS client certificates and require authentication. Etcd supports mutual TLS (mTLS) authentication, which requires clients to present a valid TLS certificate signed by a trusted CA. By configuring etcd with `--client-cert-auth=true` and providing the API server's client certificate, you ensure that only the API server (or any client with a valid certificate) can communicate with etcd. This is the recommended Kubernetes approach to restrict access to etcd, as it cryptographically verifies the identity of the client.

Answer

Set the etcd flag --peer-auto-tls=true

Answer

Configure etcd to use RBAC with a role that allows only the API server

Answer

Use a firewall rule to restrict access to etcd's port from the API server's IP

Question 9

Which YAML field in a Deployment specifies the container user should not run as root?

Accepted Answer

spec.containers[].securityContext.runAsNonRoot. `spec.containers[].securityContext.runAsNonRoot: true` explicitly enforces that the container's user ID is non-zero, preventing the container from running as root. This is a key Pod Security Standard (PSS) control for the 'Restricted' profile, ensuring compliance with the principle of least privilege. The field rejects the container if the user is set to root (UID 0) or if no user is specified and the image defaults to root.

Answer

spec.containers[].securityContext.readOnlyRootFilesystem

Answer

spec.containers[].securityContext.runAsUser: 0

Answer

spec.containers[].securityContext.allowPrivilegeEscalation

Question 10

An administrator discovers that a container has been running with root privileges despite a PodSecurityPolicy that should prevent it. What is the most likely cause?

Accepted Answer

The PodSecurityPolicy admission controller is not enabled in the kube-apiserver.. The PodSecurityPolicy (PSP) admission controller must be explicitly enabled in the kube-apiserver's `--enable-admission-plugins` flag. Without it, PSP resources are stored in etcd but never enforced, allowing any pod to run with root privileges regardless of PSP definitions.

Answer

The PodSecurityPolicy is applied in the wrong order and a less restrictive policy overrides it.

Answer

The pod's service account lacks RBAC permissions to use the PSP.

Answer

The PodSecurityPolicy resource is misconfigured with an empty allowPrivilegeEscalation field.

Question 11

A security team wants to ensure that only approved container images can run in their production cluster. Which admission controller should be configured in the kube-apiserver to enforce this policy?

Accepted Answer

ImagePolicyWebhook. The ImagePolicyWebhook admission controller allows a cluster to enforce a policy that only approved container images can run by sending image admission requests to an external webhook backend. This webhook can validate images against an allowlist, a trusted registry, or a custom policy engine, and it returns an admission decision (allow or deny) before the pod is created. This directly meets the requirement of restricting which container images are permitted in the cluster.

Answer

PodSecurityPolicy

Answer

AlwaysPullImages

Answer

NodeRestriction

Question 12

A security team wants to detect any attempt to read the /etc/shadow file inside a container. Which Falco rule condition would trigger an alert for such an event?

Accepted Answer

evt.type=open and fd.name=/etc/shadow and evt.arg.flags contains O_RDONLY. Reading /etc/shadow requires the open syscall with the O_RDONLY flag. Falco's rule condition `evt.type=open and fd.name=/etc/shadow and evt.arg.flags contains O_RDONLY` precisely matches an attempt to open the file for reading, which is the event that should trigger an alert for unauthorized read access.

Answer

evt.type=open and proc.name=bash and fd.name=/etc/shadow

Answer

evt.type=open and fd.name contains /etc

Answer

evt.type=open and fd.name=/etc/shadow and evt.arg.flags contains O_WRONLY

Question 13

Which THREE of the following are valid ways to restrict access to etcd? (Select 3)

Accepted Answer

Enable etcd RBAC to restrict read/write access. Etcd supports Role-Based Access Control (RBAC) that allows you to define roles and permissions to restrict read and write access to keys. By enabling etcd RBAC, you can enforce fine-grained authorization, ensuring that only authenticated and authorized clients (e.g., the Kubernetes API server) can perform specific operations on etcd data.

Answer

Use HTTP instead of HTTPS

Answer

Disable client authentication for simplicity

Question 14

An administrator wants to enforce a custom AppArmor profile named 'k8s-apparmor-example' on a pod. The profile has been loaded on the node. Which annotation should be added to the pod's metadata to apply this profile?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/nginx: localhost/k8s-apparmor-example. The annotation format for applying an AppArmor profile to a container in a pod is `container.apparmor.security.beta.kubernetes.io/<container_name>`. The value `localhost/k8s-apparmor-example` specifies that the profile named `k8s-apparmor-example` is loaded locally on the node. This annotation enforces the profile on the container named 'nginx'.

Answer

container.apparmor.security.beta.kubernetes.io/pod: localhost/k8s-apparmor-example

Answer

apparmor.security.beta.kubernetes.io/pod: k8s-apparmor-example

Answer

container.apparmor.security.beta.kubernetes.io/nginx: k8s-apparmor-example

Question 15

Which THREE are valid methods to enforce that only images from a specific registry can be deployed in a Kubernetes cluster? (Select three.)

Accepted Answer

ImagePolicyWebhook admission controller. Option B (ImagePolicyWebhook admission controller) is correct because it is a built-in Kubernetes admission controller that calls an external HTTP webhook during admission to approve or reject a Pod based on its container image, so the webhook can enforce that images originate only from an allowed registry. Option C (Kyverno policy validating image registry) is correct because Kyverno is a Kubernetes-native admission policy engine whose validating policies can match on Pod specs and deny any container whose image field does not reference the approved registry. Option D (OPA/Gatekeeper constraint to validate registry) is correct because Gatekeeper runs OPA as a validating admission webhook and its ConstraintTemplates/Constraints (e.g., using Rego on input.review.object.spec.containers[_].image) can reject workloads that pull from unapproved registries. Option A (PodSecurityPolicy) is not correct because PSP only governed pod security attributes such as privileged mode, host namespaces, and volume types, not image registry provenance. Option E (NetworkPolicy) is not correct because it only controls L3/L4 network traffic (e.g., egress to registry IPs/ports) and cannot inspect or validate the image reference used in a Pod specification.

Answer

PodSecurityPolicy (PSP)

Answer

NetworkPolicy to restrict egress to registries