20+ practice questions focused on System Hardening — one of the most tested topics on the Certified Kubernetes Security Specialist CKS exam. Each question includes a detailed explanation so you learn why the right answer is correct.
Start System Hardening PracticeA cluster is running Kubernetes 1.24. The security team wants to enforce that all pods run with a read-only root filesystem. Which approach is most effective?
Explanation: In Kubernetes 1.24, PodSecurityPolicy (PSP) is deprecated but still functional. The PodSecurity admission controller with the restricted profile is the built-in, forward-looking replacement that enforces a read-only root filesystem for all pods. The restricted profile sets `securityContext.readOnlyRootFilesystem: true` by default, ensuring compliance without external tools, whereas PSP will be removed in 1.25 and is no longer the recommended approach.
A developer wants to run a container that needs to modify kernel parameters. What is the secure way to achieve this?
Explanation: Kubernetes provides a secure mechanism to modify kernel parameters via the `sysctls` field in the Pod's `securityContext`. This approach allows specific sysctls (e.g., `net.ipv4.tcp_syncookies`) to be set without granting full privileged access or dangerous capabilities. Safe sysctls can be set directly; unsafe sysctls must be explicitly enabled by the cluster administrator using the kubelet `allowedUnsafeSysctls` option.
You are a security engineer for a large e-commerce company. The Kubernetes cluster runs on-premises and hosts critical payment processing applications. Recently, a security scan revealed that several pods are running with privileged escalation enabled, and some have a writable root filesystem. The cluster uses Kubernetes v1.26 with PodSecurity admission controller enabled but currently set to 'privileged' profile for all namespaces. The development teams require flexibility for some legacy applications that need to run with hostNetwork or hostPID. However, the security team wants to enforce a restricted profile for most namespaces while allowing exceptions. The CISO has mandated that no pod should run as root, and all pods must have read-only root filesystem and privilege escalation disabled. Additionally, any pod that requires hostNetwork or hostPID must be explicitly approved and placed in a separate namespace. You need to design a solution that meets these requirements with minimal operational overhead. What is the best course of action?
Explanation: PodSecurity admission (PSA) is the native Kubernetes mechanism for enforcing pod security standards with minimal operational overhead. By labeling most namespaces with 'pod-security.kubernetes.io/enforce=restricted', you enforce the CISO's mandates (non-root, read-only root filesystem, no privilege escalation) automatically. Creating a separate namespace with the 'baseline' profile allows legacy apps requiring hostNetwork/hostPID to run after explicit approval, while still blocking privileged escalation and other dangerous capabilities.
A security engineer is hardening a Kubernetes node and wants to ensure that kubelet does not accept requests from unauthorized sources. Which kubelet configuration change should be made?
Explanation: Setting `--anonymous-auth=false` on the kubelet disables anonymous requests, meaning the kubelet will reject any request that does not present valid authentication credentials. This is a critical hardening measure to ensure only authenticated and authorized sources (e.g., the API server) can interact with the kubelet’s HTTPS API, preventing unauthorized nodes or attackers from querying or modifying pod/container state.
During a security audit, it is found that containers running in a cluster have CAP_NET_RAW capability by default. The team wants to drop this capability for all containers. Which approach should be taken?
Explanation: A mutating admission webhook can intercept Pod creation requests and modify the security context to drop capabilities like NET_RAW for all containers. This approach enforces the policy cluster-wide without requiring manual changes to each deployment, making it a viable alternative to deprecated PodSecurityPolicy.
+15 more System Hardening questions available
Practice all System Hardening questions1. Baseline your knowledge
Start with 10 questions to gauge your current understanding of System Hardening. This tells you whether you need a concept refresher or just practice.
2. Review every explanation
For each question — right or wrong — read the full explanation. Understanding why an answer is correct is more valuable than knowing the answer itself.
3. Focus on exam traps
System Hardening questions on the CKS frequently use trap wording. Look for subtle differences in answers that test your precision, not just general knowledge.
4. Reach 80% consistently
Do repeated sessions until you score 80%+ three times in a row. Then move to mixed-mode practice to test cross-topic recall under realistic conditions.
The exact number varies per candidate. System Hardening is tested as part of the Certified Kubernetes Security Specialist CKS blueprint. Practicing with targeted System Hardening questions ensures you can handle any format or difficulty that appears.
Yes. Courseiva provides free CKS practice questions across all exam topics and domains. The platform includes topic-based practice, mock exams, missed-question review, bookmarked questions, and readiness tracking — no account required.
Difficulty is subjective, but System Hardening is a high-priority exam concept tested in multiple ways — direct recall, scenario analysis, and command-output interpretation. Consistent practice is the best way to build confidence.
Launch a full System Hardening practice session with instant scoring and detailed explanations.
Start System Hardening Practice →