How should I use these Cluster Setup and Hardening practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Cluster Setup and Hardening questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Cluster Setup and Hardening domain.

CKS · topic practice

Cluster Setup and Hardening practice questions

Practise Certified Kubernetes Security Specialist CKS Cluster Setup and Hardening practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

20 questionsDomain: Cluster Setup and Hardening

Practice 10 questions Browse domain →

What the exam tests

What to know about Cluster Setup and Hardening

Cluster Setup and Hardening questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Cluster Setup and Hardening exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Cluster Setup and Hardening questions

20 questions · select your answer, then reveal the explanation

Question 1mediummulti select

Read the full Cluster Setup and Hardening explanation →

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)

Trap 1: Apply a PodSecurityPolicy that restricts containers from running as…

PSP is deprecated and replaced by Pod Security Admission; also it does not prevent token mounting.

Trap 2: Create a new service account with no roles bound and assign it to…

The pod would still use the default SA if not explicitly set, and the new SA without roles still has no access but does not prevent mounting of the default SA token.

Trap 3: Set automountServiceAccountToken: false in the pod spec.

This only affects that pod, not the default SA, and the question asks for measures to harden the cluster globally.

Study all Cluster Setup and Hardening common traps →

A
Apply a PodSecurityPolicy that restricts containers from running as root.
Why wrong: PSP is deprecated and replaced by Pod Security Admission; also it does not prevent token mounting.
B
Create a new service account with no roles bound and assign it to the pod.
Why wrong: The pod would still use the default SA if not explicitly set, and the new SA without roles still has no access but does not prevent mounting of the default SA token.
C
Edit the default service account to set automountServiceAccountToken: false.
Prevents automatic mounting of the default SA token in pods that do not specify a service account.
D
Set automountServiceAccountToken: false in the pod spec.
Why wrong: This only affects that pod, not the default SA, and the question asks for measures to harden the cluster globally.
E
Add securityContext: runAsNonRoot: true to the pod spec.
Ensures the container runs as a non-root user, reducing impact of compromise.

Full breakdown with real-world context →

Question 2hardmultiple choice

Read the full Cluster Setup and Hardening explanation →

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?

Trap 1: Patch existing deployments to remove privileged containers, then…

Patches would cause redeployment, potentially breaking the application and causing downtime.

Trap 2: Create a PodSecurityPolicy that restricts privileged containers and…

PodSecurityPolicy is deprecated in v1.24 and does not work with Pod Security Admission.

Trap 3: Set the namespace label…

'inform' is not a valid mode; valid modes are enforce, audit, warn.

Study all Cluster Setup and Hardening common traps →

A
Patch existing deployments to remove privileged containers, then add the label 'pod-security.kubernetes.io/enforce=restricted' to the namespace.
Why wrong: Patches would cause redeployment, potentially breaking the application and causing downtime.
B
Add the namespace label 'pod-security.kubernetes.io/enforce=restricted' and leave existing pods unchanged; new pods violating the policy will be rejected.
Correctly enforces the policy on new pods without affecting existing ones.
C
Create a PodSecurityPolicy that restricts privileged containers and bind it to all service accounts in the namespace.
Why wrong: PodSecurityPolicy is deprecated in v1.24 and does not work with Pod Security Admission.
D
Set the namespace label 'pod-security.kubernetes.io/enforce=restricted' and use the 'inform' mode to allow existing pods.
Why wrong: 'inform' is not a valid mode; valid modes are enforce, audit, warn.

Full breakdown with real-world context →

Question 3easymultiple choice

Read the full Cluster Setup and Hardening explanation →

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?

Trap 1: kube-proxy

kube-proxy does not serve TLS by default; it is a network proxy on nodes.

Trap 2: etcd

etcd can use TLS but is not the primary component for node-to-control-plane communication; nodes talk to API server.

Trap 3: kube-scheduler

The scheduler communicates with the API server, not directly with nodes.

Study all Cluster Setup and Hardening common traps →

A
kube-proxy
Why wrong: kube-proxy does not serve TLS by default; it is a network proxy on nodes.
B
etcd
Why wrong: etcd can use TLS but is not the primary component for node-to-control-plane communication; nodes talk to API server.
C
kube-scheduler
Why wrong: The scheduler communicates with the API server, not directly with nodes.
D
kube-apiserver
The API server serves HTTPS; configuring its TLS certificate encrypts all communication to/from it.

