CKS Cluster Setup and Hardening Practice Test 1 — 15 Questions

Question 1

During a security audit, you discover that a container running as root inside a pod has been compromised. The pod uses the default service account. Which two measures should you implement to harden the cluster? (Select TWO)

Accepted Answer

Edit the default service account to set automountServiceAccountToken: false.. Option C is correct because setting `automountServiceAccountToken: false` on the default service account prevents any pod that uses it from automatically mounting the service account token. This reduces the attack surface: if a container is compromised, the attacker cannot use the token to authenticate to the Kubernetes API server. This is a fundamental hardening measure for service accounts that do not require API access.

Answer

Apply a PodSecurityPolicy that restricts containers from running as root.

Answer

Create a new service account with no roles bound and assign it to the pod.

Answer

Set automountServiceAccountToken: false in the pod spec.

Question 2

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.. Option B is correct because 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 3

A security engineer needs to ensure that all communication between nodes and the control plane is encrypted. Which component must be configured with a TLS certificate to achieve this?

Accepted Answer

kube-apiserver. The kube-apiserver is the central gateway for all cluster operations, and it must be configured with a TLS certificate to encrypt communication between nodes (kubelets) and the control plane. The kube-apiserver presents this certificate to authenticate itself and establish encrypted HTTPS connections, ensuring that all traffic from node components (e.g., kubelets, kube-proxy) and other control plane components is secured in transit.

Answer

kube-proxy

Answer

etcd

Answer

kube-scheduler

Question 4

After a security incident, you need to restrict which pods can communicate with each other in the 'finance' namespace. You want to allow only pods with label 'app: api' to connect to pods with label 'app: db' on TCP port 5432, and deny all other traffic. Which NetworkPolicy should you create?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: finance
spec:
  podSelector:
    matchLabels:
      app: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api
    ports:
    - port: 5432. Option D is correct because it defines a NetworkPolicy that selects pods with label 'app: db' as the target and allows ingress traffic only from pods with label 'app: api' on TCP port 5432. By default, if no NetworkPolicy exists, all traffic is allowed; once a NetworkPolicy selects a pod, all traffic not explicitly allowed is denied. This policy therefore restricts communication to only the intended api-to-db flow on the specified port.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: finance
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: db
    ports:
    - port: 5432

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: finance
spec:
  podSelector:
    matchLabels:
      app: api
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: db
    ports:
    - port: 5432

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: finance
spec:
  podSelector:
    matchLabels:
      app: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api

Question 5

A cluster has been configured with the NodeRestriction admission plugin. A developer tries to create a pod that uses a hostPath volume pointing to /var/log. The pod's nodeSelector is set to 'kubernetes.io/hostname: worker-1'. Which statement is true?

Accepted Answer

The pod will be created because NodeRestriction does not restrict hostPath volumes.. The NodeRestriction admission plugin limits the node labels that a kubelet can set and restricts pods from modifying their node affinity to gain access to node-specific resources. However, it does not restrict the use of hostPath volumes. Therefore, a pod with a hostPath volume pointing to /var/log and a nodeSelector for 'worker-1' will be created, as long as the nodeSelector matches an existing node label and the hostPath volume is otherwise permitted by the PodSecurityPolicy or other security contexts.

Answer

The pod will be created only if the node label matches the nodeSelector; the hostPath volume is irrelevant.

Answer

The pod will be rejected because hostPath volumes are not allowed by NodeRestriction.

Answer

The pod will be rejected because the nodeSelector conflicts with the NodeRestriction plugin.

Question 6

Which THREE of the following are valid methods to secure etcd in a Kubernetes cluster? (Select THREE)

Accepted Answer

Use RBAC to restrict access to etcd.. RBAC is a valid method to secure etcd because etcd supports role-based access control for its API, allowing you to define roles and permissions that restrict which users or processes can read or write keys. By enabling RBAC on etcd, you can limit access to sensitive cluster data, such as secrets and configuration, to only authorized components like the Kubernetes API server.

Answer

Apply a NetworkPolicy to block traffic to etcd pods.

Answer

Expose the etcd client port (2379) to the public internet for monitoring.

Question 7

Which TWO of the following are recommended practices for securing the Kubernetes API server? (Select TWO)

Accepted Answer

Enable audit logging.. Option C is correct because enabling audit logging on the API server records all requests to the cluster, providing an immutable record for security monitoring, incident response, and compliance. Audit logs are essential for detecting unauthorized access attempts, misconfigurations, and policy violations, and are a core requirement for Kubernetes security hardening.

Answer

Set --cors-allowed-origins=* for easy access.

Answer

Disable TLS to improve performance.

Answer

Set --insecure-port=8080 to allow non-TLS access.

Question 8

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 9

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.. Option C is correct because 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 10

A DevOps engineer needs to restrict the outbound network traffic from pods running in namespace 'secure-ns'. Which NetworkPolicy configuration achieves this by default?

Accepted Answer

