Cluster Setup
Free Certified Kubernetes Security Specialist practice — 6 questions on Cluster Setup, with explanations. No sign-up. Full 12-question mixed test →
You must create a NetworkPolicy in namespace 'payments' that allows ingress traffic ONLY from pods labeled role: frontend that are running inside namespaces labeled team: frontend. Traffic from frontend-labeled pods in any other namespace, or from any pod (without the role label) inside team: frontend namespaces, must be denied. Which policy 'ingress.from' structure correctly enforces this?
When namespaceSelector and podSelector appear inside the SAME 'from' entry, Kubernetes ANDs them — only pods matching both the pod label AND running in a matching namespace are allowed. This is the only structure that matches the exact requirement.
Per the CIS Kubernetes Benchmark, which kubelet configuration correctly closes the anonymous authentication attack surface while still delegating authorization decisions to the API server's RBAC policies?
CIS 4.2.1 requires anonymous-auth=false to prevent unauthenticated requests to the kubelet API, and 4.2.2 requires authorization-mode=Webhook so the kubelet defers every authorization decision to the API server's configured RBAC/webhook authorizer instead of trusting all callers.
During a CIS benchmark review of etcd's static pod manifest, you see --cert-file and --key-file are set, but --client-cert-auth and --peer-client-cert-auth are absent. What is the resulting risk, and what is the correct fix?
Without --client-cert-auth and --peer-client-cert-auth, TLS may encrypt the channel but etcd does not require or verify client/peer certificates, meaning any process that can reach the etcd port can authenticate as a trusted member or client — a critical CIS control (etcd section) failure.
Which kube-apiserver flag combination should you verify per the CIS Benchmark to ensure the insecure port is disabled and the profiling debug endpoint is turned off?
CIS requires --insecure-port=0 (the insecure port is already removed by default in current Kubernetes but must be verified as 0/absent) and --profiling=false to prevent exposing pprof debug/profiling data that can leak sensitive runtime information.
Pods on cloud-hosted worker nodes can successfully query http://169.254.169.254/latest/meta-data/iam/security-credentials/ and retrieve the node's IAM role credentials. Which control BEST mitigates this specific risk at the cluster networking layer?
Blocking egress to the instance metadata IP via NetworkPolicy (and hardening the metadata service itself, e.g., requiring IMDSv2 tokens with a low hop-limit so containerized processes can't reach it) directly stops pods from reaching node-level cloud credentials — this is the standard CKS mitigation for the metadata-endpoint attack path.
You downloaded the kubeadm binary from the official Kubernetes release channel before installing it on a hardened control-plane node. Which method authoritatively verifies BOTH the integrity and the publisher authenticity of the binary before use?
SHA-512 checksum verification confirms the file wasn't corrupted or tampered with in transit, while validating the cryptographic signature against the known Kubernetes release signing key confirms the binary genuinely originated from the official Kubernetes release process — together they cover both integrity and authenticity, which the CKS exam explicitly tests.
Ready for the real thing?
The full course has two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed answer explanations.
Start my full course on Udemy →