Full breakdown with real-world context →

Question 4mediummultiple choice

Read the full Cluster Setup and Hardening explanation →

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?

Trap 1: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata:…

The podSelector selects 'app: api' but should select the target pods 'app: db'.

Trap 2: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata:…

This controls egress from api pods, not ingress to db pods; it also does not deny other traffic to db.

Trap 3: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata:…

Missing port restriction; allows all ports from api pods.

Study all Cluster Setup and Hardening common traps →

A
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
Why wrong: The podSelector selects 'app: api' but should select the target pods 'app: db'.
B
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
Why wrong: This controls egress from api pods, not ingress to db pods; it also does not deny other traffic to db.
C
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
Why wrong: Missing port restriction; allows all ports from api pods.
D
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
Correctly targets db pods, allows ingress from api pods on port 5432, and implicitly denies all other ingress.

Full breakdown with real-world context →

Question 5hardmultiple choice

Read the full NAT/PAT explanation →

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?

Trap 1: The pod will be created only if the node label matches the…

NodeSelector is for scheduling, not for hostPath restrictions.

Trap 2: The pod will be rejected because hostPath volumes are not allowed…

NodeRestriction does not restrict hostPath volumes.

Trap 3: The pod will be rejected because the nodeSelector conflicts with…

No conflict exists; NodeRestriction does not affect nodeSelector.

Study all Cluster Setup and Hardening common traps →

A
The pod will be created only if the node label matches the nodeSelector; the hostPath volume is irrelevant.
Why wrong: NodeSelector is for scheduling, not for hostPath restrictions.
B
The pod will be rejected because hostPath volumes are not allowed by NodeRestriction.
Why wrong: NodeRestriction does not restrict hostPath volumes.
C
The pod will be created because NodeRestriction does not restrict hostPath volumes.
NodeRestriction only restricts node self-updates, not hostPath.
D
The pod will be rejected because the nodeSelector conflicts with the NodeRestriction plugin.
Why wrong: No conflict exists; NodeRestriction does not affect nodeSelector.

Full breakdown with real-world context →

Question 6mediummulti select

Read the full Cluster Setup and Hardening explanation →

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

Trap 1: Apply a NetworkPolicy to block traffic to etcd pods.

NetworkPolicies apply to pods, not to etcd running as a static pod or systemd service; also etcd may not be a pod.

Trap 2: Expose the etcd client port (2379) to the public internet for…

Exposing etcd publicly is insecure; it should be internal.

Study all Cluster Setup and Hardening common traps →

A
Apply a NetworkPolicy to block traffic to etcd pods.
Why wrong: NetworkPolicies apply to pods, not to etcd running as a static pod or systemd service; also etcd may not be a pod.
B
Use RBAC to restrict access to etcd.
RBAC can limit which users/service accounts can access etcd via the API server.
C
Enable TLS peer and client authentication.
TLS ensures encrypted communication and mutual authentication.
D
Expose the etcd client port (2379) to the public internet for monitoring.
Why wrong: Exposing etcd publicly is insecure; it should be internal.
E
Set file permissions on etcd data directory to 700.
Restricts access to the etcd user only.

Full breakdown with real-world context →

Question 7easymulti select

Read the full Cluster Setup and Hardening explanation →

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

Trap 1: Set --cors-allowed-origins=* for easy access.

Wildcard CORS allows any origin, increasing risk of CSRF attacks.

Trap 2: Disable TLS to improve performance.

TLS is essential for encryption; disabling it compromises security.

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

Insecure port is deprecated and should be disabled.

Study all Cluster Setup and Hardening common traps →

A
Set --cors-allowed-origins=* for easy access.
Why wrong: Wildcard CORS allows any origin, increasing risk of CSRF attacks.
B
Disable TLS to improve performance.
Why wrong: TLS is essential for encryption; disabling it compromises security.
C
Enable audit logging.
Audit logs help detect and investigate suspicious activities.
D
Set --insecure-port=8080 to allow non-TLS access.
Why wrong: Insecure port is deprecated and should be disabled.
E
Set --anonymous-auth=false.
Prevents unauthenticated requests to the API server.

Full breakdown with real-world context →