Apply a NetworkPolicy that selects pods in 'secure-ns' and has an empty egress section.. By default, Kubernetes NetworkPolicies are additive and deny-all unless explicitly allowed. Applying a NetworkPolicy with an empty egress section (no egress rules) to pods in 'secure-ns' effectively denies all outbound traffic from those pods, because the policy's egress field defaults to an empty list, which matches no traffic. This is the standard Kubernetes behavior for restricting egress.

Answer

Apply a NetworkPolicy that selects pods in 'secure-ns' and has an egress rule allowing all traffic.

Answer

No NetworkPolicy is needed because egress is denied by default.

Answer

Apply a NetworkPolicy that selects pods in 'secure-ns' and has an egress rule allowing traffic to port 53.

Question 11

Which TWO of the following are valid methods to secure the etcd datastore in a Kubernetes cluster?

Accepted Answer

Enable TLS encryption for client-to-server communication.. Option A is correct because enabling TLS encryption for client-to-server communication ensures that all data transmitted between etcd clients (such as the Kubernetes API server) and the etcd server is encrypted, preventing eavesdropping and man-in-the-middle attacks. This is a fundamental security measure for protecting sensitive cluster state and secrets stored in etcd.

Answer

Use HTTP instead of HTTPS for better performance.

Answer

Disable client authentication to simplify configuration.

Answer

Expose the etcd port (2379) on a public IP for easier monitoring.

Question 12

You are a security engineer for a financial services company running a Kubernetes cluster on-premises. The cluster uses kubeadm for bootstrapping and Calico for network policy. Recently, a compliance audit revealed that all nodes in the cluster have the kubelet port 10250 open to the public network, allowing unauthenticated access to the kubelet API. This poses a severe security risk. The cluster has 10 worker nodes and 3 control plane nodes. You need to remediate this without disrupting running workloads. The nodes are behind a corporate firewall, but the internal network is considered untrusted. You have access to the node's iptables and can modify configuration files. Which course of action best secures the kubelet port while maintaining cluster functionality?

Accepted Answer

Use iptables on each node to allow incoming connections to port 10250 only from the cluster's CIDR (e.g., 10.0.0.0/8).. Option A is correct because using iptables to restrict access to port 10250 to only the cluster's internal CIDR (e.g., 10.0.0.0/8) directly addresses the audit finding by blocking unauthenticated public access while allowing necessary kubelet API communication from within the cluster. This approach does not disrupt running workloads, as it only modifies firewall rules without restarting kubelet or changing its configuration. It leverages the existing network infrastructure (iptables) and is consistent with the principle of least privilege for an untrusted internal network.

Answer

Configure a Calico GlobalNetworkPolicy to block inbound traffic to port 10250 on all nodes.

Answer

Change the kubelet port to a non-standard port (e.g., 10260) and update all kubelet configurations.

Answer

Set the --anonymous-auth flag to false on each kubelet and restart them one by one.

Question 13

A security engineer is configuring a Kubernetes cluster to meet CIS benchmark recommendations. The cluster uses kubeadm for bootstrapping. Which action should be taken to ensure the kube-apiserver is hardened against unauthorized access?

Accepted Answer

Set --anonymous-auth=false on the kube-apiserver. Option D is correct because setting `--anonymous-auth=false` on the kube-apiserver disables anonymous requests, ensuring that all API requests must be authenticated. This directly addresses CIS benchmark recommendations for hardening the API server against unauthorized access by preventing unauthenticated users from reaching the API.

Answer

Set --insecure-port=8080 on the kube-apiserver

Answer

Disable the NodeRestriction admission plugin

Answer

Enable encryption at rest for secrets in etcd

Question 14

A Kubernetes cluster is experiencing issues where pods cannot pull images from a private container registry. The registry requires authentication via imagePullSecrets. The cluster has a pod running with the following spec snippet. What is the likely cause of the failure?

Accepted Answer

The pod does not set serviceAccountName to the service account that has the imagePullSecrets. The pod spec snippet shows that the pod does not have a `serviceAccountName` field set, meaning it uses the default service account in the namespace. The default service account typically does not have `imagePullSecrets` attached. Even if the secret 'regcred' exists, the pod cannot use it unless the service account associated with the pod has that secret linked via `imagePullSecrets` in the service account definition. Therefore, the pod fails to authenticate to the private registry.

Answer

The secret 'regcred' does not exist in the namespace

Answer

The service account lacks RBAC permissions to use the secret

Answer

The imagePullSecret is of type 'Opaque' instead of 'kubernetes.io/dockerconfigjson'

Question 15

A DevOps team is tasked with upgrading a Kubernetes cluster from version 1.21 to 1.22. They want to minimize downtime and follow best practices. Which approach should they take?

Accepted Answer

Upgrade the control plane from 1.21 to 1.22 first, then upgrade worker nodes. Option C is correct because the Kubernetes upgrade process mandates upgrading the control plane first, as it is the authoritative source for cluster state and API operations. Worker nodes can then be upgraded to match the control plane version, ensuring compatibility and minimizing downtime by allowing workloads to continue running during the node upgrade phase.

Answer

Upgrade worker nodes first, then the control plane

Answer

Upgrade etcd to 1.22 first, then the API server

Answer

Drain all nodes, then upgrade all components to 1.22 at once