Question 8hardmultiple choice

Read the full Cluster Setup and Hardening explanation →

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?

Trap 1: PodSecurityPolicy

PodSecurityPolicy is deprecated and does not validate image sources.

Trap 2: AlwaysPullImages

AlwaysPullImages forces image pull but does not validate image origin or policy.

Trap 3: NodeRestriction

NodeRestriction limits node self-updates, not image admission.

Study all Cluster Setup and Hardening common traps →

A
PodSecurityPolicy
Why wrong: PodSecurityPolicy is deprecated and does not validate image sources.
B
AlwaysPullImages
Why wrong: AlwaysPullImages forces image pull but does not validate image origin or policy.
C
NodeRestriction
Why wrong: NodeRestriction limits node self-updates, not image admission.
D
ImagePolicyWebhook
ImagePolicyWebhook allows integration with an external webhook to enforce image admission policies.

Full breakdown with real-world context →

Question 9mediummultiple choice

Read the full Cluster Setup and Hardening explanation →

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?

Trap 1: The PodSecurityPolicy is applied in the wrong order and a less…

PSP ordering is alphabetical and the most restrictive policy that allows the pod is used; a misorder would not cause root.

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

RBAC permissions are required but if the admission controller is missing, PSPs are not evaluated.

Trap 3: The PodSecurityPolicy resource is misconfigured with an empty…

An empty field defaults to false, which would deny privilege escalation, not allow it.

Study all Cluster Setup and Hardening common traps →

A
The PodSecurityPolicy is applied in the wrong order and a less restrictive policy overrides it.
Why wrong: PSP ordering is alphabetical and the most restrictive policy that allows the pod is used; a misorder would not cause root.
B
The pod's service account lacks RBAC permissions to use the PSP.
Why wrong: RBAC permissions are required but if the admission controller is missing, PSPs are not evaluated.
C
The PodSecurityPolicy admission controller is not enabled in the kube-apiserver.
Without the admission controller, PSPs are not enforced regardless of RBAC.
D
The PodSecurityPolicy resource is misconfigured with an empty allowPrivilegeEscalation field.
Why wrong: An empty field defaults to false, which would deny privilege escalation, not allow it.

Full breakdown with real-world context →

Question 10easymultiple choice

Read the full Cluster Setup and Hardening explanation →

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

Trap 1: Apply a NetworkPolicy that selects pods in 'secure-ns' and has an…

This allows all egress, not restricting it.

Trap 2: No NetworkPolicy is needed because egress is denied by default.

By default, egress is allowed if no NetworkPolicy selects the pod.

Trap 3: Apply a NetworkPolicy that selects pods in 'secure-ns' and has an…

This only allows DNS traffic, but other egress is blocked. However, the question asks 'which configuration achieves this by default?' and an empty egress is the correct approach.

Study all Cluster Setup and Hardening common traps →

A
Apply a NetworkPolicy that selects pods in 'secure-ns' and has an empty egress section.
An empty egress rule blocks all egress traffic.
B
Apply a NetworkPolicy that selects pods in 'secure-ns' and has an egress rule allowing all traffic.
Why wrong: This allows all egress, not restricting it.
C
No NetworkPolicy is needed because egress is denied by default.
Why wrong: By default, egress is allowed if no NetworkPolicy selects the pod.
D
Apply a NetworkPolicy that selects pods in 'secure-ns' and has an egress rule allowing traffic to port 53.
Why wrong: This only allows DNS traffic, but other egress is blocked. However, the question asks 'which configuration achieves this by default?' and an empty egress is the correct approach.

Full breakdown with real-world context →

Question 11mediummulti select

Read the full Cluster Setup and Hardening explanation →

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

Trap 1: Use HTTP instead of HTTPS for better performance.

HTTP does not encrypt traffic, compromising security.

Trap 2: Disable client authentication to simplify configuration.

Disabling authentication allows unauthorized access.

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

Exposing etcd to public networks increases attack surface.

Study all Cluster Setup and Hardening common traps →

A
Enable TLS encryption for client-to-server communication.
TLS encrypts data in transit between etcd and clients.
B
Enable peer authentication using TLS certificates.
Peer authentication ensures only trusted etcd members join the cluster.
C
Use HTTP instead of HTTPS for better performance.
Why wrong: HTTP does not encrypt traffic, compromising security.
D
Disable client authentication to simplify configuration.
Why wrong: Disabling authentication allows unauthorized access.
E
Expose the etcd port (2379) on a public IP for easier monitoring.
Why wrong: Exposing etcd to public networks increases attack surface.

Full breakdown with real-world context →

Question 12hardmultiple choice

Read the full Cluster Setup and Hardening explanation →

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?

Trap 1: Configure a Calico GlobalNetworkPolicy to block inbound traffic to…

Calico network policies operate at the pod level, not on host ports like kubelet. This would not affect host network traffic.

Trap 2: Change the kubelet port to a non-standard port (e.g., 10260) and…

Changing the port requires updating kube-apiserver and other components, causing potential disruption and complexity.

Trap 3: Set the --anonymous-auth flag to false on each kubelet and restart…

Disabling anonymous auth does not block network access; authenticated requests from compromised nodes could still reach the kubelet.

Study all Cluster Setup and Hardening common traps →

A
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).
Restricting source IPs to the cluster network reduces exposure while allowing legitimate kubelet API calls from the control plane and other nodes.
B
Configure a Calico GlobalNetworkPolicy to block inbound traffic to port 10250 on all nodes.
Why wrong: Calico network policies operate at the pod level, not on host ports like kubelet. This would not affect host network traffic.
C
Change the kubelet port to a non-standard port (e.g., 10260) and update all kubelet configurations.
Why wrong: Changing the port requires updating kube-apiserver and other components, causing potential disruption and complexity.
D
Set the --anonymous-auth flag to false on each kubelet and restart them one by one.
Why wrong: Disabling anonymous auth does not block network access; authenticated requests from compromised nodes could still reach the kubelet.

Full breakdown with real-world context →

Question 13mediummultiple choice

Read the full Cluster Setup and Hardening explanation →

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?

Trap 1: Set --insecure-port=8080 on the kube-apiserver

Enabling insecure port exposes the API server without authentication.

Trap 2: Disable the NodeRestriction admission plugin

Disabling NodeRestriction reduces node security.

Trap 3: Enable encryption at rest for secrets in etcd

Encryption at rest protects data at rest, not API access.

Study all Cluster Setup and Hardening common traps →

A
Set --insecure-port=8080 on the kube-apiserver
Why wrong: Enabling insecure port exposes the API server without authentication.
B
Disable the NodeRestriction admission plugin
Why wrong: Disabling NodeRestriction reduces node security.
C
Enable encryption at rest for secrets in etcd
Why wrong: Encryption at rest protects data at rest, not API access.
D
Set --anonymous-auth=false on the kube-apiserver
Disables anonymous requests, requiring authentication for all API access.

Full breakdown with real-world context →

Question 14hardmultiple choice

Read the full Cluster Setup and Hardening explanation →

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?

Trap 1: The secret 'regcred' does not exist in the namespace

The secret is assumed to exist if referenced.

Trap 2: The service account lacks RBAC permissions to use the secret

Service accounts can reference secrets without extra RBAC.

Trap 3: The imagePullSecret is of type 'Opaque' instead of…

The type should be dockerconfigjson, but if it's correct, it's not the issue.

Study all Cluster Setup and Hardening common traps →

A
The secret 'regcred' does not exist in the namespace
Why wrong: The secret is assumed to exist if referenced.
B
The service account lacks RBAC permissions to use the secret
Why wrong: Service accounts can reference secrets without extra RBAC.
C
The pod does not set serviceAccountName to the service account that has the imagePullSecrets
Without explicit service account, pod uses 'default' SA which has no imagePullSecrets.
D
The imagePullSecret is of type 'Opaque' instead of 'kubernetes.io/dockerconfigjson'
Why wrong: The type should be dockerconfigjson, but if it's correct, it's not the issue.

Full breakdown with real-world context →

Question 15easymultiple choice

Read the full Cluster Setup and Hardening explanation →

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?

Trap 1: Upgrade worker nodes first, then the control plane

Control plane must be upgraded before worker nodes.

Trap 2: Upgrade etcd to 1.22 first, then the API server

etcd is upgraded as part of control plane upgrade.

Trap 3: Drain all nodes, then upgrade all components to 1.22 at once

Draining is good but upgrading all at once may cause downtime.

Study all Cluster Setup and Hardening common traps →

A
Upgrade worker nodes first, then the control plane
Why wrong: Control plane must be upgraded before worker nodes.
B
Upgrade etcd to 1.22 first, then the API server
Why wrong: etcd is upgraded as part of control plane upgrade.
C
Upgrade the control plane from 1.21 to 1.22 first, then upgrade worker nodes
Component upgrades must follow version skew policy; control plane first.
D
Drain all nodes, then upgrade all components to 1.22 at once
Why wrong: Draining is good but upgrading all at once may cause downtime.

Full breakdown with real-world context →

Question 16mediummulti select

Read the full Cluster Setup and Hardening explanation →

Which TWO actions should be taken to secure etcd in a Kubernetes cluster?

Trap 1: Run etcd as a DaemonSet to ensure high availability

etcd is stateful and should use a dedicated cluster.

Trap 2: Disable client certificate authentication for etcd

Disabling authentication weakens security.

Trap 3: Enable the NodeRestriction admission plugin on etcd

NodeRestriction is not applicable to etcd.

Study all Cluster Setup and Hardening common traps →

A
Enable TLS authentication for etcd peer and client communication
TLS ensures encrypted and authenticated communication.
B
Run etcd as a DaemonSet to ensure high availability
Why wrong: etcd is stateful and should use a dedicated cluster.
C
Disable client certificate authentication for etcd
Why wrong: Disabling authentication weakens security.
D
Enable the NodeRestriction admission plugin on etcd
Why wrong: NodeRestriction is not applicable to etcd.
E
Restrict access to etcd using network policies or firewall rules
Limits network access to etcd.

Full breakdown with real-world context →

Question 17mediumdrag order

Read the full Cluster Setup and Hardening explanation →

Arrange the steps to create and enforce a Pod Security Policy (PSP) in a Kubernetes cluster.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Question 18mediumdrag order

Read the full Cluster Setup and Hardening explanation →

Order the steps to perform a Kubernetes cluster upgrade from version 1.24 to 1.25.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Question 19mediummatching

Read the full Cluster Setup and Hardening explanation →

Match each Kubernetes security component to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Admission controller that enforces security constraints on pods

Defines how groups of pods can communicate with each other and other network endpoints

Role-based access control for authorization within the cluster

Linux security facility to restrict system calls from a container

Mandatory access control system that confines programs to a limited set of resources

Question 20mediummatching

Read the full Cluster Setup and Hardening explanation →

Match each container security context setting to its effect.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Prevents processes from gaining more privileges than their parent

Ensures the container runs with a user ID that is not 0 (root)

Mounts the container's root filesystem as read-only

Drops all Linux capabilities, minimizing kernel privileges

Disables privileged mode, preventing access to host devices

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Cluster Setup and Hardening sessions

Start a Cluster Setup and Hardening only practice session

Every question in these sessions is drawn from the Cluster Setup and Hardening domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Cluster Setup and Hardening questions →Mixed CKS session

Frequently asked questions

What does the CKS exam test about Cluster Setup and Hardening?: Cluster Setup and Hardening questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Cluster Setup and Hardening questions in a focused session?: Yes — the session launcher on this page draws every question from the Cluster Setup and Hardening domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other CKS topics?: Use the topic links above to move to related areas, or go back to the CKS question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the CKS exam covers. They are not copied from any real exam or dump site.

Cluster Setup and Hardening only

10 questions 20 questions 30 questions 50 questions

Mixed CKS session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All CKS questions Cluster Setup and Hardening domain overview CKS exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Cluster Setup and Hardening practice questions

What to know about Cluster Setup and Hardening

Common Cluster Setup and Hardening exam traps

Cluster Setup and Hardening questions

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)

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?

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?

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?

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

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

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?

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?

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

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

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?

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?

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?

Which TWO actions should be taken to secure etcd in a Kubernetes cluster?

Arrange the steps to create and enforce a Pod Security Policy (PSP) in a Kubernetes cluster.

Order the steps to perform a Kubernetes cluster upgrade from version 1.24 to 1.25.

Match each Kubernetes security component to its description.

Match each container security context setting to its effect.

Track your progress over time

Start a Cluster Setup and Hardening only practice session

Related CKS topic practice pages

Monitoring Logging and Runtime Security practice questions